COMPREPLY as a nameref to a readonly associative array

It's possible to change any readonly associative array to the indexed array (''): $ declare -rA var=([foo]=bar) $ f() { declare -ng COMPREPLY=var; } $ compgen -F f . bash: compgen: warning: -F option may not work as you expect $ declare -p var declare -ar var=([0]="")

COMP_WORDS, namerefs and readonly variables

In bind_comp_words, the readonly attribute is unconditionally removed from COMP_WORDS, even if that variable is a nameref. This allows unsetting the readonly attribute on any arbitrary variable. v = find_variable ("COMP_WORDS"); if (v == 0) v = make_new_array_variable ("COMP_WORDS")

$* vs ${ARRAY[*]} differences in some parameter expansions

bash currently handles all parameter expansions with $* and $@ as described in interpretation 888, and the behavior when using an array subscripted with @ matches identically the behavior of the examples concerning $@. However, the behavior when using an array subscripted with * does not always mat

Re: [BUG] With null IFS, ${1+$*}, ${var-$*}, etc. don't generate fields

On 2/24/17 4:07 PM, Chet Ramey wrote: > On 2/24/17 3:20 PM, Grisha Levit wrote: >> >> >> On Sat, Feb 18, 2017 at 8:35 PM, Martijn Dekker > > wrote: >>> >>> When IFS is null, unquoted $* within an unquoted substitution (e.g. >>> ${1+$*} or ${unset_var-$*}) joins the PPs toge

Re: [BUG] With null IFS, ${1+$*}, ${var-$*}, etc. don't generate fields

On 2/24/17 3:20 PM, Grisha Levit wrote: > > > On Sat, Feb 18, 2017 at 8:35 PM, Martijn Dekker > wrote: >> >> When IFS is null, unquoted $* within an unquoted substitution (e.g. >> ${1+$*} or ${unset_var-$*}) joins the PPs together into one field, as if >> either "$*" or

Re: [BUG] With null IFS, ${1+$*}, ${var-$*}, etc. don't generate fields

On Sat, Feb 18, 2017 at 8:35 PM, Martijn Dekker wrote: > > When IFS is null, unquoted $* within an unquoted substitution (e.g. > ${1+$*} or ${unset_var-$*}) joins the PPs together into one field, as if > either "$*" or the whole substitution were quoted. > > POSIX says the unquoted substitution is

Re: Follow-up to Non-expanding here-documents inside command substitution

On 2/24/17 12:14 AM, Kevin Grigorenko wrote: > On February 11th 2017, there was a discussion on the topic of > "Non-expanding here-documents inside command substitution are subject to > newline joining" where it was confirmed that Bash contains a bug. Two > questions: > > 1. Is there a plan to fix

Re: Follow-up to Non-expanding here-documents inside command substitution

On Thu, Feb 23, 2017 at 11:14 PM, Kevin Grigorenko wrote: > On February 11th 2017, there was a discussion on the topic of "Non-expanding > here-documents inside command substitution are subject to newline joining" > where it was confirmed that Bash contains a bug. Two questions: > > 1. Is there a