[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] posix-shell.m4: fix typo that made this test malfunction
From: |
Paul Eggert |
Subject: |
Re: [PATCH] posix-shell.m4: fix typo that made this test malfunction |
Date: |
Wed, 09 Jul 2008 15:04:58 -0700 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
Jim Meyering <address@hidden> writes:
> + f () { test $v = "$(printenv v)"; func_return $?; }
> + v=2 f &&
That doesn't look right to me. I don't think POSIX requires
that test to succeed.
Hmm, let me find that language-lawyer hat! Here are some quotes:
1. "Function Definition Command"
<http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_05>
says "When a function is executed, it shall have the syntax-error and
variable-assignment properties described for special built-in
utilities in the enumerated list at the beginning of Special Built-In
Utilities."
2. "Special Built-In Utilities" (e.g., 'eval', 'shift')
<http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_14>
says "Variable assignments specified with special built-in utilities
remain in effect after the built-in completes; this shall not be the
case with a regular built-in or other utility."
3. "Shell Execution Environment"
<http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_12>
says "Utilities other than the special built-ins (see Special Built-In
Utilities) shall be invoked in a separate environment that consists of
the following. The initial value of these objects shall be the same as
that for the parent shell, except as noted below.... * Variables with
the export attribute, along with those explicitly exported for the
duration of the command, shall be passed to the utility environment
variables"
So, there's no requirement that function executions be treated like
ordinary commands as far as the "a=b f" syntax goes. On the contrary,
it looks more the other way around: if F is a function, "a=b f" looks
like it is supposed to be executed as if it were "a=b; f".
I fully admit that many real implementations disagree with the
interpretation of POSIX given in the previous paragraph. (Maybe
someone should file an interpretation request. :-) Given all the
real-world problems with this syntax, though, it would seem unwise to
test or rely on this particular feature.