[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"
   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

   2. "Special Built-In Utilities" (e.g., 'eval', 'shift')
   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"
   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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]