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

[Ralf Wildenhues]

[ This thread starts at
http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00049.html
and continues at
http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00051.html
I'm CC:ing the MinGW list because it is affected as well, see below. ]

* Eric Blake wrote on Wed, Aug 10, 2005 at 06:37:46PM CEST:
> > > 
> > > 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):

OK.  I've tried your examples on cygwin (non-managed mount) and mingw,
both recent.
  . ./foo
seems to open foo rather than foo.exe (i.e., work as we'd like) in every
case (i.e., even if foo.exe exists, whether it is an executable or a
shell script snippet).
  . ./foo.
works for mingw in any case, but it seems it is not necessary to add the
dot.  Looks like we can simplify func_source like this then:

func_source ()
{
    $opt_debug
    case $1 in
    */* | *\\*) . "$1" ;;
    *) . "./$1" ;;
    esac
}

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

This is a different matter, and not a problem actually, since, as you
observe, we use foo.exe only to invoke "$SHELL foo".

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

The question here is whether mingw behavior used to be different, and if
so, whether libtool still needs to cater for the old behavior.

Regards,
Ralf