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

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 perhaps for completeness

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 ends up getting bypassed i

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

hi, there are two problems: not checking NULL returned by bind_variable, and not allowing to enter valid_nameref_value. Since bind_variable can return NULL, that should be checked everywhere. Also NULL and empty strings are not valid nameref values, so the check should be added in valid_namer

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

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 ends up getting bypassed in some cases when the value is an empty string: declare -n r; : ${r=}declare -n r; r=""

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

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, C

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 ass

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

I can understand this, but perhaps this discussion is too general? in this particular case there is no point in the assignment. Unless you can convince me there is? pg On 5 May 2016, at 00:31, Dan Douglas wrote: > ...Also remember it isn't feasible to actually validate a "name" in a > script

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 do

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 expanded, but allowed th

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 erro

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 important to note that the n

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 me. It shouldn't howev

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

On 5/2/16 4:01 PM, Dan Douglas wrote: > 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 impo

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 important to note that the nameref attribute is throw

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 important to note that the n

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 makes some sense since

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

On 5/2/16 12:12 PM, Chet Ramey wrote: > 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

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 valid_array_reference as well t

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 clears

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 attributes. > > Once you conver

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 na

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 readonly variable. This fee

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 t

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 > support declare -n ref=a[x]

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 identifie

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

a short summary: 1. there is a real bug reported here: allowing namref on illegal identifiers, if we assume that the value of the variable that has nameref attribute is the name of the variable it refers to, then we have to require that declare -n a=b anly allows legal identifiers for b: di

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

On 27 Apr 2016, at 21:49, Eduardo A. Bustamante López wrote: > > Actually, this seems to be a special case, just because '5' is an invalid > variable name. But the problem still exists: > > | dualbus@hp ...src/gnu/bash % ./bash -c 'declare -r RO=x; r=$RO; declare -n > r; x=y; declare -n RO; R

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 sa

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

On Wed, Apr 27, 2016 at 3:49 PM, Eduardo A. Bustamante López < dual...@gmail.com> wrote: > f() { echo $r; }; declare -n r; r=/ f I'm not sure about the tempenv variable. > That case doesn't seem to be an issue since assignments here just create regular variables without attributes. $ a=(1); f

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

Here's the updated list of cases: | r=/; declare -n r | declare -n r=/ | declare -n r; r=/ | declare -n r; for r in /; do :; done | declare -n r; select r in /; do :; done <<< 1; echo x; echo $r | declare -n r; ((r=0)) | ((r=0)); declare -n r | r=/ declare -n r | f() { declare -n r; }; r=

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; d

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 inc

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 beh

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 r

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 i

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 ho

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 modifying the value of a di

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

On 25 Apr 2016, at 22:57, Grisha Levit wrote: > 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 [..] It seems to me that creating the reference should be allowed, but th

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