PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

Michel LaBarre
The CYGWIN site makes it quite difficult to discern how somebody can report
an issue or comment.

In any event, I subscribed to the cygwin mailing list and am replying to one
of the many links sent to me in case this happens to be a way to comment.

Problem 1:  Cygwin does not support PATHEXT and really should.

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.
 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.  This means that when invoked from BASH, you name a command "ZOT"
but "ZOT.sh" (or similar) if invoked from CMD.  The published solutions in
the various FAQs are not satisfactory. Creating links between ZOT.sh and ZOT
creates substantial overhead.  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.  (This is
not insurmountable as the MKS toolkit has supported this for decades.)

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.

I have been using and developing system software within Unix since 1974 and
Windows since the mid-80's.  in more recent years (since the mid-90's) I
have developed extensive sets of tools (sh/awk/etc..) for corporate and
public sector clients - on the order of 100,000 lines of code for
representative projects.  Most had to run under both Solaris and Windows
environments for which I used the MKS toolkit.

Michel LaBarre






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

Reply | Threaded
Open this post in threaded view
|

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

Kaz Kylheku-5
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

Reply | Threaded
Open this post in threaded view
|

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

Michel LaBarre
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: [hidden email] [mailto:[hidden email]] On Behalf Of Kaz Kylheku
Sent: August-03-16 10:55 PM
To: Michel LaBarre
Cc: [hidden email]
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

Reply | Threaded
Open this post in threaded view
|

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

Vince Rice
In reply to this post by Michel LaBarre
> On Aug 3, 2016, at 8:43 PM, Michel LaBarre wrote:
>
> The CYGWIN site makes it quite difficult to discern how somebody can report
> an issue or comment.

If you think a plainly labeled “Reporting Problems” and “Mailing Lists” in the prominent sidebar is difficult, then I’m afraid it’s only going to get worse from here.

> Problem 1:  Cygwin does not support PATHEXT and really should.
>
> 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.

“To you.” Almost every sentence in that paragraph should have “to you” at the end. I’ve used Cygwin for over a dozen years, and I have never once missed having PATHEXT in mintty/bash.
You can continue to use PATHEXT to your heart’s content in CMD.
Bash isn’t CMD.

> The published solutions in the various FAQs are not satisfactory.

“To you."

> Problem 2:  Cygwin does not support CR-LF delimiters.

Yes it does, although it is heartily suggested they be left behind (pretty much any Windows program can handle Unix line endings but Notepad, and anyone using Notepad has bigger issues than line endings).
Text mounts can be created in Cygwin (although, again, not suggested). There are also a few (non-standard) things in Cygwin’s bash to try to handle CRLF scripts. You can search the archives for more information.

> CYGWIN could be a very smart supplement to that requirement.
> …
> 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.  

No, Cygwin _is_ a very smart supplement to that requirement. You talk as if Cygwin just showed up last week. It’s been around for almost twenty years, is widely used and widely respected.

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

No, _you_ expect to. I don’t. I know that Bash isn’t CMD.

Cygwin is providing a Posix environment on Windows. If you want a Windows environment on Windows, then use CMD. Almost all of Cygwin’s supplied programs work perfectly well in CMD, as long as you remember they’re providing a Posix environment and therefore need Unix paths, etc.



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

Reply | Threaded
Open this post in threaded view
|

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

Doug Henderson
In reply to this post by Michel LaBarre
On 3 August 2016 at 22:30, Michel LaBarre  wrote:

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


First, this discussion is more appropriate for cygwin-talk than this list.

Second, PATHEXT is an attempt to carry the concept of default behavior
(based on its extension) for a file in the graphics window world, into the
command line world. That default behavior is hidden away in the registry
where normal users fear to tread and experts tread with care. That default
behavior is subject to the whims of the most recently installed program
than thinks it knows what the user wants to do with a file with a
particular extension.

The default behavior of a newly installed version of windows is to hide the
extension, and only show an icon in the explorer, where (again) the icon
depends on the most recently installed program than thought it knew what
icon should go with that file extension. And that icon to extension mapping
does not guarantee or require a unique icon for each extension, so, unless
you dig through the registry you have no way of knowing, in advance, what
will happen when you double click that file. And any knowledge you gained
from experience may get changed by the next program you install, without
your knowledge or permission.

A couple of examples: I work with Oracle databases, so 90% of my .sql files
are Oracle scripts and PL/SQL. I had to install MSSQL for some reason, and
suddenly an accidental double click on an .sql file was opening some huge
slow Microsoft tool instead of SQL Developer. It was an annoying fiddle to
restore useful behavior.

