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]
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] ?
> interpret "on the variable" as doing a depth first search (going as deep
as possible over the reference chain) in order to find the variable
Yes, that makes perfect sense, but I think all the issues above don't
concern the search for the variable, but rather modifications to the
references thems
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
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
this one does not seem like a bug to me, rather a decision made by the author:
to interpret "on the variable" from this:
"All references, assignments, and attribute modifications to name, except for
changing the -n attribute itself, are performed on the variable referenced by
name’s value."
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
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
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
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=
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.
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
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
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
declare -n name=value, when name is already a nameref, shows the following
presumably inconsistent behavior:
Given a chain of namerefs like:
ref_1 -> ref_2 -> ... -> ref_i ... -> ref_N [-> var]
- If ref_N points to a name that is not a nameref, the operations declare
-n ref_N=value and dec
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
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
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
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
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
On 4/26/16 4:50 PM, Eric Pruitt wrote:
> On Tue, Apr 26, 2016 at 01:54:12PM -0400, Chet Ramey wrote:
>> Thanks for the report. I will fix this before bash-4.4 is released.
>
> Thank you. I am happy to compile a prerelease build to try out your
> solution if you want another tester before you roll
Hello,
Recently we came across a bug in bash which was introduced by below patch :
http://git.savannah.gnu.org/cgit/bash.git/commit/?id=d5d00961
In bash 4.2 this could lead to a race condition. 'yy_readline_get ()' function
sets 'terminate_immediately' to 1 before calling readline() at [1].
Hello,
Recently we came across a bug in bash which was introduced by below patch :
http://git.savannah.gnu.org/cgit/bash.git/commit/?id=d5d00961
In bash 4.2 this could lead to a race condition. 'yy_readline_get ()' function
sets 'terminate_immediately' to 1 before calling readline() at [1].
On 4/26/16 10:49 PM, Grisha Levit wrote:
> Thanks for the explanation. I'd read that thread but thought the change
> was supposed to only modify the behavior when explicitly specifying the
> --debugger option. That also seems to be the gist of the original RedHat
> bugzilla request that prompted
Is the behavior below expected? In the presence of a local $var, the
*global* $var can be modified by assigning a value to a local nameref that
points to a global nameref that points to $var. However, the local nameref
expands to the *local* value of $var.
lref --> gref --> var
Example:
var=Gf()
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
On Wed, Apr 27, 2016 at 07:33:25AM -0400, Grisha Levit wrote:
> Sorry that wasn???t very clear. I only included that case to demonstrate that
> seemingly contradictory things are happening:
>
>- "${_+$@}" expands each positional parameter to a separate word,
>following the usual "$@" behav
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
Sorry that wasn’t very clear. I only included that case to demonstrate that
seemingly contradictory things are happening:
- "${_+$@}" expands each positional parameter to a separate word,
following the usual "$@" behavior
- The usual "$@" behavior is to expand to 0 words if there are no
On 26 Apr 2016, at 21:03, Grisha Levit wrote:
> This behavior seems very strange. This example is with $@ but it seems the
> same for ${array[@]}
>
> The manual says for ${parameter:-word}:
>
> > If parameter is unset or null, the expansion of word is substituted.
>
> In this case, $@ is exp
Hi Grisha,
confirmed.
I think this one fixes it:
diff --git a/variables.c b/variables.c
index 69ed170..9eeda46 100644
--- a/variables.c
+++ b/variables.c
@@ -2636,9 +2636,14 @@ bind_variable_internal (name, value, table, hflags,
aflags)
#if defined (ARRAY_VARS)
/* declare -n foo=x[2] *
31 matches
Mail list logo
