Re: portability bug (shell syntax)

[Peter Selinger]

Hi Ralf,

I have to eat my words. I went to bed last night, got up, decided to
investigate some more, and I cannot now reproduce the problem. I have
no idea what happened over night. What is happening today is:
./configure executes itself using /bin/bash, sets SHELL to /bin/bash,
the XSI test succeeds, ./libtool is built with first line "#!
/bin/bash", and the make succeeds.

The only way I can still reproduce last night's behavior is by
invoking configure as "/bin/bash ./configure". In this case,
./configure runs under /bin/bash, CONFIG_SHELL is empty, SHELL gets
set to /bin/sh, the XSI test succeeds, ./libtool is built with first
line "#! /bin/sh", and the make fails (due to XSI commands being used
in a /bin/sh script). So this could still be considered a bug, as the
XSI test should test the shell that's given in $SHELL (that ./libtool
will run under), not the shell that ./configure is running under.

That's not how I invoked it yesterday, but go figure. Maybe somewhere
between "make dist", transferring tarballs to another machine,
upgrading from autoconf 2.57 to 2.67, and re-running the configuration
tools, something didn't get updated until this morning. Sorry about
that. -- Peter

Peter Selinger wrote:
> 
> 
> Ralf Wildenhues wrote:
> > 
> > Hi Peter,
> > 
> > * Peter Selinger wrote on Fri, Aug 06, 2010 at 06:02:42AM CEST:
> > > I am using libtool-2.2.10 on a
> > > SunOS chase-sun 5.10 Generic_118833-20 sun4u sparc SUNW,Ultra-4
> > > 
> > > Line 665 of libtool is:
> > > 
> > >   func_arith_result=$(( $* ))
> > > 
> > > Apparently this syntax is not portable, as Sun's /bin/sh gives:
> > > 
> > > ../libtool: syntax error at line 665: `func_arith_result=$' unexpected
> > 
> > Thanks for the bug report.  configure should actually be creating a
> > libtool script with the portable code instead of the faster XSI
> > implementation if it determines the shell to not be XSI compliant.
> > Can you please show how you invoked configure, the configure output,
> > and output of './libtool --config'?  Do you have CONFIG_SHELL, SHELL
> > in your environment, and if yes, what do they contain?
> > 
> > Thanks,
> > Ralf
> 
> Hi Ralf,
> 
> I am using GNU Autoconf 2.67. The first line of ./configure is "#!
> /bin/sh", and I invoke it as ./configure.  Here is the relevant line
> out output from ./configure:
> 
> checking whether the shell understands some XSI constructs... yes
> 
> And here is a line from the output of 'ps -ef', while ./configure is
> running:
> 
> selinger 16570 14310   2 03:38:47 pts/14      0:02 /bin/bash ./configure
> 
> This surprised me a lot. After looking at the actual ./configure
> script, I discovered that ./configure re-executes itself as /bin/bash
> when it does not like the shell that it is running in. This happens in
> the following section of the configure script:
> 
>       if test "x$CONFIG_SHELL" != x; then :
>   # We cannot yet assume a decent shell, so we have to provide a
>         # neutralization value for shells without unset; and this also
>         # works around shells that cannot unset nonexistent variables.
>         BASH_ENV=/dev/null
>         ENV=/dev/null
>         (unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV
>         export CONFIG_SHELL
>         exec "$CONFIG_SHELL" "$as_myself" ${1+"$@"}
> fi
> 
> Note the "exec" in the last line; at this point $CONFIG_SHELL = /bin/bash.
> 
> So my current best explanation is: if ./configure does not like
> /bin/sh, then it re-executes itself under the first shell it finds and
> likes, in my case /bin/bash. Therefore, the test for XSI tests the
> /bin/bash capability and not that of /bin/sh. However, libtool later
> runs under /bin/sh, where the XSI syntax is not understood.
> 
> I am not sure what to suggest. Perhaps it's better not to use XSI
> syntax at all, rather than trying to guess whether it will work? Or
> else perhaps the test for XSI can be changed to invoke /bin/sh
> explicitly?
> 
> The output of ./configure and of ./libtool --config are attached. I
> can also send the actual package I am compiling, if it helps. 
> 
> Please let me know if you need more info or testing. Thanks, -- Peter