wrapperdot on cygwin (was: small abstractions: func_source, func_execute_cmds)

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Wed, Aug 10, 2005 at 04:47:05PM CEST:
> Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:
> 
> > +# func_source file noexe
> > +# Source FILE, adding directory component if necessary.
> > +# If noexe is given, add a dot to prevent `$file.exe' from
> > +# being sourced on system with automatic-append-.exe behavior.
> > +func_source ()
> > +{
> > +    $opt_debug
> > +    case $2,$build in
> > +    noexe,*cygwin* | noexe,*mingw*)
> > +       func_source_file=$1. ;;
> > +    *) func_source_file=$1  ;;
> 
> 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.

MinGW still works this way, right?

*snip*
> Furthermore, appending a trailing . does not always work in cygwin.
*snip*
> On a managed mount, trailing . is not stripped, so adding a trailing
> dot with the excuse of suppressing .exe magic breaks:

Can we find out whether the file lives on a managed mount?
Or can we just turn off adding a dot for all of cygwin?
Or just for new cygwin versions?

> > -     # To insure that "foo" is sourced, and not "foo.exe",
> > -     # finese the cygwin/MSYS system by explicitly sourcing "foo."
> > -     # which disallows the automatic-append-.exe behavior.
*snip*
> OK, so your refactoring did not introduce the bug; it was already present.  
> But 
> it still needs to be fixed.

Yep, and now that you've reported it: it also needs to be fixed in
branch-1-5 and branch-2-0 (to which I was not going to apply this
patch).

Cheers,
Ralf