This is the mail archive of the
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 firstname.lastname@example.org
- References: <email@example.com> <firstname.lastname@example.org>
- 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
>> 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
> 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
> if a #! line is absent, otherwise the interpreter nominated by the #!
> 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%
[C:\Users\anrdaemon\Documents\_pas\ShExETest]$ assoc .sh
[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
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
"text" mounts and modes were discouraged for ages, if not decades, by now.
With best regards,
Thursday, August 4, 2016 15:13:11
Sorry for my terrible english...