I use Python a lot. I have 7 versions (of Python, 5 for Win, 2 for cygwin,
plus Jython and IronPython) installed right now, so I need to pick my
environment for each .py file, or for my current project. I had to install
Visual Studio and a Python plugin for it. VS hijacked my .py files, ignores
#! lines, and takes forever to load and open an editor window. Now though,
double clicked a .py file or entering its name (with or without the
extension) at the command prompt opens it in a fast and useful text editor.

To summarize, I don't think PATHEXT is such a great feature of the command
prompt that it needs to be emulated in cygwin.

If I have gone to the trouble of typing "./name_of_file", (you don't have
"." in your PATH do you?) it's no big effort to hit TAB (for command
completion) and fill in the explicit extension. And if I'm writing a
script, I'm a fool if I don't include the extension.

And BTW, I set CYGWIN_NOWINPATH=1 from the control panel so I can't
accidentally run a windows program when I meant to run a cygwin one.


Doug

--
Doug Henderson, Calgary, Alberta, Canada

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

Reply | Threaded
Open this post in threaded view
|

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

Csaba Ráduly
In reply to this post by Michel LaBarre
Hi Michel,

On Thu, Aug 4, 2016 at 6:30 AM, Michel LaBarre  wrote:
> Thanks for the reply Kaz.  I did not embed any comments in your reply for the sake of brevity.

Please don't top-post.
For the sake of brevity:  https://cygwin.com/acronyms/#TOFU

Csaba
--
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

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

Reply | Threaded
Open this post in threaded view
|

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

Andrey Repin
In reply to this post by Michel LaBarre
Greetings, Michel LaBarre!

> Problem 1:  Cygwin does not support PATHEXT and really should.

No, it should not. Cygwin is a POSIX environment, and it uses POSIX
conventions to determine if a file is executable somehow.

> PATHEXT is as fundamental component of Windows program execution as PATH.

PATHEXT is a shell (CMD) extension. Some programs do make use of it, notable
file managers and CMD replacements do, but overall, this is a mechanism of
finding the file to execute, not of executing it per se.
You can write your own extension to bash-completion "file-not-found" handler,
if you so desire.

> Problem 2:  Cygwin does not support CR-LF delimiters.

Cygwin, in this case, is a library (newlib), and it doesn't care about
delimiters. This is an application's choice and right to support various EOL's
or not.

> For the same reason, it is unfortunate that CYGWIN/bash does not cope

bash do cope, if you tell it to do. So does Cygwin, if you use text mounts.
Which is a sure way to destroy your data and cause lots of other messy
behavior.

> with both types of line delimiters transparently.

-transparently
+ambiguously

> I have been using and developing system software within Unix since 1974 and
> Windows since the mid-80's.  in more recent years (since the mid-90's) I
> have developed extensive sets of tools (sh/awk/etc..) for corporate and
> public sector clients - on the order of 100,000 lines of code for
> representative projects.  Most had to run under both Solaris and Windows
> environments for which I used the MKS toolkit.

And they do run fine, as long as you are not making stupid mistakes, like
using bogus EOL terminators and expecting the program to work equally on
different systems.


--
With best regards,
Andrey Repin
Thursday, August 4, 2016 15:03:06

Sorry for my terrible english...
Reply | Threaded
Open this post in threaded view
|

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

Andrey Repin
In reply to this post by Kaz Kylheku-5
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...
Reply | Threaded
Open this post in threaded view
|

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

Bill Smith
In reply to this post by Andrey Repin


> > Problem 1:  Cygwin does not support PATHEXT and really should.
>
> No, it should not. Cygwin is a POSIX environment, and it uses POSIX
> conventions to determine if a file is executable somehow.
>
> > PATHEXT is as fundamental component of Windows program execution as
> PATH.
>
> PATHEXT is a shell (CMD) extension. Some programs do make use of it,
> notable file managers and CMD replacements do, but overall, this is a
> mechanism of finding the file to execute, not of executing it per se.
> You can write your own extension to bash-completion "file-not-found"
> handler, if you so desire.
[Bill Smith]

A couple of years ago I was involved with porting a very large code base of makefiles
& shell scripts to work with Cygwin.  In our environment, the main issue was shell scripts calling
*.bat files without the .bat suffix because of the $PATHEXT.  The fix was to change

somescript

To
somescript${BAT}

where ${BAT} would be set to .bat on Windows.

Another option available was to create wrapper shell script.  So I would create a script named "somescript"
that is only in $PATH on Windows and it would look something like this:

#!/bin/sh
adaptman.bat "$@"

Granted our *.bat files are simple and don't have to worry about arguments with spaces.

