DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:subject:mime-version:content-type
	:content-transfer-encoding:date:from:cc:in-reply-to:references
	:message-id; q=dns; s=default; b=uml+Fbo6Svn6kCKmWaqXC393Bu4ZNPc
	whA1St5ty4Ot4qYF2s8S7E/W0cbrj2OwU8keRHak+mQ2MARRWeUDqA8LCDpgvFyv
	NRQvddFob4wMw83EZdaJDlo8ov0cOk1+D85Dfi99s/Y9AcAgd1wx13WhG65442qi
	eZADp2nyXHSI=
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
To: Michel LaBarre <michel DOT labarre AT rogers DOT com>
Subject: Re: PATHEXT is fundamental to Windows and Should be recognised by  CYGWIN
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Wed, 03 Aug 2016 19:54:32 -0700
From: Kaz Kylheku <kaz AT kylheku DOT com>
Cc: cygwin AT cygwin DOT com
In-Reply-To: <001001d1edf1$a4e1ae90$eea50bb0$@rogers.com>
References: <001001d1edf1$a4e1ae90$eea50bb0$@rogers.com>
Message-ID: <b572984759892a20202a879d54e1213a@mail.kylheku.com>
User-Agent: Roundcube Webmail/0.9.2

On 03.08.2016 18:43, Michel LaBarre wrote:
> Problem 1:  Cygwin does not support PATHEXT and really should.

A casual websearch shows that this topic has come up before.

For instance, someone posted, some decade ago, to the Cygwin mailing
list, a patch against GNU Bash to make its command search algorithm
take PATHEXT into account.

> Fundamental reason:  from the Cygwin FAQ - What is it?  "Cygwin is a
> distribution of popular GNU and other Open Source tools running on 
> Microsoft
> Windows."
> 
> PATHEXT is as fundamental component of Windows program execution as 
> PATH.

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?)

Everything points to it being a CMD.EXE "gizmo". If you want to execute
a command such that PATHEXT is taken into account, you have to spawn
CMD.EXE /C <yourcommand>.

Cygwin provides a POSIX environment on Windows. Users of a POSIX
environment don't expect a command "foo" to resolve to a file
"foo.bat". If they want to run "foo.bat" they use "foo.bat".

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

> This means that when invoked from BASH, you name a command "ZOT"
> but "ZOT.sh" (or similar) if invoked from CMD.

 From CMD, you have do something explicit like this:

   C:\Cygwin\bin\bash C:\Path\to\zot.sh

That is, you have to run Bash, and pass it the script as an argument.
Windows and CMD.EXE will not associate .sh with Bash and certainly
won't look at any #! line you may have in the script.

Not supporting arbitrary interpreters for scripts is a Windows
problem/limitation.

Cygwin overcomes that limitation within its "garden".

If you solve the entry point problem of how to invoke Cygwin code
from the outside, once you are in Cygwin land, you have no further
problems. Scripts marked executable and containing #! use their
respective interpreters and so on.

> The published solutions in
> the various FAQs are not satisfactory. Creating links between ZOT.sh 
> and ZOT
> creates substantial overhead.
 
I don't think that will work, unless by "creating a link" you mean
that you create a ZOT.BAT file shim which invokes the neighboring
ZOT.sh by passing its full path to bash.exe.

> If CYGWIN really intends to support Windows
> it should support its fundamental execution framework.  It should be 
> equally
> easy to invoke a bash script from a bash script or a CMD script.

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

> Problem 2:  Cygwin does not support CR-LF delimiters.  For the same 
> reason,
> it is unfortunate that CYGWIN/bash does not cope with both types of 
> line
> delimiters transparently.

The way Cygwin deals with CR/LF has evolved over time, and there
are various ways to deal with this, depending on the specific
situation.

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.

Then, secondly, there are approaches for individual C programs.

If you're porting something written in C,
the C library in Cygwin supports the "t" flag in
fopen and related functions. This is similar to the Microsoft
extension, found in the Visual C run-time library.
In ISO C, if you omit the "b" mode, then a file is open in text
mode, but on POSIX that is the same as binary mode. In Cygwin, if
you specify "t", you get the Windows text mode, CR/LF. Without "t"
or "b", I think it defaults to the mode from the mount table. So if
you're working on porting a C program, that's one tool in your arsenal.

As an alternative to introducing "t" into C programs, there
is a link-time method. Cygwin provides several special .o
object files that can be specified when linking
a C program, which change its treatment of files in this regard.

Note that some standard utilities for processing text, though
written in C, do not use the C stdio library. So they don't
respond to these mechanisms. For instance GNU Awk does its
own I/O, and that is LF terminated.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple