This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN
- From: Andrey Repin <anrdaemon at yandex dot ru>
- To: Kaz Kylheku <kaz at kylheku dot com>, cygwin at cygwin dot com
- Date: Thu, 4 Aug 2016 15:49:20 +0300
- Subject: Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN
- Authentication-results: sourceware.org; auth=none
- Authentication-results: smtp2m.mail.yandex.net; dkim=pass header.i=@yandex.ru
- References: <001001d1edf1$a4e1ae90$eea50bb0$@rogers.com> <b572984759892a20202a879d54e1213a@mail.kylheku.com>
- Reply-to: cygwin at cygwin dot com
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...