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

[Kaz Kylheku]

Post by Michel LaBarre
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.

Post by Michel LaBarre
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".

Post by Michel LaBarre
 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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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".

Post by Michel LaBarre
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

[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: cygwin-***@cygwin.com [mailto:cygwin-***@cygwin.com] On Behalf Of Kaz Kylheku
Sent: August-03-16 10:55 PM
To: Michel LaBarre
Cc: ***@cygwin.com
Subject: Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

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

[Doug Henderson]

Post by Michel LaBarre
...
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

[Csaba Raduly]

Hi Michel,

Post by Michel LaBarre
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

[Andrey Repin]

Greetings, Michel LaBarre!

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

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.)

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
"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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.)

Post by Michel LaBarre
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.

Post by Michel LaBarre
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

[Andrey Repin]

Greetings, Kaz Kylheku!

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

Post by Kaz Kylheku

Post by Michel LaBarre
 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" %*

Post by Kaz Kylheku
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.

Post by Kaz Kylheku
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.

Post by Kaz Kylheku
Firstly, the binary mode default treatment for files comes
$ 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

[Vince Rice]

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
The published solutions in the various FAQs are not satisfactory.

“To you."

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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

[Michel LaBarre]

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: cygwin-***@cygwin.com [mailto:cygwin-***@cygwin.com] 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

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
The published solutions in the various FAQs are not satisfactory.

“To you."

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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

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

[Eliot Moss]

Post by cyg Simple
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

[Michel LaBarre]

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

[Corinna Vinschen]

Post by Michel LaBarre
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

[cyg Simple]

Post by Corinna Vinschen

Post by Michel LaBarre
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.

I've seen that code and I still think it would be worthwhile to support
PATHEXT.

[Marco Atzeri]

Post by cyg Simple

Post by Corinna Vinschen

Post by Michel LaBarre
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.

I've seen that code and I still think it would be worthwhile to support
PATHEXT.

I have the impression you are really underestimating the
negative consequence to add additional burden on the current code.


Regards
Marco




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

[Herbert Stocker]

On 05.08.2016 17:29, Corinna Vinschen wrote:
If you see the

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

Herbert



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

[cyg Simple]

Post by Corinna Vinschen
If you see the

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

In my opinion this is an issue with stat/lstat coding. In the alpha days
of Cygwin binutils didn't add the .exe to executable files. The problem
that caused was that CMD couldn't execute a perfectly valid executable
even though Cygwin's bash could. The fix is what we have today and it
does cause problems such as you describe. The fact that this scenario
prevails is an indication that the code needs to be revisited. Maybe
even a different method to execute files with extensions given without
the extensions at the command line.

[Michel LaBarre]

Based on the emails under this thread and other items I found, it seems that anomalies
handling program suffixes within CYGWIN are not new. It has been proposed that the
relevant code be re-thought. I suggest that any rethink consider PATHEXT support.

It may be of no interest for CYGWIN users of pure Posix applications and tools never intended
to use, or be used by, Win32 programs as has been pointed out within this thread. Even then,
Windows underpins CYGWIN so its rules percolate up.

For users who wish to exploit the power of CYGWIN tools and shells to control
and supplement Win32 tools, to control and configure Windows and Windows subsystems,
and extensive corporate applications under Windows, PATHEXT (plus the file associations
that determine how to invoke the handler for a given suffix) is a part of the bridge.
In a sense, in this case Windows rules, conventions, and expectations percolate down.

CYGWIN addressing Windows program invocation comprehensively once and for all
might help rationalise things and reduce the anomalous end cases that seem to
crop up while satisfying the needs of hybrid CYGWIN/Win32 users.

As a novice CYGWIN user, It is quite possible that I misunderstand CYGWIN and that inter-operation
with Win32 environments is not an objective in which case perhaps somebody can set me straight
and recommend an alternative. It could very well be that, as one response to me on this thread
alluded, CYGWIN's role is to provide the equivalent of an isolated POSIX VM under Windows
without the VM. Such isolation pretty much excludes Windows developers and integrators and
begs the question as to why host all this POSIX infrastructure within Windows in the first place
especially now that VM support is pervasive and efficient?

I expect that many CYGWIN users in fact blend CYGWIN and Win32 tools to build solutions.

As a novice CYGWIN user, I was first struck by the variety of offshoots from CYGWIN.
Presumably, these offshoots satisfy some un-met needs but must result in dilution of talent and effort.
Maybe I should be looking at one of these but my first cursory looks showed that some
common Unix utilities that I find useful were missing but are in CYGWIN which is why I wound up here.

I really hope to not have offended anybody.

Michel



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

[Herbert Stocker]

Post by Michel LaBarre
It could very well be that, as one response to me on this thread
alluded, CYGWIN's role is to provide the equivalent of an isolated
POSIX VM under Windows without the VM.

Having used Cygwin for a long time, maybe 10 or 13 years, i see
that CYGWIN is *not* an isolated POSIX environment. It brings
POSIX to the OS named "Windows". And i enjoyed its interoperability
a lot. Cygwin EXEs can call Windows EXEs and vice versa, they
put lots of efforts in supporting Windows style ACLs vs. POSIX
ACLs, have Active Directory integration, Translate Windows accounts
to POSIX style accounts, whatever.

And if you are on the C/C++ level, you have the POSIX API, and
when you do a simple #include "Windows.h" you have the Win32
APIL *also*. Both in the same Executable. I used that already.

This interoperability makes CYGWIN so beautiful.

Herbert


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

[Warren Young]

Post by Michel LaBarre
It could very well be that, as one response to me on this thread
alluded, CYGWIN's role is to provide the equivalent of an isolated
POSIX VM under Windows without the VM.

...CYGWIN is *not* an isolated POSIX environment. It brings
POSIX to the OS named "Windows”…

In addition to Herbert’s points, I also want to point out that bidirectional Windows interoperability is a key differentiator for Cygwin vs. “Bash on Windows,” a.k.a. WSL:

https://msdn.microsoft.com/commandline/wsl/

I’ve seen several of these isolationist moves over the years I’ve been using Cygwin, and I think they are essentially harmful to Cygwin. The more you promote Cygwin as being its own little world, the easier it is to replace it with something that truly is isolated: WSL, a Linux VM, or even a Mac.

(If you’re wondering why Macs belong on that list, consider that if you’ve been using Cygwin on Windows because you don’t find the Linux desktop compelling, when it comes time to buy your next desktop, why not choose a first-class desktop computing platform where the Unix command line is not an afterthought, kept isolated as much as possible?)

I do not mean, by this comment, to endorse this idea of implementing PATHEXT in Cygwin. In fact, I’ve made profitable use of the current situation by creating foo.bat and a shell script called foo, which gives me a single command that does the same task under cmd.exe and Cygwin’s shell, using mechanisms native to each. I would not particularly want that ability to disappear.

