sh tests in configure.ac

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

sh tests in configure.ac

Rik-4
On 02/25/2015 09:01 AM, [hidden email] wrote:

> Subject:
> test "$foo" = "$bar" vs test x"$foo" = x"$bar"
> From:
> Jordi Gutiérrez Hermoso <[hidden email]>
> Date:
> 02/25/2015 08:27 AM
> To:
> octave-maintainers <[hidden email]>
> List-Post:
> <mailto:[hidden email]>
> Content-Transfer-Encoding:
> 7bit
> Precedence:
> list
> MIME-Version:
> 1.0
> Message-ID:
> <1424881676.5456.26.camel@Iris>
> Content-Type:
> text/plain; charset="UTF-8"
> Message:
> 3
> re: bug #44367.
>
> I need a little help with my shell scripting.
>
> What's the reason to have
>
>     test x"$foo" = x"$bar"
>
> vs
>
>     test "$foo" = "$bar"
>
> ?
>
> It was my understanding is that the intent of the former is to handle
> the case where $foo or $bar is empty, but I thought the quotes handled
> that.
>
> That is, I thought you needed to either do
>
>    test x$foo = x$bar
>
> or
>
>    test "$foo" = "$bar"
>
> but having both the leading x and the quotes is redundant.
>
> - Jordi G. H.

I didn't find many instances in configure.ac; I have worked pretty hard to
get rid of them.

The definitive guide is from Autoconf and their section on how to write
portable shell scripts
(http://ftp.gnu.org/old-gnu/Manuals/autoconf-2.57/html_chapter/autoconf_10.html).
I find that it helps to know where the input is coming from and that allows
you to gauge how defensively to code.  Raw user input has to be treated
with the utmost caution.

The trouble with test "$foo" is that foo may contain a string that looks
like an argument to test, such as '-n' or '-z' and the shell will get
confused by test -z = "$bar".  Putting an 'x' in front stops the expansion
from looking like an option.

The subsequent question, why to use x"$foo" versus just x$foo is that $foo
and $bar may expand to characters which are not relevant to the shell for
parsing.  If $foo is " " and $bar is "    " then the concatenation x$foo is
just x + spaces and x$bar is x + more spaces and the shell parses this as
'x' == 'x'.  Of course, maybe extra spaces aren't really important, but you
can eliminate that issue as well by putting the variable in quotes.
Autoconf's own recommendation is to put the entire thing in quotes like so
"x$foo".

In terms of defensiveness, the --withval parameter could be anything so
configure.ac uses 'x' when checking that value.

The FFLAGS option, if it exists, is very likely to start with a '-' and
potentially look like an option so it too uses x-testing.

## Default FFLAGS is -O.
if test x"$FFLAGS" = x""; then
  FFLAGS="-O"
fi

These two instances below could possibly be re-coded, but you would need to
check where enable_shared gets defined.

if test x"$enable_shared" = x"yes"; then
  SHARED_LIBS=yes
else
  SHARED_LIBS=no
fi

if test x"$enable_static" = x"yes"; then
  STATIC_LIBS=yes
else
  STATIC_LIBS=no
fi

The other instances are in the FLTK configure stuff that was just copied
over from fltk.org and I didn't feel like putting it into our style in case
it changed again.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: sh tests in configure.ac

Jordi Gutiérrez Hermoso-2
Thanks for your detailed response, Rik. This helped a lot.

I've pushed the proposed fix:

    http://hg.savannah.gnu.org/hgweb/octave/rev/e8ccfc5d892b

- Jordi G. H.