Re: portability bug (shell syntax)

[Peter Selinger]

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

libtool--config-output
Description: ASCII English text

configure-output
Description: ASCII English text