This is not a simple question of “should Cygwin integrate with Windows?” Your change implies a broad impact which should be carefully considered.

It sounds like you just want Cygwin to work like MKS, Michael, which isn’t going to happen. Cygwin has ~20 years of independent development, all of which were in parallel with MKS. If the developers of Cygwin had wanted to clone MKS, they would have done so long before now.
--
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

[Vince Rice]

Post by Warren Young

Post by Michel LaBarre
It could very well be that, as one response to me on this thread
alluded, CYGWIN's role is to provide the equivalent of an isolated
POSIX VM under Windows without the VM.

...CYGWIN is *not* an isolated POSIX environment. It brings
POSIX to the OS named "Windows”…

https://msdn.microsoft.com/commandline/wsl/
I’ve seen several of these isolationist moves over the years I’ve been using Cygwin, and I think they are essentially harmful to Cygwin. The more you promote Cygwin as being its own little world, the easier it is to replace it with something that truly is isolated: WSL, a Linux VM, or even a Mac.
(If you’re wondering why Macs belong on that list, consider that if you’ve been using Cygwin on Windows because you don’t find the Linux desktop compelling, when it comes time to buy your next desktop, why not choose a first-class desktop computing platform where the Unix command line is not an afterthought, kept isolated as much as possible?)
I do not mean, by this comment, to endorse this idea of implementing PATHEXT in Cygwin. In fact, I’ve made profitable use of the current situation by creating foo.bat and a shell script called foo, which gives me a single command that does the same task under cmd.exe and Cygwin’s shell, using mechanisms native to each. I would not particularly want that ability to disappear.
This is not a simple question of “should Cygwin integrate with Windows?” Your change implies a broad impact which should be carefully considered.
It sounds like you just want Cygwin to work like MKS, Michael, which isn’t going to happen. Cygwin has ~20 years of independent development, all of which were in parallel with MKS. If the developers of Cygwin had wanted to clone MKS, they would have done so long before now.

I have a Mac. I have to run a Windows VM on it due to work software requirements. (Among other things, there’s still not a really good SSMS replacement.) Cygwin is still the first thing I install on a VM.

AFAIC, Cygwin is the perfect blend. I can run Cygwin programs in bash, or I can run Cygwin programs in my Windows command shell choice. That isn’t true of WSL, a Linux VM, or my terminal shell in OSX.
And, as I said earlier in this thread, in a dozen years of using Cygwin, I’ve never once missed not having PATHEXT in bash. _In bash_, I think PATHEXT would cause far (FAR) more harm than good.
--
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

[Corinna Vinschen]

Post by Corinna Vinschen
If you see the

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

I have some doubt here. Cygwin always checks for "foo" first.
Only if it doesn't find "foo", it checks for "foo.exe", then
for "foo.lnk" and last, for backward compat, for "foo.exe.lnk".

In the POSIX realm, "foo" == "foo.exe" == "foo.lnk". The search itself
is indiscriminately, because Cygwin can't know if you're looking for
"foo" or "foo.exe" or a symlink "foo" using the .lnk suffix.


Corinna

[cyg Simple]

Post by Corinna Vinschen

Post by Corinna Vinschen
If you see the

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

I have some doubt here. Cygwin always checks for "foo" first.
Only if it doesn't find "foo", it checks for "foo.exe", then
for "foo.lnk" and last, for backward compat, for "foo.exe.lnk".

Which is the exact cause of the issue.

Post by Corinna Vinschen
In the POSIX realm, "foo" == "foo.exe" == "foo.lnk". The search itself
is indiscriminately, because Cygwin can't know if you're looking for
"foo" or "foo.exe" or a symlink "foo" using the .lnk suffix.

Why do you say "In the POSIX realm"? Only Cygwin does this association.
I understand why it does so but is there a different way to achieve the
same thing with greater accuracy? Maybe we don't want the artificial
symlink of foo == foo.exe all the time. Maybe it is time we drop the
artificial symlink altogether in preference for modifying the scripts
and programs to use .exe when on Windows including Cygwin or perhaps
creating a real symlink for foo.exe to foo. Dropping the artificial
symlink would simplify the code and increase the speed with which it
executes.

As for PATHEXT we can do the following scenario instead.

export PATHEXT="$PATHEXT;.TXT"
vi foo.txt
:set ff=dos
i
a
b
c
<ESC>
:wq
cmd /c foo

[Corinna Vinschen]

Post by cyg Simple

Post by Corinna Vinschen

Post by Corinna Vinschen
If you see the

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

I have some doubt here. Cygwin always checks for "foo" first.
Only if it doesn't find "foo", it checks for "foo.exe", then
for "foo.lnk" and last, for backward compat, for "foo.exe.lnk".

Which is the exact cause of the issue.

Post by Corinna Vinschen
In the POSIX realm, "foo" == "foo.exe" == "foo.lnk". The search itself
is indiscriminately, because Cygwin can't know if you're looking for
"foo" or "foo.exe" or a symlink "foo" using the .lnk suffix.

Why do you say "In the POSIX realm"? Only Cygwin does this association.
I understand why it does so but is there a different way to achieve the
same thing with greater accuracy?

No, sorry, but no. Every time you start to double guess what the
application is looking for in a certain scenario, you lose. See
the example I just made up in

https://cygwin.com/ml/cygwin/2016-08/msg00124.html

And it's just *one* very simple example.


Corinna

[cyg Simple]

Post by Corinna Vinschen

Post by cyg Simple

Post by Corinna Vinschen

Post by Corinna Vinschen
If you see the

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

I have some doubt here. Cygwin always checks for "foo" first.
Only if it doesn't find "foo", it checks for "foo.exe", then
for "foo.lnk" and last, for backward compat, for "foo.exe.lnk".

Which is the exact cause of the issue.

Post by Corinna Vinschen
In the POSIX realm, "foo" == "foo.exe" == "foo.lnk". The search itself
is indiscriminately, because Cygwin can't know if you're looking for
"foo" or "foo.exe" or a symlink "foo" using the .lnk suffix.

Why do you say "In the POSIX realm"? Only Cygwin does this association.
I understand why it does so but is there a different way to achieve the
same thing with greater accuracy?

No, sorry, but no. Every time you start to double guess what the
application is looking for in a certain scenario, you lose. See
the example I just made up in
https://cygwin.com/ml/cygwin/2016-08/msg00124.html
And it's just *one* very simple example.

Agree that looks horrific.

[Corinna Vinschen]

Post by cyg Simple

Post by Corinna Vinschen

Post by Corinna Vinschen
If you see the

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

I have some doubt here. Cygwin always checks for "foo" first.
Only if it doesn't find "foo", it checks for "foo.exe", then
for "foo.lnk" and last, for backward compat, for "foo.exe.lnk".

