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_nameref_value (at the moment passing NULL as first argument
sigsegs (due to valid_array_reference not checking if name is NULL)).
The attached patch fixes errors in your report (please note that if in
variables.c:2877 also can be simplified) and the above.
Concerning exporting the namerefs, we are a bit back at our earlier discussion
and patch proposal (export -r).
cheers,
pg
check_NULL_after_bind_allow_to_enter_valid_nameref_value_with_empty_string.patch
Description: Binary data
On 14 May 2016, at 18:41, 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 in some cases when the value is an
> empty string:
>
> declare -n r; : ${r=}
> declare -n r; r=""
> declare -n r; printf -v r ''
>
> r=
> ""; declare
> -n r
>
> Each of these result in:
>
> $ declare
> -p r
>
> declare -n r=""
> Which itself is invalid:
>
> $ declare -n r=""
>
> bash:
> declare: `': not a valid identifier
> This new nameref takes assignments but doesn’t seem to do anything with them.
> It does cause at least one segfault though:
>
> $ declare -n r; r=""
>
> $
> export r# or readonly r
>
> Segmentation fault:
> 11
Re: declare [-+]n behavior on existing (chained) namerefs
On 13 May 2016, at 23:31, Grisha Levit wrote: > All the behavior inside functions now seems consistent with what is in the > docs. But the behavior at global scope still seems strange (sorry if this is > still a WIP): > Each of the following produces different results in global scope and inside a > function: [..] judging from the comments in declare_internal the behaviour in global scope is intentional, while at the same time in function scope, the local variables are created unconditionally. when I type: declare -n r=a I would expect a new variable r with nameref attribute to be created pointing to variable of name a, no matter what kind of wicked chains of namerefs Grisha created earlier. Concerning declare +n r=a I am not sure, but it would seem as logical to just create a variable r of value a. After all this is what those command say: declare and assign a variable. If you want nameref resolving, declare is not the correct place to do it. Both fixes can be easily done in declare_internal, decision being the difficult part. cheers, pg
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=""declare -n r; printf -v r ''
r=""; declare -n r
Each of these result in:
$ declare -p rdeclare -n r=""
Which itself is invalid:
$ declare -n r=""
bash: declare: `': not a valid identifier
This new nameref takes assignments but doesn’t seem to do anything with
them. It does cause at least one segfault though:
$ declare -n r; r=""
$ export r# or readonly r
Segmentation fault: 11
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 ("REPLY", input_string, 0);-
VUNSETATTR (var, att_invisible);- if (readonly_p (var) ||
noassign_p (var))++ if (var == 0 || readonly_p (var) ||
noassign_p (var))
retval = EXECUTION_FAILURE;+ else+VUNSETATTR
(var, att_invisible);
xfree (input_string);
return (retval);
On Fri, May 6, 2016 at 11:39 AM, Chet Ramey wrote:
> 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, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>
Re: Cannot clone from anonymous git
yeah, started yesterday, seems like a reaource allocation problem, I would avoid clones, if possible, and fetch only certain branches. if you already have a piece of repo that is. usually pulls work after a couple of tries. pg El 13/05/2016 23:41, "Mike Frysinger" escribió: > On 13 May 2016 15:42, Eduardo A. Bustamante López wrote: > > http://savannah.gnu.org/git/?group=bash lists: > > > > | Getting a Copy of the Git Repository > > | > > | Anonymous clone: > > | > > | git clone git://git.savannah.gnu.org/bash.git > > | > > | Member clone: > > | > > | git clone @git.sv.gnu.org:/srv/git/bash.git > > > > When I try to clone: > > > > | dualbus@hp ~ % git clone git://git.savannah.gnu.org/bash.git > > | Cloning into 'bash'... > > | fatal: Could not read from remote repository. > > | > > | Please make sure you have the correct access rights > > | and the repository exists. > > > > The links here appear to work: http://git.savannah.gnu.org/cgit/bash.git > > savannah in general is having troubles. pretty sure there's not much > bash can do but wait for them to resolve things. > -mike >