> > Problem 2:  Cygwin does not support CR-LF delimiters.
>
> Cygwin, in this case, is a library (newlib), and it doesn't care about delimiters.
> This is an application's choice and right to support various EOL's or not.
>
> > For the same reason, it is unfortunate that CYGWIN/bash does not cope

[Bill Smith]

You can tell bash to ignore carriage returns in scripts by doing the following:

set -o igncr
export SHELLOPTS

> > I have been using and developing system software within Unix since
> > 1974 and Windows since the mid-80's.  in more recent years (since the
> > mid-90's) I have developed extensive sets of tools (sh/awk/etc..) for
> > corporate and public sector clients - on the order of 100,000 lines of
> > code for representative projects.  Most had to run under both Solaris
> > and Windows environments for which I used the MKS toolkit.
>
> And they do run fine, as long as you are not making stupid mistakes, like
> using bogus EOL terminators and expecting the program to work equally on
> different systems.
[Bill Smith]
Agreed.  If you need advice on porting scripts to work both in Cygwin and MKS, feel free
to send me email.  

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

Reply | Threaded
Open this post in threaded view
|

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

Andrey Repin
In reply to this post by Michel LaBarre
Greetings, Michel LaBarre!

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

> PATHEXT has been part of Windows

Part of CMD.exe. Not 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.).

Shells =/= Operating system.

> Windows inherently uses file suffixes to associate programs to
> data files, hence CMD files to CMD.exe, VBS to VB, etc..

Right. And wrong at the same time.
There's a hardcoded behavior of CreateProcess to execute .BAT and .CMD files
with cmd.exe. Even ignoring %ComSpec%, as I recall, in case it was
compromised. ShellExecute(Ex), of course, doesn't do that, as it uses
associations to find ways to execute the object.

Yet again, this has no relation to PATHEXT.
As demonstrated by Kaz earlier, just adding an extension to search order will
not make a script executable by the shell.

> All its shells refer to PATHEXT and/or file associations in the registry.

Do NOT mix PATHEXT and file associations, they are NOT the same thing.
PATHEXT is a discovery mechanics, shell associations is an execution
mechanics.

> I have worked with Unix for a long time (1974) and Windows for almost as
> long (1986?).

Then you should know better than to present easily disprovable arguments.

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

Then you just made your life hard for yourself.
If you would NOT change suffixes, but have added them from the start, knowing
that your toolset may be run on Windows, you would have never encountered such
issues.

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

Do you want to know, why Windows developers adopt *NIX tools?
I'll tel you why - because they interoperate in a standardized and predictable
way. With any other tools. You can pipe an output of a Cygwin grep to a
CMD's FOR statement and it'll consume and process it without a hitch.
On the other hand, Windows tools in 99.(9)% of cases are burdensome bunch,
spewing tons of crap and impossible to manage.

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

But it is not approved by Microsoft!!
(You have no idea, how many times people say that, and this is the main reason
the evolution happens outside Windows world.)

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

"Pure Windows programmers" are hell bent on Microsoft tools and see everything
else as a heresy.

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

And it does work. For me, the biggest problem with working with Cygwin apps
from native shells is impossibility to tell CMD to shut the fuck up when I
Ctrl+C the Cygwin script. Always pops with "do you want to terminate batch
file yes no" idiocy. Got so tired that I've moved my wrappers to TCC.
"ON BREAK REM" and no problem.

> You penalise CYGWIN users - not Microsoft. Frankly, that comment
> strikes me as somewhat cavalier.

How the hell you've drawn such a conclusion?
If you have no idea how CMD works, or how to make it behave, ask me. Off list.
This is not a Cygwin question.

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

*You* disagree is the right wording. But we have an equal right to disagree,
too.

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

No. Period. If I want to run foo.bat, I will type "foo.bat". Because otherwise
it may execute any random crap without my full consent.

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

Gosh. Try it yourself.
Make a program calling "CreateProcess('test');" and let's see how it would
execute your test.sh.
Then talk about what is wired into Windows.
(Hint: ShellExecute(Ex) is not a Windows (WinAPI) functionality, it is
ShellAPI functionality. But even ShellExecute(Ex) does not refer to the
PATHEXT.)

> It is a myth that Unix-y programmers work in a vacuum within Windows.

Nice discussion we have here. Making up statements to "disprove" them.

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

