-----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 > <ESC> > :wq > cmd /c foo As you show here, the PATHEXT definition is so that it also contains file suffixes which require to know the interpreters starting them. To implement that, the lib would have to either read the registry to know the connection between suffix and interpreter (which is pretty convoluted), or it would have to "start the file", aka call ShellExecute on the file, without knowing what process will come up as child process. In your example that would be Notepad or Write. The way this works is just not feasible to be used from inside the DLL, e.g.: - ShellExecute does not return a handle to the called process, so the parent can't wait(2) for it. - ShellExecute does not allow to specify an environment for the child process. Cygwin's Windows environment is reduced to minimal size. Cygwin children inherit the POSIX environment by a simple copy process. Only when starting a non-Cygwin process, this process gets a full Windows environment by means of the matching CreateProcess parameter. So, if we actually implement PATHEXT, its usage would be limited to suffixes of binary files and files starting with #!<interpreter>, or we would have to use a way to start an application which doesn't work well in a POSIX scenario, or we would have to search the registry for the suffix linkage. Additionally to searching a variable number of files for each single file access. [Michel] [Michel] #! Is better than nothing but doing PATHEXT fully might put these considerations to rest forever. [Michel] Fundamentally, the means of invoking a file interpreter in Windows are determined by the registry's file associations; [Michel] anything else is an assumption. [Michel] I don't know how cygwin.dll is implemented but the only suffixes that need to be looked up are the ones in PATHEXT and that could be done once could it not? Additionally I would (again?) like to stress that PATHEXT is a feature of CMD, aka, the shell. It's not a feature of the underlying libs. [Michel] [Michel] PATHEXT is supported by Powershell and VBS. MKS's shells (ksh,sh,perl) also. [Michel] Likely others since it is considered consistent with Windows. [Michel] It likely should have been implemented at a lower level but was not. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
