sh tests in

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

sh tests in

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

In terms of defensiveness, the --withval parameter could be anything so 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

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

if test x"$enable_static" = x"yes"; then

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


Reply | Threaded
Open this post in threaded view

Re: sh tests in

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

I've pushed the proposed fix:

- Jordi G. H.