X-Recipient:	archive-cygwin AT delorie DOT com
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=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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; s=default; bh=wpyFSUkZsNObt3Ltlj+nkk
	GukYE=; b=lMOCZsDBDHjF13XM8cCAfUG/sLBr/cROZuD1C7J8WUCwrJq+oTYlR1
	OcrSuK5FAj1J0BavwnDNosUHF/bsT84jdj/ehRurLaOMJ7Vky83QiSaI1fBFjnWV
	sMEMjfzuNFSxdIcX4FAVdkshfeXQwBfLh2ScDtPpAKXFE2wMSa0y4=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=2.0 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_THEBAT,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 spammy=H*F:D*yandex.ru, Repin, repin, H*UA:Bat!
X-HELO:	forward8m.cmail.yandex.net
Authentication-Results:	smtp2m.mail.yandex.net; dkim=pass header.i=@yandex.ru
X-Yandex-Suid-Status:	1 0,1 0
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
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id u74Coebg019670

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

- Raw text -