Which is the exact cause of the issue.

Post by Corinna Vinschen
In the POSIX realm, "foo" == "foo.exe" == "foo.lnk". The search itself
is indiscriminately, because Cygwin can't know if you're looking for
"foo" or "foo.exe" or a symlink "foo" using the .lnk suffix.

Why do you say "In the POSIX realm"? Only Cygwin does this association.
I understand why it does so but is there a different way to achieve the
same thing with greater accuracy? Maybe we don't want the artificial
symlink of foo == foo.exe all the time. Maybe it is time we drop the
artificial symlink altogether in preference for modifying the scripts
and programs to use .exe when on Windows including Cygwin or perhaps
creating a real symlink for foo.exe to foo. Dropping the artificial
symlink would simplify the code and increase the speed with which it
executes.
As for PATHEXT we can do the following scenario instead.
export PATHEXT="$PATHEXT;.TXT"
vi foo.txt
:set ff=dos
i
a
b
c
<ESC>
:wq
cmd /c foo

As you show here, the PATHEXT definition is so that it also contains
file suffixes which require to know the interpreters starting them. To
implement that, the lib would have to either read the registry to know
the connection between suffix and interpreter (which is pretty
convoluted), or it would have to "start the file", aka call ShellExecute
on the file, without knowing what process will come up as child process.
In your example that would be Notepad or Write.

The way this works is just not feasible to be used from inside the DLL,
e.g.:

- ShellExecute does not return a handle to the called process, so the
parent can't wait(2) for it.

- ShellExecute does not allow to specify an environment for the child
process. Cygwin's Windows environment is reduced to minimal size.
Cygwin children inherit the POSIX environment by a simple copy
process. Only when starting a non-Cygwin process, this process gets
a full Windows environment by means of the matching CreateProcess
parameter.

So, if we actually implement PATHEXT, its usage would be limited to
suffixes of binary files and files starting with #!<interpreter>, or we
would have to use a way to start an application which doesn't work well
in a POSIX scenario, or we would have to search the registry for the
suffix linkage. Additionally to searching a variable number of files
for each single file access.

Additionally I would (again?) like to stress that PATHEXT is a feature
of CMD, aka, the shell. It's not a feature of the underlying libs.


Corinna

[Michel LaBarre]

-----Original Message-----
From: cygwin-***@cygwin.com [mailto:cygwin-***@cygwin.com] On Behalf Of Corinna Vinschen
Sent: August-08-16 10:33 AM
To: ***@cygwin.com
Subject: Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

Post by cyg Simple

Post by Corinna Vinschen

Post by Corinna Vinschen
If you see the

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

I have some doubt here. Cygwin always checks for "foo" first.
Only if it doesn't find "foo", it checks for "foo.exe", then
for "foo.lnk" and last, for backward compat, for "foo.exe.lnk".

Which is the exact cause of the issue.

Post by Corinna Vinschen
In the POSIX realm, "foo" == "foo.exe" == "foo.lnk". The search itself
is indiscriminately, because Cygwin can't know if you're looking for
"foo" or "foo.exe" or a symlink "foo" using the .lnk suffix.

Why do you say "In the POSIX realm"? Only Cygwin does this association.
I understand why it does so but is there a different way to achieve the
same thing with greater accuracy? Maybe we don't want the artificial
symlink of foo == foo.exe all the time. Maybe it is time we drop the
artificial symlink altogether in preference for modifying the scripts
and programs to use .exe when on Windows including Cygwin or perhaps
creating a real symlink for foo.exe to foo. Dropping the artificial
symlink would simplify the code and increase the speed with which it
executes.
As for PATHEXT we can do the following scenario instead.
export PATHEXT="$PATHEXT;.TXT"
vi foo.txt
:set ff=dos
i
a
b
c
<ESC>
:wq
cmd /c foo

As you show here, the PATHEXT definition is so that it also contains
file suffixes which require to know the interpreters starting them. To
implement that, the lib would have to either read the registry to know
the connection between suffix and interpreter (which is pretty
convoluted), or it would have to "start the file", aka call ShellExecute
on the file, without knowing what process will come up as child process.
In your example that would be Notepad or Write.

The way this works is just not feasible to be used from inside the DLL,
e.g.:

- ShellExecute does not return a handle to the called process, so the
parent can't wait(2) for it.

- ShellExecute does not allow to specify an environment for the child
process. Cygwin's Windows environment is reduced to minimal size.
Cygwin children inherit the POSIX environment by a simple copy
process. Only when starting a non-Cygwin process, this process gets
a full Windows environment by means of the matching CreateProcess
parameter.

So, if we actually implement PATHEXT, its usage would be limited to
suffixes of binary files and files starting with #!<interpreter>, or we
would have to use a way to start an application which doesn't work well
in a POSIX scenario, or we would have to search the registry for the
suffix linkage. Additionally to searching a variable number of files
for each single file access.
[Michel]
[Michel] #! Is better than nothing but doing PATHEXT fully might put these considerations to rest forever.
[Michel] Fundamentally, the means of invoking a file interpreter in Windows are determined by the registry's file associations;
[Michel] anything else is an assumption.
[Michel] I don't know how cygwin.dll is implemented but the only suffixes that need to be looked up are the ones in PATHEXT and that could be done once could it not?

Additionally I would (again?) like to stress that PATHEXT is a feature
of CMD, aka, the shell. It's not a feature of the underlying libs.
[Michel]
[Michel] PATHEXT is supported by Powershell and VBS. MKS's shells (ksh,sh,perl) also.
[Michel] Likely others since it is considered consistent with Windows.
[Michel] It likely should have been implemented at a lower level but was not.


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


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

[Marco Atzeri]

Post by Corinna Vinschen
So, if we actually implement PATHEXT, its usage would be limited to
suffixes of binary files and files starting with #!<interpreter>, or we
would have to use a way to start an application which doesn't work well
in a POSIX scenario, or we would have to search the registry for the
suffix linkage. Additionally to searching a variable number of files
for each single file access.
[Michel]
[Michel] #! Is better than nothing but doing PATHEXT fully might put these considerations to rest forever.
[Michel] Fundamentally, the means of invoking a file interpreter in Windows are determined by the registry's file associations;
[Michel] anything else is an assumption.
[Michel] I don't know how cygwin.dll is implemented but the only suffixes that need to be looked up are the ones in PATHEXT and that could be done once could it not?
Additionally I would (again?) like to stress that PATHEXT is a feature
of CMD, aka, the shell. It's not a feature of the underlying libs.
[Michel]
[Michel] PATHEXT is supported by Powershell and VBS. MKS's shells (ksh,sh,perl) also.
[Michel] Likely others since it is considered consistent with Windows.
[Michel] It likely should have been implemented at a lower level but was not.

