Re: [PATCH] posix-shell.m4: fix typo that made this test malfunction

[Paul Eggert]

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.