May be you should read documentation before making conclusions?
Any Cygwin app initialize with cygwin1.dll, which, you may say, IS THE
"Cygwin" in the essence.
What lets an application a chance to be called a "Cygwin" application. (But
not necessarily allows... but that's a different topic.)
And fstab is managed in the Cygwin layer. As long as you are using POSIX
calls, the Cygwin subsystem will provide the rest.

P.S.
The main obstacle to everyday Windows user like me is path translation.
Not what you were writing in so many words here.
Not an unavoidable obstacle, if you have a powerful [enough] shell tools, but
still an impediment in some case.

P.P.S.
If you do not want to quote the original mail in your reply, take your time to
remove it.
And this list is "no top posting please, thank you".
So, thank you in advance.


--
With best regards,
Andrey Repin
Thursday, August 4, 2016 16:39:20

Sorry for my terrible english...


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

Reply | Threaded
Open this post in threaded view
|

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

Andrey Repin
In reply to this post by Bill Smith
Greetings, Bill Smith!

> A couple of years ago I was involved with porting a very large code base of
> makefiles & shell scripts to work with Cygwin.  In our environment, the main
> issue was shell scripts calling *.bat files without the .bat suffix because
> of the $PATHEXT.

Sounds like it wasn't a *NIX code base.

> The fix was to change

> somescript

> To
> somescript${BAT}

> where ${BAT} would be set to .bat on Windows.

In this case, just changing the calls to use real names would've sufficed.

> Another option available was to create wrapper shell script.  So I would create a script named "somescript"
> that is only in $PATH on Windows and it would look something like this:

> #!/bin/sh
> adaptman.bat "$@"

> Granted our *.bat files are simple and don't have to worry about arguments with spaces.

No, this is a very messy way to do it. Highly prone to backfires.

Correct way would've been (assuming this code base of yours is not purely
Windows, like I thought) is to use same shell scripts it would call otherwise,
instead of bat files, and enhance them to find relevant bits of information if
run under Cygwin, where applicable.
Then discard the .bat files and breathe free at last.


--
With best regards,
Andrey Repin
Thursday, August 4, 2016 17:36:13

Sorry for my terrible english...


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

Reply | Threaded
Open this post in threaded view
|

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

Michel LaBarre
In reply to this post by Vince Rice
Well my first foray into the world of CYGWIN mailing lists has been a lot of fun so far.  Rather than replying to each respondent, I will try to respond to each in one email.  This may be a mistake.   At least people who think I am an idiot will only have one email to delete instead of one per respondent.

Vince Rice: thank you for replying despite the obvious frustration I seem to have caused you.

Vince: my perceived difficulty "in reporting an issue or comment" has more to do with my not wanting to SPAM an entire mailing list.  My expectation was that there might be a less pervasive mechanism to which I could display my ignorance/confusion than the whole wide world of cygwin-interested parties.  The fact that any/every issue gets communicated to everybody may explain the "annoyance" evident in some of the replies I have received.   There will always be newbies - maybe we need a less intrusive means to communicate through.

Vince: regarding your "to you" observations - I was merely quoting the first item in the Cygwin faq.  Perhaps there are ways to mitigate the issues I raised.  Notably, Bill Smith has very helpfully noted the "set -o igncr" for which  I am very grateful - thank you Bill.  As for your experience with GYGWIN Vince, perhaps you have never experienced a need for PATHEXT but having spent 15 years supporting the same KSH/perl/AWK/etc scripts under Solaris and Windows for a few clients, using the MKS toolkit which does support PATHEXT, I apparently took advantage of that support extensively.  My objective was always to make the scripts equally natural to use within each environment.  Under *nix environments, a shell association is given by a #! Directive - very clever and elegant but not part of Windows shells.  The key concern I have been addressing has been that CYGWIN's value is within the context of Windows - remove Windows and there is no reason for CYG"WIN" self-evidently.  For that reason, means to better integrate CYGWIN and Windows will inevitably benefit CYGWIN users.  Further, being a CYGWIN newbie, the initial disconnects between bash and CMD support for PATHEXT and the CR/LF issues in BASH as the first impediments faced by many users (lots of web hits) - if nothing else, perhaps explicit documentation of ways to mitigate these issues would help (Thanks again Bill Smith).

Three isolated *nix-like environments have died under Windows - Interix, POSIX subsystem under NT, and I expect Ubuntu under Win10 because of the lack of integration with Win32.  You can only do so much playing within a sandbox.  The only successful commercial product integrating Unix tools within Windows has been MKS and they do a great job of co-existing with and exploiting Win32 - that is why they are embedded and distributed with dozens of *nix products ported to Windows.  Why would such product vendors be willing to pay big bucks for MKS if CYGWIN is essentially free?  Perhaps, the degree of integration with Win32 is part of the  answer.  More corporate support for CYGWIN might increase financial support for CYGWIN developers and infrastructure.

