Re: coproc and existing variables

2016-05-24 Thread Chet Ramey
On 5/24/16 4:08 AM, Dan Douglas wrote: > I don't even see why we need a magic variable for this. ksh makes you > manually store $! and bash also allows this. OK. I'm not going to go back and remove it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa,

Re: coproc and existing variables

2016-05-24 Thread Dan Douglas
I don't even see why we need a magic variable for this. ksh makes you manually store $! and bash also allows this. As an alternative, create a special BASH_COPROC_PIDS associative array to map coproc names to pids. ${foo}_suffix=bar is never as good as an associative array.

Re: coproc and existing variables

2016-05-23 Thread Grisha Levit
On Mon, May 23, 2016 at 1:37 PM, Chet Ramey wrote: > It's documented as being managed by > the coproc command, and if you choose to use it yourself, all bets are > off, similarly to how getopts manages $OPTARG. > I see; makes sense. This does allow unbind arbitrary readonly variables that end i

Re: coproc and existing variables

2016-05-23 Thread Chet Ramey
On 5/23/16 12:45 PM, Grisha Levit wrote: > On Thu, May 19, 2016 at 11:05 AM, Chet Ramey > wrote: > > > * The %s_PID variable is unbound unconditionally > > > > BTW, this is exploitable for unsetting read-only variables. > > Same change as for get

Re: coproc and existing variables

2016-05-23 Thread Grisha Levit
On Thu, May 19, 2016 at 11:05 AM, Chet Ramey wrote: > * The %s_PID variable is unbound unconditionally > > > > BTW, this is exploitable for unsetting read-only variables. > > Same change as for getopts. > This should probably instead be the same change as was previously done for unsetting t

Re: coproc and existing variables

2016-05-19 Thread Chet Ramey
On 5/17/16 5:03 PM, Grisha Levit wrote: > On Mon, May 16, 2016 at 4:44 PM, Grisha Levit > wrote: > > * The %s_PID variable is unbound unconditionally > > BTW, this is exploitable for unsetting read-only variables. Same change as for getopts. -- ``The lyf so

Re: coproc and existing variables

2016-05-19 Thread Chet Ramey
On 5/17/16 5:14 PM, Grisha Levit wrote: > On Sun, Apr 24, 2016 at 2:17 PM, Chet Ramey > wrote: > > it seems reasonable to follow printf/read/mapfile and not overwrite read- > only variables used as coproc names. getopts will remain an outlier. > > getopts can

Re: coproc and existing variables

2016-05-17 Thread Grisha Levit
On Mon, May 16, 2016 at 4:44 PM, Grisha Levit wrote: >- The %s_PID variable is unbound unconditionally > > BTW, this is exploitable for unsetting read-only variables. $ declare -r RO; declare -n ref_PID=RO; coproc ref { :; }; wait; declare -p RO bash: ref_PID: readonly variable [1] 13868 ba

Re: coproc and existing variables

2016-05-17 Thread Grisha Levit
On Sun, Apr 24, 2016 at 2:17 PM, Chet Ramey wrote: it seems reasonable to follow printf/read/mapfile and not overwrite read- > only variables used as coproc names. getopts will remain an outlier. > getopts can probably benefit from a nameref check too, otherwise it can be exploited to unset arbi

Re: coproc and existing variables

2016-05-17 Thread Grisha Levit
On Tue, May 17, 2016 at 5:14 PM, Grisha Levit wrote: getopts can probably benefit from a nameref check too actually quite a few places where unbind_variable is called have this problem. declare -n IGNOREEOF=UIDset +o ignoreeof declare -n POSIXLY_CORRECT=UIDset +o posix declare -n COMPREPLY=UIDf

Re: coproc and existing variables

2016-05-17 Thread Chet Ramey
On 5/17/16 12:28 PM, Grisha Levit wrote: > > On Tue, May 17, 2016 at 11:56 AM, Chet Ramey > wrote: > > Should the coproc code remove the > nameref attribute and use the name supplied to the coproc command as the > name of the array, or should it resolve th

Re: coproc and existing variables

2016-05-17 Thread Grisha Levit
That's also what mapfile and read -a do. On Tue, May 17, 2016 at 12:28 PM, Grisha Levit wrote: > > On Tue, May 17, 2016 at 11:56 AM, Chet Ramey wrote: > >> Should the coproc code remove the >> nameref attribute and use the name supplied to the coproc command as the >> name of the array, or shou

Re: coproc and existing variables

2016-05-17 Thread Grisha Levit
On Tue, May 17, 2016 at 11:56 AM, Chet Ramey wrote: > Should the coproc code remove the > nameref attribute and use the name supplied to the coproc command as the > name of the array, or should it resolve the nameref and use `x' as the > name of the coproc? > I think the latter makes sense since

Re: coproc and existing variables

2016-05-17 Thread Chet Ramey
On 5/16/16 4:44 PM, Grisha Levit wrote: > 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: What do you think should happen here? Should the coproc code remove the

Re: coproc and existing variables

2016-05-16 Thread 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]+ Donecoproc ref { :; }decla

Re: coproc and existing variables

2016-04-24 Thread Chet Ramey
On 4/21/16 2:39 PM, Grisha Levit wrote: > On Thu, Apr 21, 2016 at 1:22 PM, Chet Ramey 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 set

Re: coproc and existing variables

2016-04-21 Thread Grisha Levit
On Thu, Apr 21, 2016 at 1:22 PM, Chet Ramey 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

Re: coproc and existing variables

2016-04-21 Thread Chet Ramey
On 4/21/16 12:36 AM, Grisha Levit wrote: > A few issues inspired by the coproc proposal in this > thread: http://lists.gnu.org/archive/html/bug-bash/2016-04/msg00050.html > > 1. coproc unsets readonly NAME after the process completes Yes. This is a gray area. Under some circumstances, e.g, geto

Re: coproc and existing variables

2016-04-21 Thread Piotr Grzybowski
On 21 Apr 2016, at 09:36, Grisha Levit wrote: > A few issues inspired by the coproc proposal in this thread: > http://lists.gnu.org/archive/html/bug-bash/2016-04/msg00050.html > > 1. coproc unsets readonly NAME after the process completes [..] > 2. Segfault if NAME is an existing associative ar

coproc and existing variables

2016-04-21 Thread Grisha Levit
A few issues inspired by the coproc proposal in this thread: http://lists.gnu.org/archive/html/bug-bash/2016-04/msg00050.html 1. coproc unsets readonly NAME after the process completes $ declare -p UID; coproc UID { :; }; wait; declare -p UID declare -ir UID="501" bash: UID: readonly variable bas