On 3/11/10 4:24 AM, Marc Herbert wrote:
> Chet Ramey a écrit :
>>> On the other hand, local is not specified by POSIX. What would it hurt
>>> to redefine the exit status of local to reflect the status of any
>>> command substitutions performed during the local assignments (short of
>>> compatibility with zsh)?
>>
>> I think that would be a bad idea, and am not inclined to do it.
>
> Care to elaborate a bit? (preferably on the public list)
Because that's not what local and its siblings (declare/typeset/export/
readonly) do. These builtins exist to assign and modify variable
attributes. As an added feature, they support value assignment at the
same time, but the important function is the attribute setting. They
don't need to know how the value was computed.
(Yes, a secondary function is to insulate the shell programmer from
assignment errors that might otherwise cause the shell to exit, and the
ability to create variables with local scope is clearly a hole in Posix.)
Since the function is setting the attribute or value, the exit status
should reflect whether or not that succeeded. For instance, attempting
to modify a read-only variable, or to assign a variable with an invalid
name, which would cause a Posix shell to exit, should be reflected in the
exit status.
For instance, should this succeed or fail?
local -r foo=$(echo a; exit 1)
After all, the variable was correctly created, and ends up with the desired
attribute. Is that not the intent of the statement?
To Posix, assignment statements never fail -- assignment errors cause non-
interactive shells to exit, period. In that case, it's possible to
reflect the exit status of a command substitution in the exit status of a
command consisting only of assignment statements, though that has problems
of its own and is only reliable on commands consisting of a single
assignment.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
