Re: CVS autoconf testsuite failure on Tru64 unix

[Paul Eggert]

Noah Misch <address@hidden> writes:

> When the user runs `./testsuite -x', _AT_CHECK needs to expand all shell
> parameters in the command it executes to see if that produces a command
> containing newlines.  If it does, _AT_CHECK disables shell tracing for that
> command to avoid spurious test failures.
>
> For that purpose, it is safe to expand valid parameter expansions
> that the shell will never expand.  That will not effect the outcome
> of a test for whether an expanded command contains a newline.

Thanks for looking into this, but I have to admit that I'm wayyy lost.
I don't have a clue as to what's going on here.  I vaguely understand
that you're trying to predict how a shell command will behave before
you actually execute it, but I don't know why this is important.

That being said, is it really true that you can predict whether a
shell expansion will contain a newline, without possibly introducing
harmful side effects?  For example, how would you know what the
following will expand to, without executing the "rm"?

y=${x-`rm foo; echo bar`}

This will not execute the command "rm foo".  But if we "expand all shell
parameters to see whether that produces a command containing newlines",
won't we have to execute the "rm"?

> +# Escape all `"', ``', and `\' in STRING.  Possibly escape some `$', but do 
> not
> +# escape any parameter expansion that the shell could expand when it 
> interprets
> +# STRING. `foo="AS_ESCAPE_FOR_EXPAND(STRING)"' shall be a valid POSIX shell
> +# command.  If STRING is not a valid shell command, the result is 
> unspecified.

Can this comment be worded as follows?

If STRING is a valid shell command, then
`foo="AS_ESCAPE_FOR_EXPAND(STRING)"' is a valid shell command that has
no side effect other than assigning to "foo".

> +# This implementation leaves valid parameter expansions active
> +# regardless of whether backslashes or single-quotes will keep the
> +# shell from ever expanding them.  It escapes all invalid parameter
> +# expansions; if the shell were to ever expand those, STRING would
> +# also be invalid.

But this makes it sound like STRING can be any string, and that STRING
need not be a valid shell command.  So I guess I'm still lost.

> +# AS_RE_PARAMETER
> +# ---------------
> +# The definition of AS_RE_PARAMETER is a regular expression that only matches
> +# every valid POSIX shell parameter.
> +m4_define([AS_RE_PARAMETER],
> +[\([A-Za-z_][A-Za-z0-9_]*\|[0-9]+\|address@hidden)])

"that only matches every valid POSIX shell parameters"?
Is that equivalent to "that matches valid POSIX shell parameters"?

That "?-*" looks suspicious.  * precedes ? in the ASCII encoding.
Presumably you meant address@hidden  Also (to be pedantic)
A-Z and a-z aren't portable to EBCDIC; you have to spell
them out, e.g., with m4_cr_letters.

> +# The definition of AS_RE_PARAMETER_EXP is a regular expression
> +# that matches many valid POSIX shell parameter expansions and does
> +# not match any invalid POSIX shell parameter expansions.  This
> +# implementation matches only `${...}'  expansions, because only
> +# they can form grammatically invalid shell.

Is it accurate to say that it matches any shell parameter
expansion that begins with "${"?  If so, that would be a shorter
way to say it.