Winpty can't launch (certain) executables via Windows NTFS symlink

[CMCDragonkai]

I use Windows NTFS symlinks to symlink to Windows executables such as:

New-Item -Path C:\ProgramData\bin\prey -ItemType SymbolicLink -Value 'C:\Windows\Prey\current\bin\prey.cmd'

I put C:\ProgramData\bin into my SYSTEM PATH. Doing it this way (without the .cmd extension) makes the symlink executable in Powershell and in Cygwin (although powershell appears to always launch the program in a new cmd window).

However when I try to run winpty prey console, I end up with this:

Could not start 'prey': The system cannot find the file specified. (error 0x2)

Cygwin and Powershell can both find prey in this way. However Winpty and I noticed CMD can't find prey.

They can only find it, if I rename C:\ProgramData\bin\prey -> C:\ProgramData\bin\prey.cmd, however I don't want to do this as this makes Cygwin unable to launch prey without the .cmd extension, and it also doesn't work at all because for some reason unlike Cygwin neither Powershell nor CMD changes its current working directory to the location of the symlink when executing through a symlink. So changing it to prey.cmd won't solve any problems, but just make the symlink useless.

[CMCDragonkai]

Actually I found the main explanation for this: http://superuser.com/questions/927411/how-can-i-start-an-application-via-a-windows-symlink

The most foolproof method would be to use to have:

x -> x.bat
x.bat as a batch file that executes /path/to/x.cmd

Where x and x.bat are both in the same directory, and the directory is in the PATH.

But it would be great if winpty could somehow interpret symlinks the same way that cygwin does and shift the working directory appropriately for symlinks. (Perhaps this can be done with a flag).

[rprichard]

I'll look at this next week sometime.

[rprichard]

I don't think shells change the working directory when they start a program. %~dp0 is an absolute path to the script being invoked -- %cd% is the working directory.

I wonder if winpty.exe ought to try and reuse the Cygwin fork/exec code somehow. It could do so easily by reinvoking itself from the agent with a special command-line. It would fix other issues (e.g. the MSYS2 argument conversion issue #88 and could allow propagating Cygwin signals, #29).

#81 is another bug in the executable searching code.