Michel,
your quest is starting to boring me.

If you want this feature, please propose a patch to implement it.
It will be evaluated and we will consider the additional burden (aka
delay) that it will introduce on the current usage.

For my usage of cygwin, your feature request is of no interest.
If I want to run a specific program based on extension I can do
by myself or use cygstart.

Regards
Marco

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

[cyg Simple]

Post by Corinna Vinschen

Post by cyg Simple
As for PATHEXT we can do the following scenario instead.
export PATHEXT="$PATHEXT;.TXT"
vi foo.txt
:set ff=dos
i
a
b
c
<ESC>
:wq
cmd /c foo

As you show here, the PATHEXT definition is so that it also contains
file suffixes which require to know the interpreters starting them. To
implement that, the lib would have to either read the registry to know
the connection between suffix and interpreter (which is pretty
convoluted), or it would have to "start the file", aka call ShellExecute
on the file, without knowing what process will come up as child process.
In your example that would be Notepad or Write.
The way this works is just not feasible to be used from inside the DLL,
- ShellExecute does not return a handle to the called process, so the
parent can't wait(2) for it.
- ShellExecute does not allow to specify an environment for the child
process. Cygwin's Windows environment is reduced to minimal size.
Cygwin children inherit the POSIX environment by a simple copy
process. Only when starting a non-Cygwin process, this process gets
a full Windows environment by means of the matching CreateProcess
parameter.

Sorry, it seems I confused the issue. I was suggesting with this
example that as a Cygwin shell user I could use this technique to start
a file if I so choose without any modification to Cygwin.

Post by Corinna Vinschen
So, if we actually implement PATHEXT, its usage would be limited to
suffixes of binary files and files starting with #!<interpreter>, or we
would have to use a way to start an application which doesn't work well
in a POSIX scenario, or we would have to search the registry for the
suffix linkage. Additionally to searching a variable number of files
for each single file access.

I tried "chmod +x foo.txt; ./foo.txt" but that results in Cygwin
assuming the text file is a script and executing each line of the file.
If PATHEXT were used only to determine that the file should be passed to
ShellExecute instead it might be beneficial but since I can easily just
do "cmd /c foo.txt" then probably not so much.

Post by Corinna Vinschen
Additionally I would (again?) like to stress that PATHEXT is a feature
of CMD, aka, the shell. It's not a feature of the underlying libs.

And other application type programs and libraries. WSH for one makes
use of PATHEXT.
https://msdn.microsoft.com/en-us/library/fd7hxfdd(v=vs.84).aspx

[Marco Atzeri]

Post by cyg Simple

Post by Corinna Vinschen
So, if we actually implement PATHEXT, its usage would be limited to
suffixes of binary files and files starting with #!<interpreter>, or we
would have to use a way to start an application which doesn't work well
in a POSIX scenario, or we would have to search the registry for the
suffix linkage. Additionally to searching a variable number of files
for each single file access.

I tried "chmod +x foo.txt; ./foo.txt" but that results in Cygwin
assuming the text file is a script and executing each line of the file.
If PATHEXT were used only to determine that the file should be passed to
ShellExecute instead it might be beneficial but since I can easily just
do "cmd /c foo.txt" then probably not so much.

try "cygstart foo.txt"


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

[cyg Simple]

Post by Marco Atzeri

Post by cyg Simple

Post by Corinna Vinschen
So, if we actually implement PATHEXT, its usage would be limited to
suffixes of binary files and files starting with #!<interpreter>, or we
would have to use a way to start an application which doesn't work well
in a POSIX scenario, or we would have to search the registry for the
suffix linkage. Additionally to searching a variable number of files
for each single file access.

I tried "chmod +x foo.txt; ./foo.txt" but that results in Cygwin
assuming the text file is a script and executing each line of the file.
If PATHEXT were used only to determine that the file should be passed to
ShellExecute instead it might be beneficial but since I can easily just
do "cmd /c foo.txt" then probably not so much.

try "cygstart foo.txt"

And then you can do:

ln -s foo.txt foo
cygstart foo

OR you can do

alias foo="cygstart foo.txt"
foo

[Erik Soderquist]

Post by cyg Simple
I tried "chmod +x foo.txt; ./foo.txt" but that results in Cygwin
assuming the text file is a script and executing each line of the file.
If PATHEXT were used only to determine that the file should be passed to
ShellExecute instead it might be beneficial but since I can easily just
do "cmd /c foo.txt" then probably not so much.

That is the behavior I would expect in any *nix environment, and
therefore consider the correct behavior within cygwin.

Additionally, starting a text editor for foo.txt is not a function of
PATHEXT, but rather of file association. In CMD.EXE,

C:\tmp>echo some text >foo.txt

C:\tmp>foo
'foo' is not recognized as an internal or external command,
operable program or batch file.

C:\tmp>echo echo some text >foo.cmd

C:\tmp>foo

C:\tmp>echo some text
some text

C:\tmp>

PATHEXT looks for *executable* files, not file association. I warned
previously in this thread about getting the two confused.

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

[cyg Simple]

Post by Erik Soderquist

Post by cyg Simple
I tried "chmod +x foo.txt; ./foo.txt" but that results in Cygwin
assuming the text file is a script and executing each line of the file.
If PATHEXT were used only to determine that the file should be passed to
ShellExecute instead it might be beneficial but since I can easily just
do "cmd /c foo.txt" then probably not so much.

That is the behavior I would expect in any *nix environment, and
therefore consider the correct behavior within cygwin.

But any text file, regardless of the mode, regardless of #! first line
will be executed at least by bash; I have tested the other shells. This
isn't expected behavior as I see it.

$ uname -a
CYGWIN_NT-10.0 HAL2002 2.5.2(0.297/5/3) 2016-06-23 14:29 x86_64 Cygwin

$ bash --version
GNU bash, version 4.3.42(4)-release (x86_64-unknown-cygwin)

Post by Erik Soderquist
Additionally, starting a text editor for foo.txt is not a function of
PATHEXT, but rather of file association. In CMD.EXE,
C:\tmp>echo some text >foo.txt
C:\tmp>foo
'foo' is not recognized as an internal or external command,
operable program or batch file.
C:\tmp>echo echo some text >foo.cmd
C:\tmp>foo
C:\tmp>echo some text
some text
C:\tmp>
PATHEXT looks for *executable* files, not file association. I warned
previously in this thread about getting the two confused.

Thanks for stating this emphasis again. I overlooked it the first time.
I'm satisfied that PATHEXT shouldn't be used to determine an executable
file. I'm not satisfied that we should continue with the .exe
artificial symlink for the same reasons we shouldn't use PATHEXT.
Because of the amount of time to port scripts and software to use the
.exe suffix for executable files it should be an optional configuration
that is on by default with a scheduled deadline (two or three years) to
make it off by default.

