A couple of minor things after the change (i don’t know if they’re worth looking at..)
- If coproc name is a nameref to an unset variable, a nameref/array is left over: $ declare -n ref=x; coproc ref { :; }; wait; declare -p ref [1] 13267 [1]+ Done coproc ref { :; }declare -an ref=([0]="x") - check_unbind_variable calls builtin_error but the unbind-ing happens not while coproc is executing. maybe internal_error would make more sense? - The %s_PID variable is unbound unconditionally $ declare -r RO RO_PID; coproc RO { :; }; wait; declare -p RO RO_PID bash: RO: readonly variable [1] 13288 [1]+ Done coproc RO { :; } bash: wait: RO: cannot unset: readonly variable declare -r RO bash: declare: RO_PID: not found On Sun, Apr 24, 2016 at 2:17 PM, Chet Ramey <chet.ra...@case.edu> wrote: > On 4/21/16 2:39 PM, Grisha Levit wrote: > > On Thu, Apr 21, 2016 at 1:22 PM, Chet Ramey <chet.ra...@case.edu> wrote: > >> > >>> 1. coproc unsets readonly NAME after the process completes > >> > >> Yes. This is a gray area. Under some circumstances, e.g, getopts with > >> OPTARG, defined shell behavior can override a readonly setting. > > > > Probably should at least disallow this case? > > > > $ bash -r -c 'coproc PATH { :; }; wait; PATH=/whatever; echo $PATH' > > bash: PATH: readonly variable > > bash: PATH: readonly variable > > /whatever > > Yes, even though the restricted shell is not a great example of anything, > it seems reasonable to follow printf/read/mapfile and not overwrite read- > only variables used as coproc names. getopts will remain an outlier. > > 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/ >