Re: param expansion with single-character special vars in the environment

On 5/27/16 1:38 PM, Grisha Levit wrote: > How about removing the nameref attribute from an existing readonly > variable? This is currently allowed but perhaps for completeness it should > be forbidden? For ksh93 compatibility, bash should prevent the readonly attribute from being removed from

Re: param expansion with single-character special vars in the environment

On Mon, May 2, 2016 at 11:55 AM, Chet Ramey wrote: > I agree; `declare' should not allow attempts to add the nameref attribute > to an existing readonly variable. How about removing the nameref attribute from an existing readonly variable? This is currently allowed but

Re: param expansion with single-character special vars in the environment

On 5/14/16 12:16 PM, Grisha Levit wrote: > One more case, which currently segfaults: > > |declare -n REPLY; read <<< / | > > easy fix: Thanks for the fix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey,

Re: param expansion with single-character special vars in the environment

On 5/14/16 12:41 PM, Grisha Levit wrote: > On Mon, May 2, 2016 at 2:30 PM, Chet Ramey > wrote: > > I ended up writing a new function: valid_nameref_value(name, flags) which > I can customize to serve this purpose. > > Looks like this

Re: param expansion with single-character special vars in the environment

One more case, which currently segfaults: declare -n REPLY; read <<< / easy fix: diff --git a/builtins/read.def b/builtins/read.def index 5e2348c..8f6bd2b 100644--- a/builtins/read.def+++ b/builtins/read.def @@ -797,9 +797,11 @@ assign_vars: } else var = bind_variable

Re: param expansion with single-character special vars in the environment

On 4/27/16 4:07 PM, Eduardo A. Bustamante López wrote: > Here's the updated list of cases: Thanks for the list of test cases; these were very helpful. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS,

Re: param expansion with single-character special vars in the environment

On 5/4/16 3:37 PM, Piotr Grzybowski wrote: > > On 4 May 2016, at 17:51, Chet Ramey wrote: > >> The issue I'm thinking about currently is whether or not to allow nameref >> variables to have numeric (integer) values. bash-4.3 didn't allow those >> values to be expanded, but allowed them to be

Re: param expansion with single-character special vars in the environment

...Also remember it isn't feasible to actually validate a "name" in a script because a name can contain a subscript with a command substitution that effectively requires parsing the full language. (there are some tricks like with `set -nv` and reading its output to shanghai the shell parser into

Re: param expansion with single-character special vars in the environment

On Wed, May 4, 2016 at 2:37 PM, Piotr Grzybowski wrote: > > On 4 May 2016, at 17:51, Chet Ramey wrote: > >> The issue I'm thinking about currently is whether or not to allow nameref >> variables to have numeric (integer) values. bash-4.3 didn't allow those >> values to be

Re: param expansion with single-character special vars in the environment

On 4 May 2016, at 17:51, Chet Ramey wrote: > The issue I'm thinking about currently is whether or not to allow nameref > variables to have numeric (integer) values. bash-4.3 didn't allow those > values to be expanded, but allowed them to be assigned. It doesn't seem > harmful to change the

Re: param expansion with single-character special vars in the environment

On 4/28/16 5:20 PM, Grisha Levit wrote: > > On Thu, Apr 28, 2016 at 3:14 PM, Piotr Grzybowski > wrote: > > b. we can forbid ># declare -n T >when T is a readonly variable > > > This is the one that makes the most sense to

Re: param expansion with single-character special vars in the environment

On Mon, May 2, 2016 at 1:59 PM, Grisha Levit wrote: > > On Mon, May 2, 2016 at 2:48 PM, Chet Ramey wrote: >> >> and this one throws away the nameref attribute: >> >> typeset -n foo ; typeset -i foo ; foo=7*6 ; typeset -p foo > > > I think it's

Re: param expansion with single-character special vars in the environment

On 5/2/16 2:59 PM, Grisha Levit wrote: > > On Mon, May 2, 2016 at 2:48 PM, Chet Ramey > wrote: > > and this one throws away the nameref attribute: > > typeset -n foo ; typeset -i foo ; foo=7*6 ; typeset -p foo > > > I think it's

Re: param expansion with single-character special vars in the environment

On Mon, May 2, 2016 at 2:48 PM, Chet Ramey wrote: > and this one throws away the nameref attribute: > > typeset -n foo ; typeset -i foo ; foo=7*6 ; typeset -p foo > I think it's important to note that the nameref attribute is thrown away at the `typeset -i foo' step, which