[Helmut Karlowski]

---------------------------------------------------

Post by cyg Simple
file. I'm not satisfied that we should continue with the .exe
artificial symlink for the same reasons we shouldn't use PATHEXT.
Because of the amount of time to port scripts and software to use the
.exe suffix for executable files it should be an optional configuration
that is on by default with a scheduled deadline (two or three years) to
make it off by default.

Basically I'd agree. In this case any cygwin-prg that should be
executable by windows would need a symlink to the .exe-version.

Or hook into windows' findfirst/findnext ;)
Would PATHEXT=%PATHEXT%;. be a good idea?

-Helmut


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

[Erik Soderquist]

Post by cyg Simple

Post by Erik Soderquist

Post by cyg Simple
I tried "chmod +x foo.txt; ./foo.txt" but that results in Cygwin
assuming the text file is a script and executing each line of the file.
If PATHEXT were used only to determine that the file should be passed to
ShellExecute instead it might be beneficial but since I can easily just
do "cmd /c foo.txt" then probably not so much.

That is the behavior I would expect in any *nix environment, and
therefore consider the correct behavior within cygwin.

But any text file, regardless of the mode, regardless of #! first line
will be executed at least by bash; I have tested the other shells. This
isn't expected behavior as I see it.

... that should not work, but I've confirmed it does in some shells...

***@localhost /tmp
$ echo echo meow >foo.txt

***@localhost /tmp
$ ls -l foo.txt
-rw-r--r-- 1 user Domain Users 10 Aug 9 12:37 foo.txt

***@localhost /tmp
$ ./foo.txt
meow

***@localhost /tmp
$ chmod a-x foo.txt

***@localhost /tmp
$ ./foo.txt
meow

***@localhost /tmp
$ ksh
***@localhost:/tmp $ ./foo.txt
ksh: ./foo.txt: can't execute: Permission denied
126|***@localhost:/tmp $ ^D

***@localhost /tmp
$ dash
\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n$ ./foo.txt
meow
\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n$
***@localhost /tmp
$ uname -a ; bash --version
CYGWIN_NT-10.0 localhost 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64 Cygwin
GNU bash, version 4.3.42(4)-release (x86_64-unknown-cygwin)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

***@localhost /tmp
$



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

[Andrey Repin]

Greetings, Erik Soderquist!

Post by Erik Soderquist
PATHEXT looks for *executable* files, not file association. I warned
previously in this thread about getting the two confused.

Your statement is confusing. If not contradictory.
PATHEXT tells the shell to consider these file extensions executable.
If you create a file association for ".sh" and add ".SH" to pathext, CMD will
happily execute it, and in the current console.
--
With best regards,
Andrey Repin
Wednesday, August 10, 2016 03:48:44

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

[Warren Young]

Post by Andrey Repin

Post by Erik Soderquist
PATHEXT looks for *executable* files, not file association. I warned
previously in this thread about getting the two confused.

Your statement is confusing. If not contradictory.
PATHEXT tells the shell to consider these file extensions executable.
If you create a file association for ".sh" and add ".SH" to pathext, CMD will
happily execute it, and in the current console.

I think he means that if PATHEXT support appears in Cygwin (whether in the DLL or just in Bash) that you would have to chmod +x any files you want it to apply to. The existence of the file’s extension in PATHEXT alone would not be enough.
--
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

[cyg Simple]

Post by Warren Young

Post by Andrey Repin

Post by Erik Soderquist
PATHEXT looks for *executable* files, not file association. I warned
previously in this thread about getting the two confused.

Your statement is confusing. If not contradictory.
PATHEXT tells the shell to consider these file extensions executable.
If you create a file association for ".sh" and add ".SH" to pathext, CMD will
happily execute it, and in the current console.

I think he means that if PATHEXT support appears in Cygwin (whether in the DLL or just in Bash) that you would have to chmod +x any files you want it to apply to. The existence of the file’s extension in PATHEXT alone would not be enough.

No, adding a .sh to PATHEXT will not execute the file.
No, doing a chmod +x will not cause CMD to execute the file either even
if the extension is in the PATHEXT list.

You must associate the .sh to the executable to consume it and once you
do that association PATHEXT is meaningless.

[Erik Soderquist]

Post by Andrey Repin
Greetings, Erik Soderquist!

Post by Erik Soderquist
PATHEXT looks for *executable* files, not file association. I warned
previously in this thread about getting the two confused.

Your statement is confusing. If not contradictory.
PATHEXT tells the shell to consider these file extensions executable.
If you create a file association for ".sh" and add ".SH" to pathext, CMD will
happily execute it, and in the current console.

PATHEXT is very simply a list of extensions CMD.EXE will automatically
append to the given filename when searching the PATH for a command to
execute. Once a filename+extension is found, CMD.EXE still needs to
know what to do with the given file to be able to execute it.

In the case of .bat and .cmd files, CMD.EXE knows these are lists of
commands to be executed in order.

In the case of .exe files, CMD.EXE knows that these files are
executable unto themselves.

When CMD.EXE finds a file with an extension in the PATHEXT list to
match the extension-less request, it considers the search for the
requested command complete, and at this point PATHEXT has served its
purpose. CMD.EXE then looks to the execution of the command, and this
is where File Associations come in when the extension is not already
natively known to CMD.EXE, and are a partial equivalent to *nix's #!
line in script files. For example, .VBS is considered executeable,
but CMD.EXE has to look up under File Associations *how* to execute
it. (I do not remember exactly how, but to prove a point years ago,
I modified my registry so that .txt was considered 'executable' in the
same way .VBS is, and the execute method was "edit.com %*" (I think).
This had very annoying results since I also put .txt as the first
extension for PATHEXT, and so foo.txt was opened in edit.com rather
than foo.bat being run).

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

[Hans-Bernhard Bröker]

Post by Andrey Repin
PATHEXT tells the shell to consider these file extensions executable.

No. That's what file associations do. cygstart will apply those where
needed, so let's consider that aspect of the case closed, shall we?

PATHEXT has just _one_ job, in those few tools that even use it: it
saves one the burden of referring to a file by its actual name. It's
what makes a given command of just

foo.bar

execute the first reachable one in this list


foo.bar
foo.bar.com
foo.bar.exe
foo.bar.bat
foo.bar.cmd
foo.bar.vbs
foo.bar.vbe
foo.bar.js
...

in the current directory (unconditionally!), or the %PATH%.

So the only thing one has to do in order not to need PATHEXT support is
to call all files by their full names, which a careful script programmer
should always be doing anyway. So PATHEXT gains you nothing in
well-written scripts.