Doug Henderson:  Thank you for your thoughtfully laid out comments and argument.  Having supported mixed Solaris/Windows-MKS environments, I agree that PATHEXT is not necessarily great but it is part of Windows in the mind of any Windows programmer or admin which is sufficient justification for recognition within CYGWIN shells.  *nix has #! - Windows shells have PATHEXT and registry file-associations.  Your message did note issues inherent to integration with Windows not supporting #!.  Unfortunately PATHEXT and file association is the Windows way.  TAB completion only caters to interactive shells - it does not address the issue of scripts being run in both *nix and Win environments.  As for "being a fool" for not including a suffix when invoking from scripts, two problems arise:  one - ported scripts would then have to support .sh or variants thereof in *nix or use something like  ${BAT} or ${CMD} as noted by Bill Smith - (Thanks again Bill) and  two, if referring to a third party pkg component, one then wires into a script an expectation that a given function will continue to be a CMD or BAT or EXE or whatever whereas that 3rd party package may be independently updated someday to implement that function in a different manner (e.g. CMD to EXE for speed) forcing you to re-release.  (As noted below, my focus has been tool (compiled code and script) invocations from scripts, not low level invocations from an API.)

Bill Smith:  Thanks again.  I have already acknowledged your points wrt PATHEXT and CR/LF.   Regarding PATHEXT, you noted the use of wrapper scripts with the caveat of issues if needing to handle complex parameters - that applies in spades if you consider the syntax of parameters for sh/bash/ksh vs CMD (or other wrappers) - there be dragons!  You wind up with escape characters up the wazoo to say nothing of subtle differences in handling I/O redirection, file descriptors, and ENV inheritance.

Finally, Andrey Repin (if anybody has lasted through all this):  Thank you for your insights.  I fully appreciate the difference between an O/S and a shell though it is apparent that your depth of experience with low level interfaces exceeds mine and is much more current.  Regarding PATHEXT, it is used consistently by enough shells within Windows that it is part of the background by now.  I  admit that I am for the most part referring to scripts in various shells and not tools invoked by low level programs using CreateProcess.  I should have limited my comments to bash rather than CYGWIN.  Lots of people build extensive tool sets never having to delve into low level code.  Bash/sh/ksh/perl are so much better than CMD (why else am I trying to use CYGWIN?) that bash recognising PATHEXT would facilitate the transition (esp since there was a patch posted by somebody years ago which seemed to pass a cursory evaluation).

Thanks to you all.  We can likely let this topic rest for a while.  In the meantime, I will persevere.  I can work with anything and for my current needs I can cobble something that will work.  All those CYGWIN users cannot be wrong after all.  ;-)  

After 41 years of working with Unix (starting with release 6 on 2 mag tapes from Bell Labs on a PDP 11/45 with 256KB), in various hardware/software/consulting companies in Canada and the USA, it still amazes me that Unix has not swept Windows away.  Religious fervour, intolerance, and the variety of sects (a marketing VP once asked me, "ok - if we were to support Unix, which flavour?") have not helped.  Today, easier co-existence with Windows might help enlighten potential converts - I have amazed countless Windows folks with KSH, AWK, and regexp brevity and elegance (let alone VI).  Powershell is great for C#/C++ programmers wanting a break but lethal to admins/integrators/scripters.

Cheers,
Michel

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Vince Rice
Sent: August-04-16 1:40 AM
To: Cygwin Mailing List
Subject: Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

> On Aug 3, 2016, at 8:43 PM, Michel LaBarre wrote:
>
> The CYGWIN site makes it quite difficult to discern how somebody can
> report an issue or comment.

If you think a plainly labeled “Reporting Problems” and “Mailing Lists” in the prominent sidebar is difficult, then I’m afraid it’s only going to get worse from here.

> Problem 1:  Cygwin does not support PATHEXT and really should.
>
> 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.

“To you.” Almost every sentence in that paragraph should have “to you” at the end. I’ve used Cygwin for over a dozen years, and I have never once missed having PATHEXT in mintty/bash.
You can continue to use PATHEXT to your heart’s content in CMD.
Bash isn’t CMD.

> The published solutions in the various FAQs are not satisfactory.

“To you."

> Problem 2:  Cygwin does not support CR-LF delimiters.

Yes it does, although it is heartily suggested they be left behind (pretty much any Windows program can handle Unix line endings but Notepad, and anyone using Notepad has bigger issues than line endings).
Text mounts can be created in Cygwin (although, again, not suggested). There are also a few (non-standard) things in Cygwin’s bash to try to handle CRLF scripts. You can search the archives for more information.

> CYGWIN could be a very smart supplement to that requirement.
> …
> 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.  

No, Cygwin _is_ a very smart supplement to that requirement. You talk as if Cygwin just showed up last week. It’s been around for almost twenty years, is widely used and widely respected.

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

