Re: coproc and existing variables

[Grisha Levit]

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.ramey@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.ramey@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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/