That leaves the interactive command line as a possible use case to
benefit from PATHEXT. I say Bash <Tab> completion runs circles around
that any day.

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

[Andrey Repin]

Greetings, Hans-Bernhard Bröker!

Post by Erik Soderquist

Post by Andrey Repin
PATHEXT tells the shell to consider these file extensions executable.

PATHEXT is very simply a list of extensions CMD.EXE will automatically
append to the given filename when searching the PATH for a command to
execute. Once a filename+extension is found, CMD.EXE still needs to
know what to do with the given file to be able to execute it.
No. That's what file associations do. cygstart will apply those where
needed, so let's consider that aspect of the case closed, shall we?
PATHEXT has just _one_ job, in those few tools that even use it: it
saves one the burden of referring to a file by its actual name. It's
what makes a given command of just

Yes, sorry. I was slightly confused myself.
I rechecked my facts afterward, and, indeed, cmd was successful in executing a
script through file association, given the name including extension, even
though I explicitly removed the extension from PATHEXT and respawned the
shell to be absolutely sure.

The point about <Tab>'ing of course makes PATHEXT less and less appealing in
its native form.


--
With best regards,
Andrey Repin
Thursday, August 11, 2016 00:01:14

Sorry for my terrible eng

[Andrey Repin]

Greetings, Corinna Vinschen!

Post by Corinna Vinschen

Post by cyg Simple
As for PATHEXT we can do the following scenario instead.
export PATHEXT="$PATHEXT;.TXT"
vi foo.txt
:set ff=dos
i
a
b
c
<ESC>
:wq
cmd /c foo

As you show here, the PATHEXT definition is so that it also contains
file suffixes which require to know the interpreters starting them. To
implement that, the lib would have to either read the registry to know
the connection between suffix and interpreter (which is pretty
convoluted), or it would have to "start the file", aka call ShellExecute
on the file, without knowing what process will come up as child process.
In your example that would be Notepad or Write.
The way this works is just not feasible to be used from inside the DLL,
- ShellExecute does not return a handle to the called process, so the
parent can't wait(2) for it.

ShellExecuteEx does, but it will not help you a single bit.

Post by Corinna Vinschen
- ShellExecute does not allow to specify an environment for the child
process. Cygwin's Windows environment is reduced to minimal size.
Cygwin children inherit the POSIX environment by a simple copy
process. Only when starting a non-Cygwin process, this process gets
a full Windows environment by means of the matching CreateProcess
parameter.

ShellExecuteEx does, but…

Post by Corinna Vinschen
So, if we actually implement PATHEXT, its usage would be limited to
suffixes of binary files and files starting with #!<interpreter>, or we
would have to use a way to start an application which doesn't work well
in a POSIX scenario, or we would have to search the registry for the
suffix linkage. Additionally to searching a variable number of files
for each single file access.
Additionally I would (again?) like to stress that PATHEXT is a feature
of CMD, aka, the shell. It's not a feature of the underlying libs.

Add to that, ShellExecute(Ex) can't bind to the current console.
Even if the starting program is a console app, it will, always, create a new
console.
Alternative is to manually parse registry, like CMD apparently does, and
directly find the app to execute.
It's not very convoluted. Thankfully THIS part of Windows is fairly
straightforward and - for the present task - well-documented.
All you have to do is

1. lookup the name of the associated "handler" for a given ".ext"... In two
places... (user registry first, then system);
2. for the given "handler" key, lookup its default "action" value;
(often "open", but not always; many, so many implementors stupidly assume that
"open" is always the default action, while documentation explicitly states
that if you just want to call default action, don't pass any action at all!
And so they call ShellExecuteEx, like white men, but then defeat all their
good by passing an explicit "open" to it...)
3. for the found "action" value lookup two values:
a) "handler"/"action"/shell/command/@ - command to execute;
b) "handler"/"action"/shell/command/Path - additional search path;
4. If Path value exists, it should be prepended to the system's %PATH% for
about to be spawned process;
5. If command line contains "%1", it should be substituted by the script name
(if not, the script name simply appended to the end of exec line);
6. If command line contains "%*", it should be replaced by the "executing"
script arguments, as passed;
7. Finally, the constructed abomination should be executed.

Frankly, I've long since wanted to have ability to directly "execute" some of
the foreign scripts from Cygwin terminal.
If something like PATHEXT is implemented, I'd rather like to see it as the way
to bridge Cygwin to the native execution options, rather than to confuse
everyone by executing files at random.


--
With best regards,
Andrey Repin
Wednesday, August 10, 2016 03:04:53

Sorry for my ter

[Corinna Vinschen]

Post by Andrey Repin
Greetings, Corinna Vinschen!

Post by Corinna Vinschen

Post by cyg Simple
As for PATHEXT we can do the following scenario instead.
export PATHEXT="$PATHEXT;.TXT"
vi foo.txt
:set ff=dos
i
a
b
c
<ESC>
:wq
cmd /c foo

As you show here, the PATHEXT definition is so that it also contains
file suffixes which require to know the interpreters starting them. To
implement that, the lib would have to either read the registry to know
the connection between suffix and interpreter (which is pretty
convoluted), or it would have to "start the file", aka call ShellExecute
on the file, without knowing what process will come up as child process.
In your example that would be Notepad or Write.
The way this works is just not feasible to be used from inside the DLL,
- ShellExecute does not return a handle to the called process, so the
parent can't wait(2) for it.

ShellExecuteEx does, but it will not help you a single bit.

Post by Corinna Vinschen
- ShellExecute does not allow to specify an environment for the child
process. Cygwin's Windows environment is reduced to minimal size.
Cygwin children inherit the POSIX environment by a simple copy
process. Only when starting a non-Cygwin process, this process gets
a full Windows environment by means of the matching CreateProcess
parameter.

ShellExecuteEx does, but


Post by Corinna Vinschen
So, if we actually implement PATHEXT, its usage would be limited to
suffixes of binary files and files starting with #!<interpreter>, or we
would have to use a way to start an application which doesn't work well
in a POSIX scenario, or we would have to search the registry for the
suffix linkage. Additionally to searching a variable number of files
for each single file access.
Additionally I would (again?) like to stress that PATHEXT is a feature
of CMD, aka, the shell. It's not a feature of the underlying libs.

Add to that, ShellExecute(Ex) can't bind to the current console.
Even if the starting program is a console app, it will, always, create a new
console.

Plus, any kind of IO redirection won't work.

Sorry, but I won't implement anything like this in the DLL. It's just
not what the DLL is for. If you want to start any kind of file like
this, use "cygstart". That's what it has been made for.


Corinna

[cyg Simple]

