Greetings, Kaz Kylheku! > I can't find any reference anywhere to PATHEXT being used outside > of the CMD.EXE interpreter, which rather tends to make it substantially > less than fundamental to Windows, though noteworthy.
> Certainly, CreateProcess does not use PATHEXT. > I can't find any documentation which says that ShellExecuteEx > uses PATHEXT, either. (Can anyone confirm?) ShellExecute(Ex) uses its own discovery mechanism with hardcoded order. PATHEXT is meaningless for this case. It's a CMD's (and some other shells and file managers) setting to find executable object in a specified order. Not a mechanic to determine, how to execute it. >> Without using extensions, bash can use execution privileges to >> determine if >> a file is executable. However, that does not work when invoking a >> command >> from CMD. > What does not work from CMD is Microsoft's problem, not Cygwin's. > Yes, even though you have a "myscript.sh" and you do "chmod a+x > myscript.sh" > inside Cygwin, the outside Windows world doesn't agree that myscript.sh > is now executable, and that it uses /bin/sh by default as its > interpreter, > if a #! line is absent, otherwise the interpreter nominated by the #! > line. > Adding ".sh" to PATHEXT might work in causing CMD.EXE to resolve > "myscript" to "myscript.sh"; however, it will not then successfully > execute "myscript.sh", because the underlying CreateProcess API > will not find it executable. > CMD.EXE will probably *try* to execute it, and fail. Not, if you provide a file association. :) [C:\Users\anrdaemon\Documents\_pas\ShExETest]$ echo %PATHEXT% .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1;.MSC;.BTM;.PHP;.SH [C:\Users\anrdaemon\Documents\_pas\ShExETest]$ assoc .sh .sh=unixshell.script [C:\Users\anrdaemon\Documents\_pas\ShExETest]$ ftype unixshell.script unixshell.script="C:\Programs\Cygwin_64\bin\cygwrap.cmd" "%1" %* > Not supporting arbitrary interpreters for scripts is a Windows > problem/limitation. To be fair, CMD have this mechanics, but it's compatible with shebang in the least. To begin with, it uses an explicit command your interpreter has to know and discard, rather than a widely-accepted as a comment the '#' char. > What you need on Windows is a script-to-EXE application deployment tool, > which takes your "script.sh" and combines it with a copy of a special > binary executable, and writes out the combination to "script.exe". > Then even a raw CreateProcess Win32 API call can invoke "script.exe". You're overcomplicating it. > Firstly, the binary mode default treatment for files comes > from the mount table: > $ mount > C:/Cygwin/bin on /usr/bin type ntfs (binary,auto) > C:/Cygwin/lib on /usr/lib type ntfs (binary,auto) > C:/Cygwin on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > See how that /cygdrive/c is mounted "binary" (as is everything else?) > That's what causes text files to be treated as LF rather than CR/LF. > That can be altered; you can mount some Windows path into Cygwin's > POSIX file system view as text, and then CR/LF conversion is done. And in turn cause short reads, size miscalculations and overall corruption of the data. "text" mounts and modes were discouraged for ages, if not decades, by now. -- With best regards, Andrey Repin Thursday, August 4, 2016 15:13:11 Sorry for my terrible english...