Re: param expansion with single-character special vars in the environment

On 4/27/16 8:36 PM, Grisha Levit wrote: > > On Wed, Apr 27, 2016 at 6:47 PM, Piotr Grzybowski > wrote: > > + if (v == 0 && onref || ( onref && !legal_identifier(value))) > > > Shouldn't this (and the other patch) check

Re: param expansion with single-character special vars in the environment

On 4/27/16 7:37 PM, Piotr Grzybowski wrote: > > sorry for the spam concerning the patch: it needs merging with what Eduardo > posted (excluding the `declare -n r; declare -n r;' regression bug), and what > is in #ifdef 0 in declare.def; I just found out that it is exactly what it > intends to

Re: param expansion with single-character special vars in the environment

On 4/27/16 4:07 PM, Eduardo A. Bustamante López wrote: > The 'mapfile' one is interesting, because it drops the nameref attribute from > the 'r' variable. Array variables can't have the nameref attribute. The process of creating and clearing the array with the name supplied as an argument

Re: param expansion with single-character special vars in the environment

On 4/27/16 8:41 AM, Grisha Levit wrote: > On Wed, Apr 27, 2016 at 7:37 AM, Piotr Grzybowski > wrote: > > It seems to me that creating the reference should be allowed, but the > access to the referenced variable should honor its

Re: param expansion with single-character special vars in the environment

On 4/25/16 3:48 PM, Grisha Levit wrote: > There seems to be a bug that if an array variable with a name matching one > of the special single-character variables exists, then that variable is > used during substring expansion and parameter transformation. > > There is also a potential issue with

Re: param expansion with single-character special vars in the environment

On Thu, Apr 28, 2016 at 3:14 PM, Piotr Grzybowski wrote: > b. we can forbid ># declare -n T >when T is a readonly variable > This is the one that makes the most sense to me. It shouldn't however be forbidden to do `declare -nr RO=foo' if RO is not already a

Re: param expansion with single-character special vars in the environment

ok, after some thinking, this one seems certain: 1. forbid adding nameref when the value is not a valid identifier: # declare -n reference=/ should be forbidden, as well as later assignments to nameref with strings being illegal identifiers, as we discussed/patched. what remains (rest of

Re: param expansion with single-character special vars in the environment

On 28 Apr 2016, at 02:36, Grisha Levit wrote: > > On Wed, Apr 27, 2016 at 6:47 PM, Piotr Grzybowski wrote: > + if (v == 0 && onref || ( onref && !legal_identifier(value))) > > Shouldn't this (and the other patch) check valid_array_reference as well to >

Re: param expansion with single-character special vars in the environment

On Wed, Apr 27, 2016 at 6:47 PM, Piotr Grzybowski wrote: > + if (v == 0 && onref || ( onref && !legal_identifier(value))) > Shouldn't this (and the other patch) check valid_array_reference as well to support declare -n ref=a[x] ?

Re: param expansion with single-character special vars in the environment

sorry for the spam concerning the patch: it needs merging with what Eduardo posted (excluding the `declare -n r; declare -n r;' regression bug), and what is in #ifdef 0 in declare.def; I just found out that it is exactly what it intends to do. I am sure we need to forbid the illegal

Re: param expansion with single-character special vars in the environment

wait, this one is all right, look: 1. you are making a readonly variable: readonly USER=sandbox 2. then you are creating a nameref: declare -n USER; from now on the assignments to USER are assignments to variable of name sandbox 3. then you create a variable sandbox and assign a value since

Re: param expansion with single-character special vars in the environment

On Wed, Apr 27, 2016 at 2:43 PM, Eduardo A. Bustamante López < dual...@gmail.com> wrote: > The attached patch seems to take care of at least these two cases: > I don't think legal_identifier is the correct test here since references to array subscripts or array[@] are valid.

Re: param expansion with single-character special vars in the environment

On Wed, Apr 27, 2016 at 08:58:47PM +0200, Piotr Grzybowski wrote: > On 27 Apr 2016, at 20:43, Eduardo A. Bustamante López wrote: > > > The attached patch seems to take care of at least these two cases: [..] > > your patch also adresses the original Grisha's report: > > declare -r T=5; ref=$T;

Re: param expansion with single-character special vars in the environment

On 27 Apr 2016, at 20:43, Eduardo A. Bustamante López wrote: > The attached patch seems to take care of at least these two cases: [..] > But I think Chet already considered this, given that the check in declare.def > was '#if 0'ed out. maybe for a reason, after your patch: bash-4.4$ declare -n

Re: param expansion with single-character special vars in the environment

On Wed, Apr 27, 2016 at 3:10 PM, Eduardo A. Bustamante López < dual...@gmail.com> wrote: > On Mon, Apr 25, 2016 at 03:48:17PM -0400, Grisha Levit wrote: > > # Expected behavior:set -- 1 2 3echo ${@@A} # set -- '1' '2' > > This is actually expected behaviour. Sorry, that was confusing. I

Re: param expansion with single-character special vars in the environment

On Mon, Apr 25, 2016 at 03:48:17PM -0400, Grisha Levit wrote: > There seems to be a bug that if an array variable with a name matching one > of the special single-character variables exists, then that variable is > used during substring expansion and parameter transformation. [...] > # Expected

Re: param expansion with single-character special vars in the environment

On 27 Apr 2016, at 20:43, Eduardo A. Bustamante López wrote: > The attached patch seems to take care of at least these two cases: [..] your patch also adresses the original Grisha's report: declare -r T=5; ref=$T; declare -n ref; ref=10; declare -n T; cheers, pg

Re: param expansion with single-character special vars in the environment

The attached patch seems to take care of at least these two cases: | dualbus@hp ...src/gnu/bash % ./bash --norc --noprofile -c 'r=@; declare -n r' | ./bash: line 0: declare: @: invalid variable name for name reference | | dualbus@hp ...src/gnu/bash % ./bash --norc --noprofile -c 'declare -n

Re: param expansion with single-character special vars in the environment

On Wed, Apr 27, 2016 at 08:41:20AM -0400, Grisha Levit wrote: [...] > The above works when the readonly variable has a value that is also a valid > identifier. In my previous example I worked around this using the fact > that ref=; > declare -n ref does not check to make sure that $ref is a valid

Re: param expansion with single-character special vars in the environment

Hi, On 27 Apr 2016, at 14:41, Grisha Levit wrote: > Once you convert the variable to a reference, you can control its value by > modifying the value of a different variable with the name that corresponds to > the value of the readonly variable, so “access to the referenced variable > should

Re: param expansion with single-character special vars in the environment

On Wed, Apr 27, 2016 at 7:37 AM, Piotr Grzybowski wrote: It seems to me that creating the reference should be allowed, but the > access to the referenced variable should honor its attributes. > Once you convert the variable to a reference, you can control its value by

Re: param expansion with single-character special vars in the environment

A related issue is with adding the nameref attribute to a readonly variable. Not sure if that should be allowed, as it can be used to change the meaning of the variable, even for variables that bash is using internally: $ TIMEFORMAT='%R' $ time bash -c 'readonly TMOUT=5; read'5.007 $ time bash -c