Robert Elz <k...@munnari.oz.au> wrote, on 28 Jul 2020:
>
> | As I pointed out elsewhere in the thread, doing this would mean that
> | using set +o in a command substitution to obtain options to be
> | restored later would no longer work.
>
> That could be handled the way that T=$(trap) is handled, and the way that
> most shells handle J=$(jobs) (dash and zsh don't seem to manage that one).
> In general when something is supposed to be reset in a subshell, and there
> is a command whose purpose is to examine that something, then instead of
> resetting it when the subshell is created, it (whatever "it" is in the case
> in question) gets reset in the subshell once it is determined that the
> first command executed there is not one that extracts the value.
If you look at how we had to specify $(trap) in the standard, it is
horrible. (The paragraph beginning "When a subshell is entered" and
the one after it.) I would very much prefer that we not repeat that
with other utilities.
> Doing this isn't rocket science, we do it all the time, it is the only
> sane way to work (whatever the standard pretends should happen) - the
> only purpose of writing a command as the first command in a subshell,
> to examine something which id cleared/reset/... in a subshell is to get
> the value as it was in the parent of the subshell (the actual value in
> the subshell itself is known).
It's only easy because (most/all?) shells take the easy option and do
a lexical analysis of the command to be substituted. Applications can't
expect the following to work, but if the feature was implemented
"properly", it would:
showalltraps() { trap -p; }
alltraps=$(showalltraps)
(Of course, this assumes the addition of -p which is being done in
Issue 8.)
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
