DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=s7D39iqI8twqMOD+
	TUCJbvPXuRBwCUR9rJ3baexdyfufiKN28DfFwu4Wa5r9UOYuTj6P9upDylSHUiqT
	ufOFnAJ9qQDhbjGijfBpxt37cP/sg/NMPdKwRfGreHm1BM82qXJWBBYyuTMH0FOu
	jkhD99/jngdzKJLoPEIcG7KYG30=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Thu, 4 Aug 2016 15:49:20 +0300
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: cygwin AT cygwin DOT com
Message-ID: <373943897.20160804154920@yandex.ru>
To: Kaz Kylheku <kaz AT kylheku DOT com>, cygwin AT cygwin DOT com
Subject: Re: PATHEXT is fundamental to Windows and Should be recognised by  CYGWIN
In-Reply-To: <b572984759892a20202a879d54e1213a@mail.kylheku.com>
References: <001001d1edf1$a4e1ae90$eea50bb0$@rogers.com> <b572984759892a20202a879d54e1213a AT mail DOT kylheku DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

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