[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS autoconf testsuite failure on Tru64 unix
From: |
Paul Eggert |
Subject: |
Re: CVS autoconf testsuite failure on Tru64 unix |
Date: |
Wed, 15 Dec 2004 00:00:56 -0800 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
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.