PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

[Andrey Repin]

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...