This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN


Thanks for the reply Kaz.  I did not embed any comments in your reply for the sake of brevity.

I had seen the reference to a patch to support PATHEXT; it was dismissed pretty lightly.

PATHEXT has been part of Windows for as long as I can remember - back to the mid-80's - used by shells that run under windows (e.g. CMD, PowerShell, VBS, etc.).  Windows inherently uses file suffixes to associate programs to data files, hence CMD files to CMD.exe, VBS to VB, etc..     All its shells refer to PATHEXT and/or file associations in the registry.  

I have worked with Unix for a long time (1974) and Windows for almost as long (1986?).  Because some notion does not exist in Unix is no reason for discrediting it within Windows esp in the context of a tool framework specifically  catering to Windows according to its defining mission.  If you have been web-searching for references to my query, surely you have found many items referring to the problem in practice.  I used to move a whack of scripts between Solaris and Windows - same scripts supporting an enterprise backup product with HQ hosted on Solaris and 150 sites worldwide running Windows only.  My automated port process stripped or added suffixes as necessary going between Solaris and Windows.  However, once in Windows, a tool could be called from a shell script or a CMD script without regard of the suffix - the (MKS) shell worked with the suffix or not while CMD (and vbs) relied upon PATHEXT.

One has to look at practical applications when deciding what is warranted.  I cannot help feeling that CYGWIN's proponents give lip service to interoperability with Windows - that they would rather be running Linux in a VM in which case why  bother with a Windows foundation in the first place? Other than Microsoft fearing competition, the second biggest drawback to Windows developers adopting Unix tools has been due to Unix developers  wishing that Windows would go away.

MKS has done a great job of working with Windows.  You may recall Interix which tried to launch a product that ran isolated within the POSIX subsystem - it went nowhere - Microsoft bought the dregs of the company for no rational reason I can discern. They released a Unix environment for NT  and it tanked.  They are trying again with Ubuntu under Windows 10 but that will fail as well because it will be completely isolated from the Win32 environment. 

Windows developers need to get to Windows tools and resources - CYGWIN could be a very smart supplement to that requirement.  Windows 7 with the MKS Toolkit is in fact one of the most productive environments I have used.  MKS's value lays in its integration with Windows.  CYGWIN's developers recognising that Windows is not a passing fad might push CYGWIN into the mainstream of Windows development.  As it stands, if getting into it is a challenge for people with plenty of Unix and Windows background,  it will not make much headway with pure Windows programmers.

Your comment regarding " What does not work from CMD is Microsoft's problem, not Cygwin's." ignores that Cygwin is supposed to work within Windows.  You penalise CYGWIN users - not Microsoft. Frankly, that comment strikes me as somewhat cavalier.

You commented:
    "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"."  

I disagree completely.  If you are in an interactive bash, running on a Windows computer, you sure as hell expect to be able to run "foo.bat" by typing "foo".  And if you are in a script you expect to release to a large community, If "foo" comes from some 3rd party package released independently, then you don't want to be wiring into your script that "foo" is a bat, exe, vbs, cmd, or whatever in case the 3rd party package ever changes its implementation (e.g. converting a CMD to  an EXE for performance reasons).  I agree fully that PATHEXT is not a great mechanism - it just happens to be wired into Windows.

It is a myth that Unix-y programmers work in a vacuum within Windows.  Any serious software will have to exploit, hence interact with, Windows native and add-on tools.

As for CR/LF, I admit that I have not mastered all the opportunities fstab might present under CYGWIN but I don't think they will apply if the bash script is invoked from a Windows environment rather than from a bash script would they.

Thanks for your thoughts Kaz. I realise you are a volunteer and appreciate your efforts.  Having cut  my teeth on Unix, I appreciate its value however having been forced to work with Windows for so many decades, I have come to appreciate a few aspects.  I just miss all the tools for day-to-day use I took for granted under Unix.  If CYGWIN  could mitigate some of the recurring impediments new users trip over, (as evidenced by the many web-references to both my problems) it would facilitate its adoption by both Unix and non-Unix types.  

Cheers,
Michel

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Kaz Kylheku
Sent: August-03-16 10:55 PM
To: Michel LaBarre
Cc: cygwin@cygwin.com
Subject: Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]