Re: coproc and existing variables

[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
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'm interested in opinions here.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: coproc and existing variables

[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 that is what usually happens with
assignments to namerefs pointing to unset variables.

i.e.:

declare -n ref=x
ref=(63 64)

producing the same result as

declare -n ref=x
coproc ref { :; }

seems reasonable.

Re: coproc and existing variables

[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 should it resolve the nameref and use `x' as the
>> name of the coproc?
>>
>
> I think the latter makes sense since that is what usually happens with
> assignments to namerefs pointing to unset variables.
>
> i.e.:
>
> declare -n ref=x
> ref=(63 64)
>
> producing the same result as
>
> declare -n ref=x
> coproc ref { :; }
>
> seems reasonable.
>

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

[Grisha Levit]

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
getting mixed in with input, typed characters not all getting echoed back,
etc. It’s a bit hard to explain but hopefully this screencast [1] will
demonstrate sufficiently.

My keyboard input is “1234567890”, which produces:

bash-4.4$ 24580bash: 13679: command not found

[1] https://asciinema.org/a/10bbfdgevcku4mdx9yls5uojn
​

Re: coproc and existing variables

[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 the nameref and use `x' as the
> name of the coproc? 
> 
> 
> I think the latter makes sense since that is what usually happens with
> assignments to namerefs pointing to unset variables.

Yes, I agree.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

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

[Andreas Schwab]

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 8276 4ED5
"And now for something completely different."

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

[Grisha Levit]

$ 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 variable

$ readonly var[0]
bash: readonly: `var[0]': not a valid identifier

​

Re: coproc and existing variables

[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() { :; }
compgen -F f f
declare -n BASH_REMATCH=UID
[[ . =~ . ]]

​

Re: coproc and existing variables

[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 arbitrary readonly variables.

$ declare -r RO=foo; declare -n OPTARG; getopts x x; declare -p RO
bash: declare: RO: not found

​

Re: coproc and existing variables

[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
bash: declare: RO: not found

​

nameref subscript assignment with unset target var

[Grisha Levit]

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 to create a new array variable
$var.

But the even weirder thing is that the original $ref is still there!

$ unset ref; declare -p refdeclare -n ref="var"

Even more values can be piled up with functions:

$ ref=global
$ f() { declare -n ref=var; ref[0]=foo1; }; f
$ f() { declare -n ref=var; ref[0]=foo2; }; f
$ declare -p refdeclare -a ref=([0]="foo2")
$ unset ref; declare -p refdeclare -a ref=([0]="foo1")
$ unset ref; declare -p refdeclare -- ref="global"

​

Re: ++ causes 2 variables to increment

[phil colbourn]

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 reports the value of "$((M*1))", which is, in fact "2": inside the
> arithmetic expression "M" is expanded to "F[word]" which is expanded to "2".
>
> > # without changing M, it is now 3!!
>
> Exactly, M does not change, it is still "F[word]".  But since F[word]
> changes, the value of $((M*1)) does change to reflect the new value of
> F[word].
>
> Instead of M=F[$W], I think you want to be doing M=${F[$W]}.
>

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

[Chet Ramey]

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.4.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/