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

[Andrey Repin]

Greetings, Hans-Bernhard Bröker!

> Am 10.08.2016 um 03:01 schrieb Andrey Repin:

>> PATHEXT tells the shell to consider these file extensions executable.

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

Hans:
> 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 '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 english...

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

[Hans-Bernhard Bröker]

Am 10.08.2016 um 03:01 schrieb 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  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

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

[Erik Soderquist]

On Tue, Aug 9, 2016 at 9:01 PM, Andrey Repin wrote:
> Greetings, 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

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

[cyg Simple]

On 8/9/2016 9:11 PM, Warren Young wrote:
> On Aug 9, 2016, at 7:01 PM, Andrey Repin wrote:
>>
>>> 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.

-- 
cyg Simple

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

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

[Corinna Vinschen]

On Aug 10 03:44, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> As for PATHEXT we can do the following scenario instead.
> >> 
> >> export PATHEXT="$PATHEXT;.TXT"
> >> vi foo.txt
> >> :set ff=dos
> >> i
> >> a
> >> b
> >> c
> >> 
> >> :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.
> 
> ShellExecuteEx does, but it will not help you a single bit.
> 
> > - 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…
> 
> > So, if we actually implement PATHEXT, its usage would be limited to
> > suffixes of binary files and files starting with #!, 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

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


signature.asc
Description: PGP signature

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

[Warren Young]

On Aug 9, 2016, at 6:10 PM, Warren Young wrote:
> 
> On Aug 4, 2016, at 5:43 PM, Michel LaBarre wrote:
> 
>> 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

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

[Warren Young]

On Aug 9, 2016, at 7:01 PM, Andrey Repin wrote:
> 
>> 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

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

[Andrey Repin]

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

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

[Andrey Repin]

Greetings, Corinna Vinschen!

>> As for PATHEXT we can do the following scenario instead.
>> 
>> export PATHEXT="$PATHEXT;.TXT"
>> vi foo.txt
>> :set ff=dos
>> i
>> a
>> b
>> c
>> 
>> :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.

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

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

> So, if we actually implement PATHEXT, its usage would be limited to
> suffixes of binary files and files starting with #!, 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 terrible english...

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

[Warren Young]

On Aug 4, 2016, at 5:43 PM, Michel LaBarre  wrote:
> 
> 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.

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

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

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

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

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

> 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 

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

[Warren Young]

On Aug 8, 2016, at 8:00 AM, Erik Soderquist  wrote:
> 
> On Mon, Aug 8, 2016 at 9:52 AM, Erik Soderquist wrote:
>> On Sun, Aug 7, 2016 at 4:11 AM, Herbert Stocker wrote:
 
 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]

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

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

[Vince Rice]

> 
> On Aug 9, 2016, at 3:41 PM, Warren Young  wrote:
> 
> On Aug 9, 2016, at 2:07 AM, Herbert Stocker  wrote:
>> 
>> On 8/9/2016 2:45 AM, Michel LaBarre wrote:
>>> 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.

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

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

[Warren Young]

On Aug 9, 2016, at 2:07 AM, Herbert Stocker  wrote:
> 
> On 8/9/2016 2:45 AM, Michel LaBarre wrote:
>> 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

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

[Erik Soderquist]

On Tue, Aug 9, 2016 at 11:15 AM, cyg Simple wrote:
> On 8/9/2016 10:13 AM, Erik Soderquist wrote:
>> On Tue, Aug 9, 2016 at 8:58 AM, cyg Simple wrote:
>>> 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...

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

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

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

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

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

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

user@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$
user@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 

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

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

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

[Helmut Karlowski]

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

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

[cyg Simple]

On 8/9/2016 10:13 AM, Erik Soderquist wrote:
> On Tue, Aug 9, 2016 at 8:58 AM, cyg Simple wrote:
>> 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)

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

-- 
cyg Simple

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

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

[Erik Soderquist]

On Tue, Aug 9, 2016 at 8:58 AM, cyg Simple wrote:
> 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

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

[cyg Simple]

On 8/9/2016 9:07 AM, Marco Atzeri wrote:
> On 09/08/2016 14:58, cyg Simple wrote:
>>
>>> So, if we actually implement PATHEXT, its usage would be limited to
>>> suffixes of binary files and files starting with #!, 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

-- 
cyg Simple

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

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

[cyg Simple]