Post by cyg Simple
Maybe we don't want the artificial
symlink of foo == foo.exe all the time. Maybe it is time we drop the
artificial symlink altogether in preference for modifying the scripts
and programs to use .exe when on Windows including Cygwin or perhaps
creating a real symlink for foo.exe to foo. Dropping the artificial
symlink would simplify the code and increase the speed with which it
executes.

Corinna, you didn't respond to this part of my post.

[Erik Soderquist]

Post by Herbert Stocker

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

Were you testing for the existence of a *directory* (
/dir/subdir/something/. ) or for anything named *something* in
/dir/subdir/ ?

And what call were you using? It was my understanding that the foo ==
foo.exe == foo.lnk == foo.exe.lnk was only applied when attempting to
execute something... (is my understanding wrong?)

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

[Corinna Vinschen]

Post by Erik Soderquist

Post by Herbert Stocker

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

Were you testing for the existence of a *directory* (
/dir/subdir/something/. ) or for anything named *something* in
/dir/subdir/ ?
And what call were you using? It was my understanding that the foo ==
foo.exe == foo.lnk == foo.exe.lnk was only applied when attempting to
execute something... (is my understanding wrong?)

Yes. It's also applied when stat'ing si or access'ing something. The
same rules apply. Consider:

if (access ("foo", X_OK) == 0)
execve ("foo", ...);
else
error ("foo not executable");

Consider that every call of the application has some reason Cygwin
just can NOT double guess. If you skip the .exe/.lnk tests, you're\
basically doomed in one scenario or the other.

Been there, done that, no joy.


Corinna

[Erik Soderquist]

Post by Erik Soderquist

Post by Herbert Stocker

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

Were you testing for the existence of a *directory* (
/dir/subdir/something/. ) or for anything named *something* in
/dir/subdir/ ?
And what call were you using? It was my understanding that the foo ==
foo.exe == foo.lnk == foo.exe.lnk was only applied when attempting to
execute something... (is my understanding wrong?)

I'm wrong, the following test case demontrates that clearly.

$ rm -f /tmp/foo*

$ if [ -e /tmp/foo ] ; then echo yes ; else echo no ; fi
no

$ touch /tmp/foo.exe

$ if [ -e /tmp/foo ] ; then echo yes ; else echo no ; fi
yes

$



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

[Warren Young]

Post by Erik Soderquist

Post by Erik Soderquist

Post by Herbert Stocker

Post by Corinna Vinschen
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.

Moreso, this code has recently broken my C++ code in Cygwin.
It tried to see if a directory /dir/subdir/something existed,
and Cygwin said yes because it found a /dir/subdir/something.exe .
So my program failed.

Were you testing for the existence of a *directory* (
/dir/subdir/something/. ) or for anything named *something* in
/dir/subdir/ ?

[snip]

Post by Erik Soderquist
$ touch /tmp/foo.exe
$ if [ -e /tmp/foo ] ; then echo yes ; else echo no ; fi
yes

Yes, but:

$ if [ -d /tmp/foo ] ; then echo yes ; else echo no ; fi
no

The existence check is because foo == foo.exe == foo.lnk under Cygwin, but the original complaint came from someone checking for a directory. So, the lesson is, fix the stat(2)/test(1) call, don’t change Cygwin to cope with a bad test.
--
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

[Erik Soderquist]

Post by Michel LaBarre
Well my first foray into the world of CYGWIN mailing lists has been
a lot of fun so far.

Glad you enjoyed it :)

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
... ... ... 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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
*nix has #! - Windows shells have PATHEXT and registry file-
associations.

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

Post by Michel LaBarre
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.

Post by Michel LaBarre
... ... ... 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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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."

Post by Michel LaBarre
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

[Nellis, Kenneth]

From: Erik Soderquist

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

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

Post by Nellis, Kenneth
From: Erik Soderquist

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

[Michel LaBarre]

Back-slashes pre-date Bill. Can't blame him for that one.

Before Bill Gates there was "CP/M" launched by Digital Research - basically a bunch of nerd-hippies in Seattle. IBM was looking to license it for a low end machine it was developing (ominous background music appropriate at this point).

Gary Kildall, head of DR basically, blew them off.

Bill Gates found out about IBM's project and knew of a CP/M knock-off which he bought for $75,000 (I have heard other amounts) which he then licensed to IBM.

The IBM PC came out and retarded the industry in a major way (640K limit, TSR programs, etc.) for 10+ years but 30 years later contributed to fighting malaria in Africa. Go figure.

CP/M, MP/M, and DOS were not really an O/S - just a collection of drivers with veneer-thin interfaces.

-----Original Message-----
From: cygwin-***@cygwin.com [mailto:cygwin-***@cygwin.com] On Behalf Of Vince Rice
Sent: August-05-16 2:45 PM
To: ***@cygwin.com
Subject: Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

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.


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

[Eliot Moss]

Post by Nellis, Kenneth
From: Erik Soderquist

Post by 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?

Maybe ... but my first thought is that they did it to avoid
copyright lawsuits ...

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

[Csaba Raduly]

Post by Nellis, Kenneth
From: Erik Soderquist

Post by 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?

The roots of MS-DOS can be traced (via 86-DOS) to CP/M, not VMS.
Incidentally, CP/M also uses forward slashes for the program's options.

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

[Warren Young]

Post by Michel LaBarre
Well my first foray into the world of CYGWIN mailing lists has been a lot of fun so far.

You can’t expect to come into a well-established community and expect no push-back when you insist that they make a wide-reaching change just to suit your wishes.

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

Yes, it is indeed a mistake. It breaks threading. Take a look at the thread view for this list’s mailing list archives:

https://cygwin.com/ml/cygwin/2016-08/threads.html

Replying like you have is tolerable at the time of the reply, because the thread participants have the context in their heads at that time, but someone coming along later and trying to follow the threads of the conversation get confused when all the threads get gathered back up like this.

You’re making macramé out of our threads here. Stop it.

Post by Michel LaBarre
my perceived difficulty "in reporting an issue or comment" has more to do with my not wanting to SPAM an entire mailing list.

I think you don't understand how community support fundamentally works.

The community support model only works when people post their problems publicly so that they can be archived and searched along with the public answers to those problems. That way, many other people can learn the answer in real-time as they follow the conversation, and still more people can learn it later by searching the archives. Thus, the person or persons who spent their limited time to answer the question benefit all those who read the answer, not just the person who originally asked.

(The benefit to me from writing this very answer is to reinforce the mores of this community, not solely to educate you.)

If you want to send private email to someone to get tech support, now you’re taking up that one person’s time for your sole benefit. That is a bigger “ask” than a request for public community support, so the benefit to the person replying naturally must be greater. In some cases, this means asking a friend with whom you already have a mutually beneficial relationship, and in others it means buying a support contract.

This is why you generally see private tech support offered only by commercial software providers. Part of what you’re buying is the right to demand a slice of one person’s time for your sole benefit.

