Robert Elz <k...@munnari.oz.au> wrote, on 09 Apr 2019:
>
> Just one minor note, which applies to both issue 1211 and 1212
> resolutions... (or resolution and proposed resolution I guess)
>
> Both of the workaround methods (added in 1211, and discussed more/altered
> in 1212) have race conditions, not only the 2nd (longer) one - that one has
> a bigger window for something to fall into, but they both reset the
> traps to default, and then set them back to the way they were.
Good point. I have updated note 4358 in bug 1212 to account for this.
I'm not sure it's worth reopening 1211 to fix it there, since it's
extremely unlikely now that we'll do a TC3, so 1211 and 1212 will
end up being applied in the same revision.
> In the application usage section (of 1212) it might be worth adding
> an additional option .. when only one (or a small number) of trap(s)
> is(are) being modified, the following will work...
>
> prev_int_trap=$(trap -p INT); trap 'new trap command' INT
> # do whatever
> eval "${prev_int_trap}"
>
> rather than futzing with all of the traps.
There is already an example in my proposed changes that uses that method.
It's after the "or:" in the page 2420 line 77524 change.
> One additional question that is worth considering wrt this, and other
> similar commands (set +o, export -p, ...) is whether when the standard
> says:
> "so that it is suitable for reinput to the shell"
> is that intended to be read "for reinput to the same instance of
> the shell as saved it" or "for reinput to that shell, or any other
> instantiation of the same process", or "for reinput to any posix
> conformant shell" ?
I believe "the shell" is intended to mean the sh utility (as found by
the PATH value in a conforming environment) on a particular
implementation. So it should be possible to take the output and reinput
it to any invocation of the same shell on the same implementation.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