No, _you_ expect to. I don’t. I know that Bash isn’t CMD.

Cygwin is providing a Posix environment on Windows. If you want a Windows environment on Windows, then use CMD. Almost all of Cygwin’s supplied programs work perfectly well in CMD, as long as you remember they’re providing a Posix environment and therefore need Unix paths, etc.



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

Reply | Threaded
Open this post in threaded view
|

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

cyg Simple
Michael,

You need to configure your email client to wrap your text at no more
than 78 characters, 72 would be even better.  It helps quoting what you
write better.

You also need to stop top posting or remove the trailing mail from the
reply if quoting that particular mail isn't necessary.

Cygwin Community,

This conversation has driven me bonkers.  Cygwin is a tool for windows
first and foremost.  It was designed to help make life for those who
support both UNIX and Windows servers a little easier by not having to
convert scripts and utilities.  Cygwin is now trying to be something
more by becoming even more UNIX like.  Some of the changes that have
occurred are presenting havoc on those of us who have used a mix of
applications, some Cygwin runtime and some Windows runtime.  This makes
it difficult as is evidenced by the complaints in this list about ACL
issues.

With the PATHEXT debate Michael (and others before him) is stating that
it would be nice if Cygwin, like its competitors, could use the PATHEXT
variable to determine if the file can be executed by extension.  The
naysayers are stating that it isn't POSIX or UNIX behavior; I agree with
that statement.  I don't agree that Cygwin cannot use this variable to
determine if a file is executable.  Cygwin doesn't have to determine the
program to use, the Windows API has the smarts for that.  All Cygwin
needs to do is to pass the file path to the API to execute the file.
Cygwin even now makes an exception for files ending in .exe; see the
output of 'ls -l /bin/ls' versus 'ls -l /bin/ls*'.

I've stated this to cast my support for using PATHEXT even if it is a
filtered option via the CYGWIN variable.  Michael are you willing to
provide code?

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

Reply | Threaded
Open this post in threaded view
|

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

Erik Soderquist-2
In reply to this post by Michel LaBarre
On Thu, Aug 4, 2016 at 7:43 PM, Michel LaBarre wrote:
> Well my first foray into the world of CYGWIN mailing lists has been
> a lot of fun so far.

Glad you enjoyed it  :)

> Rather than replying to each respondent, I will try to respond to
> each in one email.  This may be a mistake.

It is, as is top-posting.  Top-posting very badly disrupts the
natural continuity of reading the message.  For some readers, top-
posting alone is justification for a bulk-delete.

> At least people who think I am an idiot will only have one email
> to delete instead of one per respondent.

Idiot?  I doubt it.  Misinformed on some topics, yes, but aren't we
all somewhere along the way?  It is usually quite easy to build a
filter to bulk-delete by sender if needs be.  I'm pretty sure most of
us would still prefer inline responses and multiple message over top-
posting by a wide margin.

> Vince: my perceived difficulty "in reporting an issue or comment"
> has more to do with my not wanting to SPAM an entire mailing list.

As this list is the primary support and ideas tool designated,
posting here regarding CYGWIN is not spam.

> ... ... ... having spent 15 years supporting the same
> KSH/perl/AWK/etc scripts under Solaris and Windows for a few
> clients, using the MKS toolkit which does support PATHEXT, I
> apparently took advantage of that support extensively.

I would consider that in and of itself a mistake; however, I was
burned by PATHEXT in my early days with foo.bat, foo.cmd, foo.exe,
foo.com, and foo.vbs all in the same directory, and all doing
different things, and which one I got seemed to be a roll of the dice
so I started using the extension explicitly even in pure DOS/Windows
environments to avoid that confusion and headache.

> My objective was always to make the scripts equally natural to use
> within each environment.  Under *nix environments, a shell
> association is given by a #! Directive - very clever and elegant
> but not part of Windows shells.

I consider that a DOS/Windows failing... DOS did a lot of things
against already established conventions, such as using a backslash
instead of a forward slash as the directory separator, just "to be
different".  As I understand it (I may be wrong), this is one of them.