On 8/8/2016 10:03 AM, Corinna Vinschen wrote:
> On Aug  8 09:43, cyg Simple wrote:
>> On 8/8/2016 7:23 AM, Corinna Vinschen wrote:
>>> On Aug  7 10:11, Herbert Stocker wrote:
 On 05.08.2016 17:29, Corinna Vinschen wrote:
  If you see the
> 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.
>>
>>> 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.

-- 
cyg Simple

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

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

[Marco Atzeri]

On 09/08/2016 14:58, cyg Simple wrote:



So, if we actually implement PATHEXT, its usage would be limited to
suffixes of binary files and files starting with #!, 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

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

[cyg Simple]

On 8/8/2016 9:43 AM, cyg Simple wrote:
> 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.

-- 
cyg Simple

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

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

[cyg Simple]

On 8/8/2016 10:33 AM, Corinna Vinschen wrote:
> On Aug  8 09:43, cyg Simple wrote:
>> As for PATHEXT we can do the following scenario instead.
>>
>> export PATHEXT="$PATHEXT;.TXT"
>> vi foo.txt
>> :set ff=dos
>> i
>> a
>> b
>> c
>> 
>> :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.
> 

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.

> So, if we actually implement PATHEXT, its usage would be limited to
> suffixes of binary files and files starting with #!, 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.

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

-- 
cyg Simple

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

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

[Herbert Stocker]

On 8/9/2016 2:45 AM, Michel LaBarre wrote:

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

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

[Marco Atzeri]

On 09/08/2016 02:17, Michel LaBarre wrote:

On Aug  8 09:43, cyg Simple wrote:

On 8/8/2016 7:23 AM, Corinna Vinschen wrote:

On Aug  7 10:11, Herbert Stocker wrote:

On 05.08.2016 17:29, Corinna Vinschen wrote:


So, if we actually implement PATHEXT, its usage would be limited to
suffixes of binary files and files starting with #!, 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

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

