Re: coproc and existing variables

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

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

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

Bash 4.4 SIGINT during command substitution (?) causes borked terminal

Seems to only happen with bash 4.4. Reproduce with something like the below. Sometimes I have to run this a few times in a row to trigger the issue but usually just once is sufficient. kill -INT -$$ & while $(:); do $(:); done Once triggered, the terminal becomes completely messed up, with output

Re: coproc and existing variables

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: Bash 4.4 SIGINT during command substitution (?) causes borked terminal

Grisha Levit writes: > My keyboard input is “1234567890”, which produces: > > bash-4.4$ 24580bash: 13679: command not found Probably two processes competing for terminal input. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 827

export/readonly unset value of target variable if passed an array reference

$ var=foo; declare -n ref=var[0] $ readonly ref $ declare -p vardeclare -ar var works even with readonly variables: $ readonly RO=foo $ declare -n ref=RO[0] $ readonly ref bash: RO: readonly variable $ declare -p ROdeclare -r RO presumably they should behave as if they were passed a subscripted

Re: coproc and existing variables

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

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

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

nameref subscript assignment with unset target var

Multiple variables with the same name are created at the same scope when doing assignments to subscripts of nameref variables that point to variables that are unset. $ unset var; declare -n ref=var; ref[0]=foo $ declare -p refdeclare -a ref=([0]="foo") I think the more reasonable thing would be t

Re: ++ causes 2 variables to increment

Thanks Grisha, Sorry for putting you through analysing my faulty example. Phil On 16 May 2016 at 05:58, Grisha Levit wrote: > > On Sun, May 15, 2016 at 4:42 PM, phil colbourn > wrote: > > # here, M=2 >> >> > It's not -- the value of $M here is the string "F[word]". Your print > function r

Re: Bash 4.4 SIGINT during command substitution (?) causes borked terminal

On 5/17/16 1:55 PM, Grisha Levit wrote: > Seems to only happen with bash 4.4. Reproduce with something like the > below. Sometimes I have to run this a few times in a row to trigger the > issue but usually just once is sufficient. Yeah, it's a really narrow race window. It will be fixed in bash-4