> The key concern I have been addressing has been that CYGWIN's value
> is within the context of Windows - remove Windows and there is no
> reason for CYG"WIN" self-evidently.  For that reason, means to
> better integrate CYGWIN and Windows will inevitably benefit CYGWIN
> users.  Further, being a CYGWIN newbie, the initial disconnects
> between bash and CMD support for PATHEXT and the CR/LF issues in
> BASH as the first impediments faced by many users (lots of web
> hits) - if nothing else, perhaps explicit documentation of ways to
> mitigate these issues would help (Thanks again Bill Smith).
>
> Three isolated *nix-like environments have died under Windows -
> Interix, POSIX subsystem under NT, and I expect Ubuntu under Win10
> because of the lack of integration with Win32.  You can only do so
> much playing within a sandbox.  The only successful commercial
> product integrating Unix tools within Windows has been MKS and they
> do a great job of co-existing with and exploiting Win32 - that is
> why they are embedded and distributed with dozens of *nix products
> ported to Windows.  Why would such product vendors be willing to
> pay big bucks for MKS if CYGWIN is essentially free?  Perhaps, the
> degree of integration with Win32 is part of the  answer.  More
> corporate support for CYGWIN might increase financial support for
> CYGWIN developers and infrastructure.

There is a paid/commercial version of CYGWIN with Red Hat's backing.
This has been around for quite some time, and I know of several
corporations who have paid for it and deployed it.  People use tools
based on how well the tool fits their needs.  I personally don't
recall having encountered MKS myself, and doubt I would choose to use
it unless an employer was specifically hiring me to work with it.

> Doug Henderson:  Thank you for your thoughtfully laid out comments
> and argument.  Having supported mixed Solaris/Windows-MKS
> environments, I agree that PATHEXT is not necessarily great but it
> is part of Windows in the mind of any Windows programmer or admin
> which is sufficient justification for recognition within CYGWIN
> shells.

I disagree that Windows introducing something inconsistent and
sometimes unpredictable is a good reason to add it to other packages;
I would much sooner educate people on why it was a bad idea, and
poorly implemented, in the first place.

> *nix has #! - Windows shells have PATHEXT and registry file-
> associations.

These are two separate things, best not to conflate them.

> TAB completion only caters to interactive shells - it does not
> address the issue of scripts being run in both *nix and Win
> environments.

This is true.

> ... ... ... not including a suffix when invoking from scripts, two
> problems arise:  one - ported scripts would then have to support
> .sh or variants thereof in *nix or use something like  ${BAT} or
> ${CMD} as noted by Bill Smith - (Thanks again Bill)

This is what I do, I usually use ${suffix} and set at the start of
the script based on the detected environment.  In some cases, there
are multiple, depending on which suffix I need in Windows to avoid
foo.bat/foo.cmd/foo.exe/etc headaches.  Supporting Windows from *nix
systems definitely can be a headache.

> and  two, if referring to a third party pkg component, one then
> wires into a script an expectation that a given function will
> continue to be a CMD or BAT or EXE or whatever whereas that 3rd
> party package may be independently updated someday to implement
> that function in a different manner (e.g. CMD to EXE for speed)
> forcing you to re-release.

When depending on third party pieces, this is always a risk, and not
just for the extension.  For example, CLI options being changed in a
future version will also cause you to have to rerelease, and having
to support multiple different versions forces you to detect which
version happens to be available before using it.  Not ideal by any
means, but a part of the coder's life.

> Bash/sh/ksh/perl are so much better than CMD (why else am I trying
> to use CYGWIN?) that bash recognising PATHEXT would facilitate the
> transition (esp since there was a patch posted by somebody years
> ago which seemed to pass a cursory evaluation).

One of the problems I see with the idea in general is that it would
add a CYGWIN specific different behavior to the shell that would
exist no where else, and anyone who came to depend on it would see
their scripts fail badly and without explanation when trying to port
the same script to any *nix host.  One of the goals of cygwin is to
be as close to a direct Linux-like environment as possible, and so
there are very very few Windows-specific additions.  The only one
coming to my mind at the moment is the -W (captial W) option added to
ps to display the Windows processes in addition to the CYGWIN
processes.

> After 41 years of working with Unix (starting with release 6 on 2
> mag tapes from Bell Labs on a PDP 11/45 with 256KB)

I'm a little envious of this... I started Unix with a mag tape load,
but when I started that was already "this is the legacy, you may
never need this but better to know and not need than need and not
know."



> it still amazes me that Unix has not swept Windows away.  Religious
> fervour, intolerance, and the variety of sects ... have not helped.

Throughout human history, religious fervor and intolerance have been
the source of massive amounts of human stupidity.  Let us be thankful
that in computing, it has not resulted in things far far worse than
Windows.

-- Erik

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

Reply | Threaded
Open this post in threaded view
|

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

Eliot Moss
In reply to this post by cyg Simple
On 8/5/2016 10:12 AM, cyg Simple wrote:

> Cygwin is a tool for windows
> first and foremost.  It was designed to help make life for those who
> support both UNIX and Windows servers a little easier by not having to
> convert scripts and utilities.

