> > > > This is wrong for cygwin. For starters, cygwin does not auto-append .exe > > when > > sourcing a file, but correctly sources the filename as it was spelled. > > (.exe > > is auto-appended when exec()ing an executable, but sourcing is different > > from > > exec()ing.) > > Thanks for this information! So when have things changed between > http://lists.gnu.org/archive/html/libtool-patches/2003-01/msg00009.html > and now? I mean, Charles won't have introduced this for no reason, with > this detailed comment added to it, and explaining this: > | There are two places in ltmain.sh where the shell wrapper is directly > | sourced. This doesn't work very well, because when both "foo" and > | "foo.exe" exist, ". ./foo" ends up sourcing "foo.exe" -- which is bad.
My earlier example was with sourcing, where the filename has no magic applied to it. The behavior is different if you want to execute a file (here, on a non-managed mount): $ cat > bar #!/bin/sh echo plain $ # Windows chokes if a file named bar.exe is a script instead of $ # an actual native executable, so I compiled a quickie: $ file bar.exe bar.exe: PE executable for MS Windows (console) Intel 80386 32-bit $ chmod u+x bar $ sh ./bar plain $ sh ./bar. plain $ sh ./bar.exe exe $ ./bar. plain $ ./bar exe $ ./bar.exe exe I don't know of any way to force execution of bar when both bar and bar.exe exist on a managed mount, but when bar is not a script. Fortunately, for libtool's usage, bar is a script, so you can force execution by invoking it with a shell. > > MinGW still works this way, right? Sorry, but I don't use mingw often enough to know. Someone else will have to field this question. > > Can we find out whether the file lives on a managed mount? I haven't found a way to do that, yet. > Or can we just turn off adding a dot for all of cygwin? > Or just for new cygwin versions? Probably the safest course, for now. It would certainly need testing, whatever happens. -- Eric Blake