Post by Michel LaBarre
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.

That wish not to publicly embarrass yourself is what drives some people to search the mailing list archives before posting. Hint.

Others take advantage of the phenomenon known as Cunningham’s Law, which is that the fastest way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.

See also https://xkcd.com/386/

Post by Michel LaBarre
The fact that any/every issue gets communicated to everybody may explain the "annoyance" evident in some of the replies I have received.

No, the annoyance comes from insisting that your opinion is right in the face of ~20 years and millions (?) of users’ experience to the contrary.

More importantly here is that your personal preference goes against the preferences of those writing the code. Open Source is a do-ocracy: those who do the work make the rules. Unless you’re going to fork Cygwin and change it to behave the way you want, you’re going to have to either accept such judgements as final or be more persuasive than you have been. Insisting louder is a poor form of persuasion.

I believe I can best describe my feeling for your PATHEXT idea as ambivalence. I would not try to block it as an optional feature, but I would be irritated if it suddenly became the default behavior of either cygwin1.dll or Cygwin Bash.

Post by Michel LaBarre
...to make the scripts equally natural to use within each environment.

Have you considered writing a foo.bat wrapper for every foo shell script that you want to run the same in both environments?

As I pointed out in a prior reply, the ability to have a “foo” command achieve the same ends via different means under cmd.exe vs Cygwin Bash is a feature of Cygwin, not a bug. Where you want the two environments to share an implementation, you can build some kind of bridge, as with my foo.bat idea, though there are certainly other ways to go about it.

Post by Michel LaBarre
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.

WSL left beta just this week, and you’ve already got its grave marker carved and installed? Wow.

Microsoft replaced the POSIX subsystem with their Interix purchase because Interix was more functional.

Interix/SFU died because it was first commercial — a speed-bump in the way of wide adoption — then it was only available in the more expensive versions of Windows, and finally, late in the game when it finally became a free download it still had all the interop weaknesses of NT subsystems, owing to the way the NT kernel keeps them mutually isolated.

And yes, that isolation is going to be a speed-bump to WSL adoption, too. But, WSL has several things going for it that neither the POSIX subsystem or SFU had, the biggest of which are native ELF support and the Ubuntu package repository. I predict that WSL is going to woo away a whole bunch of Cygwin users who simply don’t need tight Windows integration.

I predict that the biggest contingent will be web developers, since the only integration you need in that case is at the filesystem and TCP/IP levels, which WSL provides. For such users, WSL will be faster and a closer match to their eventual deployment environment than Cygwin, so it’s a clear win.

Those WSL adopters will entrain quite a few others who might also be better served by Cygwin, all things considered, but who will use WSL instead because WSL appears somewhere else in their life first.

Post by Michel LaBarre
You can only do so much playing within a sandbox.

Yes, but “so much” happens to amount to many billions of dollars worth of value to the computing industry, via virtualization, containerization, and sandboxing.

Isolation is not always a bad thing.

Post by Michel LaBarre
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.

MKS predates Cygwin by quite a long stretch, so I’d bet a lot of their customer base comes from those they captured early on, and that they’re now living mainly off their prior lock-in, rather than any inherent value to the platform.

How often do you see raw newbies saying, “Hey, I think I’ll go buy MKS instead of downloading Cygwin!” (Or Linux, or WSL, or anything else free.)

Your argument reminds me of all the commercial Unix vs Linux flamewars of the mid 1990s. You saw how that went. It takes more than a few technical advantages to overcome “free and adequate,” and Cygwin surpassed “adequate” sometime in its beta stages.

Post by Michel LaBarre
Andrey Repin: 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.

Additionally, he’s part of the do-ocracy around here, so you’re going to have to at least take his opinions into account when planning what you’re going to do next.

Post by Michel LaBarre
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.

The Unix Wars did a lot of damage, as did all that time in the late 80’s and early 90’s when it took $1,000 to even get started with Unix on PCs. Then, as the Unix world was about to be saved from going down the drain by Linux and the BSDs, you had USL suing BSDI and SCO suing major Linux users.

If the Unix world had gotten behind the OSS Linux/BSD movement as soon as it appeared, instead of waiting until they’d poisoned their own pond for a decade, we might never have lost the Unix workstation market and all the software that went along with that.

The miracle is that Linux and the BSDs were able to rescue as much as they did. Without them, Unix would have slipped wholly under the waves a decade or two ago.

Sure, we’d have had the occasional Solaris installation still chugging along, but that’s no more “continued success” than is the fact that there are VMS, OS/390, and OS/2 boxes still in service.

Did you know that DEC’s VT terminal business was sold off to another company in 1995, and that they only left the business this year?

http://www.boundlessterminals.com/

It takes more than an entrenched/imprisoned installed base to maintain a healthy marketplace.

Post by Michel LaBarre
easier co-existence with Windows might help enlighten potential converts

You’ve got your cause and effect swapped.

Cygwin is not pushing people to try Linux, the BSDs, or even commercial Unix. The explosion first of the web and then of cloud computing, driven by the availability of the free *ixes, is driving new users into the market for Cygwin.

Therefore, the best thing Cygwin can do is what it is already doing: emulate Linux while doing the best it can to interoperate with native Windows.

That order is key: where there is a conflict, Cygwin should follow Linux, not break compatibility or introduce behaviors that will be strange to the Linux/BSD natives just to make it behave more like Windows.

Post by Michel LaBarre
Powershell is great for C#/C++ programmers wanting a break but lethal to admins/integrators/scripters.

I don’t get PowerShell at all. It seems to me that it’s basically just a REPL for a dialect of C#. If I wanted to program in C#, I’d fire up Visual Studio. Microsoft promised me a better shell, not a C# REPL.

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

[Warren Young]

Post by Warren Young

Post by Michel LaBarre
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.

WSL left beta just this week

Nope, still beta:

https://msdn.microsoft.com/commandline/wsl/install_guide

Maybe we can let it get to 3.0 — the traditional point where Microsoft finally gets it right — before pronouncing its doom?
--
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

[Andrey Repin]

Greetings, Michel LaBarre!

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

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
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.

Post by Michel LaBarre
with both types of line delimiters transparently.

-transparently
+ambiguously

Post by Michel LaBarre
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

Sor

[Bill Smith]

Post by Andrey Repin

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

Post by Michel LaBarre
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.

Post by Andrey Repin

Post by Michel LaBarre
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.

Post by Michel LaBarre
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

Post by Andrey Repin

Post by Michel LaBarre
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

[Andrey Repin]

Greetings, Bill Smith!

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

Post by Bill Smith
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.

Post by Bill Smith
Another option available was to create wrapper shell script. So I would create a script named "somescript"
#!/bin/sh
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

[Kaz Kylheku]

[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