[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

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

[Michel LaBarre]

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

On Aug  8 09:43, cyg Simple wrote:
> On 8/8/2016 7:23 AM, Corinna Vinschen wrote:
> > On Aug  7 10:11, Herbert Stocker wrote:
> >> On 05.08.2016 17:29, Corinna Vinschen wrote:
> >>  If you see the
> >>> 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.
> 
> > 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
> 
> :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 #!, 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

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

[Corinna Vinschen]

On Aug  8 09:43, cyg Simple wrote:
> On 8/8/2016 7:23 AM, Corinna Vinschen wrote:
> > On Aug  7 10:11, Herbert Stocker wrote:
> >> On 05.08.2016 17:29, Corinna Vinschen wrote:
> >>  If you see the
> >>> 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.
> 
> > 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
> 
> :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 #!, 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

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


signature.asc
Description: PGP signature

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

[Corinna Vinschen]

On Aug  8 09:43, cyg Simple wrote:
> On 8/8/2016 7:23 AM, Corinna Vinschen wrote:
> > On Aug  7 10:11, Herbert Stocker wrote:
> >> On 05.08.2016 17:29, Corinna Vinschen wrote:
> >>  If you see the
> >>> 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.
> 
> > 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

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


signature.asc
Description: PGP signature

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

[Erik Soderquist]

On Mon, Aug 8, 2016 at 9:52 AM, Erik Soderquist wrote:
> On Sun, Aug 7, 2016 at 4:11 AM, Herbert Stocker wrote:
>>>
>>> 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

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

[Corinna Vinschen]

On Aug  8 09:52, Erik Soderquist wrote:
> On Sun, Aug 7, 2016 at 4:11 AM, Herbert Stocker wrote:
> >>
> >> 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

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


signature.asc
Description: PGP signature

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

[Erik Soderquist]

On Sun, Aug 7, 2016 at 4:11 AM, Herbert Stocker wrote:
>>
>> 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

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

[cyg Simple]

On 8/8/2016 7:23 AM, Corinna Vinschen wrote:
> On Aug  7 10:11, Herbert Stocker wrote:
>> On 05.08.2016 17:29, Corinna Vinschen wrote:
>>  If you see the
>>> 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.

> 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

:wq
cmd /c foo

-- 
cyg Simple

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

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

[Corinna Vinschen]

On Aug  7 10:11, Herbert Stocker wrote:
> On 05.08.2016 17:29, Corinna Vinschen wrote:
>  If you see the
> > 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

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


signature.asc
Description: PGP signature

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

[cyg Simple]

On 8/7/2016 4:11 AM, Herbert Stocker wrote:
> On 05.08.2016 17:29, Corinna Vinschen wrote:
>  If you see the
>> 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.

-- 
cyg Simple

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

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

[Csaba Raduly]

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

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

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

[Herbert Stocker]

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

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

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

[Eliot Moss]

On 8/5/2016 2:14 PM, Nellis, Kenneth wrote:

From: Erik Soderquist

... DOS did a lot of things
against already established conventions, such as using a backslash
instead of a forward slash as the directory separator, just "to be
different".


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


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

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

[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-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
Vince Rice
Sent: August-05-16 2:45 PM
To: cygwin@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

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

[Marco Atzeri]

On 05/08/2016 21:43, cyg Simple wrote:

On 8/5/2016 11:29 AM, Corinna Vinschen wrote:

On Aug  5 11:20, Michel LaBarre wrote:

Hello cygsimple,

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

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

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

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


That.  Plus, the refusal from cgf is still valid today.  If you see the
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.



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

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

[cyg Simple]

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

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

-- 
cyg Simple

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

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

[Vince Rice]

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

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


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


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

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

[Nellis, Kenneth]

From: Erik Soderquist
> ... DOS did a lot of things
> against already established conventions, such as using a backslash
> instead of a forward slash as the directory separator, just "to be
> different".

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

--Ken Nellis

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

[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

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

[Corinna Vinschen]

On Aug  5 11:20, Michel LaBarre wrote:
> Hello cygsimple,
> 
> Thanks for the advice regarding line length. 
> I will try to remember to rein in my margins when emailing to cygwin. 
> 
> Thanks for your recognition of PATHEXT's potential value;
> reassuring to know I am not alone in my delusions.
> 
> Regarding providing code, I am somewhat stale (though I spent my first 20 
> work years
> immersed in system code, assembly/C/Algol/Pascal/C++, building firmware for 
> bit-sliced processors, etc.)
> 
> The patch to which I referred is one I found while researching the topic;
> https://cygwin.com/ml/cygwin/2007-09/msg00127.html is one reference to it.
> It is old and likely out of date.

That.  Plus, the refusal from cgf is still valid today.  If you see the
code required to handle .exe and .lnk extensions you don't *want*
PATHEXT support anymore.


Corinna

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


signature.asc
Description: PGP signature

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

[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

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

[Eliot Moss]

On 8/5/2016 10:12 AM, cyg Simple wrote:


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


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

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

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

Regards -- Eliot Moss

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

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

[Erik Soderquist]

On Thu, Aug 4, 2016 at 7:43 PM, Michel LaBarre wrote:
> Well my first foray into the world of CYGWIN mailing lists has been
> a lot of fun so far.

Glad you enjoyed it  :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This is true.

> ... ... ... not including a suffix when invoking from scripts, two
> 

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

[cyg Simple]

Michael,

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

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

Cygwin Community,

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

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

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

-- 
cyg Simple

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

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

[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 

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

[Andrey Repin]

Greetings, Bill Smith!

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

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

> The fix was to change

> somescript

> To
> somescript${BAT}

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

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

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

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

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

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

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


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

Sorry for my terrible english...


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

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

[Andrey Repin]

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 

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

[Bill Smith]

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

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

somescript

To
somescript${BAT}

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

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

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

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

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

[Bill Smith] 

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

set -o igncr
export SHELLOPTS

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

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

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

[Andrey Repin]

Greetings, Kaz Kylheku!

> I can't find any reference anywhere to PATHEXT being used outside
> of the CMD.EXE interpreter, which rather tends to make it substantially
> less than fundamental to Windows, though noteworthy.

> Certainly, CreateProcess does not use PATHEXT.

> I can't find any documentation which says that ShellExecuteEx
> uses PATHEXT, either. (Can anyone confirm?)

ShellExecute(Ex) uses its own discovery mechanism with hardcoded order.
PATHEXT is meaningless for this case.
It's a CMD's (and some other shells and file managers) setting to find
executable object in a specified order.
Not a mechanic to determine, how to execute it.

>>  Without using extensions, bash can use execution privileges to
>> determine if
>> a file is executable.  However, that does not work when invoking a 
>> command
>> from CMD.

> What does not work from CMD is Microsoft's problem, not Cygwin's.

> Yes, even though you have a "myscript.sh" and you do "chmod a+x 
> myscript.sh"
> inside Cygwin, the outside Windows world doesn't agree that myscript.sh
> is now executable, and that it uses /bin/sh by default as its 
> interpreter,
> if a #! line is absent, otherwise the interpreter nominated by the #!
> line.

> Adding ".sh" to PATHEXT might work in causing CMD.EXE to resolve
> "myscript" to "myscript.sh"; however, it will not then successfully
> execute "myscript.sh",  because the underlying CreateProcess API
> will not find it executable.

> CMD.EXE will probably *try* to execute it, and fail.

Not, if you provide a file association. :)

[C:\Users\anrdaemon\Documents\_pas\ShExETest]$ echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1;.MSC;.BTM;.PHP;.SH

[C:\Users\anrdaemon\Documents\_pas\ShExETest]$ assoc .sh
.sh=unixshell.script

[C:\Users\anrdaemon\Documents\_pas\ShExETest]$ ftype unixshell.script
unixshell.script="C:\Programs\Cygwin_64\bin\cygwrap.cmd" "%1" %*

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

To be fair, CMD have this mechanics, but it's compatible with shebang in the 
least.
To begin with, it uses an explicit command your interpreter has to know and
discard, rather than a widely-accepted as a comment the '#' char.

> What you need on Windows is a script-to-EXE application deployment tool,
> which takes your "script.sh" and combines it with a copy of a special
> binary executable, and writes out the combination to "script.exe".
> Then even a raw CreateProcess Win32 API call can invoke "script.exe".

You're overcomplicating it.

> Firstly, the binary mode default treatment for files comes
> from the mount table:

>$ mount
>C:/Cygwin/bin on /usr/bin type ntfs (binary,auto)
>C:/Cygwin/lib on /usr/lib type ntfs (binary,auto)
>C:/Cygwin on / type ntfs (binary,auto)
>C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)

> See how that /cygdrive/c is mounted "binary" (as is everything else?)
> That's what causes text files to be treated as LF rather than CR/LF.
> That can be altered; you can mount some Windows path into Cygwin's
> POSIX file system view as text, and then CR/LF conversion is done.

And in turn cause short reads, size miscalculations and overall corruption of
the data.
"text" mounts and modes were discouraged for ages, if not decades, by now.


-- 
With best regards,
Andrey Repin
Thursday, August 4, 2016 15:13:11

Sorry for my terrible english...

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

[Andrey Repin]

Greetings, Michel LaBarre!

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

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

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

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

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

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

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

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

> with both types of line delimiters transparently.

-transparently
+ambiguously

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

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


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

Sorry for my terrible english...

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

[Csaba Raduly]

Hi Michel,

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

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

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

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

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

[Doug Henderson]

On 3 August 2016 at 22:30, Michel LaBarre  wrote:

> ...
>
> PATHEXT has been part of Windows for as long as I can remember - back to
> the mid-80's - used by shells that run under windows
>


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

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

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

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

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

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

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

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


Doug

--
Doug Henderson, Calgary, Alberta, Canada

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

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

[Vince Rice]

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

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

> Problem 1:  Cygwin does not support PATHEXT and really should.
> 
> Fundamental reason:  from the Cygwin FAQ - What is it?  "Cygwin is a
> distribution of popular GNU and other Open Source tools running on Microsoft
> Windows.”

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

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

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

“To you."

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

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

> CYGWIN could be a very smart supplement to that requirement.
> …
> If CYGWIN  could mitigate some of the recurring impediments new users trip 
> over, (as evidenced by the many web-references to both my problems) it would 
> facilitate its adoption by both Unix and non-Unix types.  

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

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

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

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



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

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

[Michel LaBarre]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Kaz Kylheku]

On 03.08.2016 18:43, Michel LaBarre wrote:

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


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

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


Fundamental reason:  from the Cygwin FAQ - What is it?  "Cygwin is a
distribution of popular GNU and other Open Source tools running on 
Microsoft

Windows."

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


I can't find any reference anywhere to PATHEXT being used outside
of the CMD.EXE interpreter, which rather tends to make it substantially
less than fundamental to Windows, though noteworthy.

Certainly, CreateProcess does not use PATHEXT.

I can't find any documentation which says that ShellExecuteEx
uses PATHEXT, either. (Can anyone confirm?)

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

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, 

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