Well, that's one point of view.  Mine is that I get the standard tools
of Windows, kind of expected by business colleagues, etc., such as MS
Office and the like, while also getting my familiar (Unix) coding
environment for my classes and research (I am a computer science
professor).  I do maintain some personal scripts across platforms,
but I do not see that as Cygwin's primary purpose.  I would put it
this way, which I think is capture's Cygwin's stated goals:

To provide a POSIX environment (as close as is practical) running
natively under Windows (not within a separate virtual machine),
allowing the vast majority of POSIX compatible programs to be built
on and to run under Cygwin on Windows platforms.

That said, I wouldn't necessarily mind if PATHEXT were supported as
an optional extension, if it makes life easier for some folks.  If
you're going to do that, I think you get a better result by building
it into the cygwin.dll as opposed to making it a feature only of
bash.  I can see some of the arguments against PATHEXT, which is
why I think it would need to be an option.

Regards -- Eliot Moss

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

Reply | Threaded
Open this post in threaded view
|

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

Michel LaBarre
In reply to this post by cyg Simple
Hello cygsimple,

Thanks for the advice regarding line length.
I will try to remember to rein in my margins when emailing to cygwin.

Thanks for your recognition of PATHEXT's potential value;
reassuring to know I am not alone in my delusions.

Regarding providing code, I am somewhat stale (though I spent my first 20 work years
immersed in system code, assembly/C/Algol/Pascal/C++, building firmware for bit-sliced processors, etc.)

The patch to which I referred is one I found while researching the topic;
https://cygwin.com/ml/cygwin/2007-09/msg00127.html is one reference to it.
It is old and likely out of date.

Michel (as opposed to Michael... )



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

Reply | Threaded
Open this post in threaded view
|

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

Corinna Vinschen-2
On Aug  5 11:20, Michel LaBarre wrote:

> Hello cygsimple,
>
> Thanks for the advice regarding line length.
> I will try to remember to rein in my margins when emailing to cygwin.
>
> Thanks for your recognition of PATHEXT's potential value;
> reassuring to know I am not alone in my delusions.
>
> Regarding providing code, I am somewhat stale (though I spent my first 20 work years
> immersed in system code, assembly/C/Algol/Pascal/C++, building firmware for bit-sliced processors, etc.)
>
> The patch to which I referred is one I found while researching the topic;
> https://cygwin.com/ml/cygwin/2007-09/msg00127.html is one reference to it.
> It is old and likely out of date.
That.  Plus, the refusal from cgf is still valid today.  If you see the
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Kaz Kylheku-5
In reply to this post by Michel LaBarre
[private, off-list reply]

Hi Michael,

Do you have some sort of list of detailed requirements implemented by
MKS
tools where Cygwin is different or lacking in some way?

Maybe Cygwin could pick up some of them.

Anyway, about a month ago, when I learned that Cygwin is now under
the Lesser GPL, I started a project called Cygnal (Cygwin Native
Application Library) whose goal is to improve the usefulness
of Cygwin for Windows development.

http://www.kylheku.com/cygnal

However, I have a different angle on it: the perspective is
of developing a native application (which ships native executables,
without any apparent POSIX environment with a shell, commands or any
of that).

I don't need to infuse the Cygwin environment with Windows conventions;
building my program within the POSIX conventions suits me just fine.

However, I don't want the *users* of the program (a binary .exe
accompanied by .dll files, wrapped up in an installer) to be exposed
to POSIX conventions.

With Cygnal, you can develop a single executable file, which works
with POSIX and Windows conventions, simply based on which flavor
of the cygwin1.dll it is linking against.

Cheers ...


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

Reply | Threaded
Open this post in threaded view
|

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

Nellis, Kenneth-3
In reply to this post by Erik Soderquist-2
From: Erik Soderquist
> ... DOS did a lot of things
> against already established conventions, such as using a backslash
> instead of a forward slash as the directory separator, just "to be
> different".

Not just to be different, but to distinguish from slashes used as
command qualifiers (a la VMS), don't you think?

--Ken Nellis
Reply | Threaded
Open this post in threaded view
|

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

Vince Rice
The choice to use slashes as qualifers instead of dashes was “just to be different” as well.

This was ’78-81. VMS wasn’t in Gates’ mind at the time.


> On Aug 5, 2016, at 1:14 PM, Nellis, Kenneth <[hidden email]> wrote:
>
> From: Erik Soderquist
>> ... DOS did a lot of things
>> against already established conventions, such as using a backslash
>> instead of a forward slash as the directory separator, just "to be
>> different".
>
> Not just to be different, but to distinguish from slashes used as
> command qualifiers (a la VMS), don't you think?
>
> --Ken Nellis


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

123