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

[Andrey Repin <anrdaemon at yandex dot ru>]

Greetings, Michel LaBarre!

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

> PATHEXT has been part of Windows

Part of CMD.exe. Not Windows.

> for as long as I can remember - back to the mid-80's - used by shells that
> run under windows (e.g. CMD, PowerShell, VBS, etc.).

Shells =/= Operating system.

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

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

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

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

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

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

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

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

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

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

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

> MKS's value lays in its integration with Windows.  CYGWIN's developers
> recognising that Windows is not a passing fad might push CYGWIN into the
> mainstream of Windows development.

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

> As it stands, if getting into it is a challenge for people with plenty of
> Unix and Windows background, it will not make much headway with pure
> Windows programmers.

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

> Your comment regarding "What does not work from CMD is Microsoft's
> problem, not Cygwin's." ignores that Cygwin is supposed to work within
> Windows.

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

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

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

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

> I disagree completely.

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

> If you are in an interactive bash, running on a Windows computer, you sure
> as hell expect to be able to run "foo.bat" by typing "foo".

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

> And if you are in a script you expect to release to a large community, If
> "foo" comes from some 3rd party package released independently, then you
> don't want to be wiring into your script that "foo" is a bat, exe, vbs, cmd,
> or whatever in case the 3rd party package ever changes its implementation
> (e.g. converting a CMD to  an EXE for performance reasons).

> I agree fully that PATHEXT is not a great mechanism - it just happens to be
> wired into Windows.

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

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

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

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

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

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

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


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

Sorry for my terrible english...


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