Re: namref dicussion continued: [PATCH] export -r reference

Oh I see you talked about some of this already in the "chained nameref" thread. I haven't read that one yet... I wonder why `export -r` requires a different solution because it's pretty much the same underlying problem.

Re: namref dicussion continued: [PATCH] export -r reference

On Thu, May 5, 2016 at 2:46 AM, Piotr Grzybowski wrote: > ok, so Dan wants this patch. Yes I think your bash patch is probably an improvement at least in this particular case. > Maybe you can comment on wether the patches are valid. The posix export and readonly don't

Re: declare [-+]n behavior on existing (chained) namerefs

On 4/28/16 9:49 PM, Grisha Levit wrote: > In a slightly different version, with `declare -n r; r=a', the function > exits with code 1 after the `r=a' statement: > > $ declare -nt r=a; f() { declare a; declare -n r; r=a; declare -p a r; }; > f; echo $? > 1 In this case, you create a

Re: History modifier :p ignored prior to another history reference

On 5 May 2016, at 20:08, Piotr Grzybowski wrote: > [..] > Currently the design indicates: :p applies to the whole line. As Dean just has pointed out to me, this sentence is obviously wrong. it should be: Currently the design indicates: the last :p applies to the whole line, the information

Re: declare [-+]n behavior on existing (chained) namerefs

On 5/2/16 1:55 PM, Piotr Grzybowski wrote: > Hi, > > I hope the attached patch does not break to much; it addresses the masking: > >> declare -nt r=a; f() { declare a; declare -n r=a; declare -p a r; }; f > > as per Grisha's report; it tries to enlighten make_local_variable to the > existence

Re: declare [-+]n behavior on existing (chained) namerefs

On 4/29/16 12:50 PM, Grisha Levit wrote: > The only buggy behavior when inside of functions (ignoring scope issues) > seems to be that `declare -n ref’ unsets the value of $ref if it previously > pointed to a variable that is unset. > > |$ f() { unset var; declare -n ref=var; declare -n ref;

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: set isearch-terminators "\r" in .inputrc causes malloc assert fails/death

hi, I cannot replicate it in anyway on mac os x or linux. Could you please define "sometimes", and supply the exact version of bash that shows this behavior, and the version you refer to as "my old bash"? I have a distinct feeling that it is something different than my old bash. cheers, pg

Re: namref dicussion continued: [PATCH] export -r reference

ok, a small correction, the problem lies in exportscope:40, but none of the patches mentioned solve it, the same behaviour of the test can be recovered with just export instead of declare on this line (at least proves that the patches dont break it ;-)). some other make_local_variable issue I

Re: namref dicussion continued: [PATCH] export -r reference

ok, so Dan wants this patch. I took a look at your script, there are two cases it addresses: exporting nameref and doing it from inside the function scope, I applied both patches: nameref masking in scope: https://lists.gnu.org/archive/html/bug-bash/2016-05/msg00012.html exporting namerefs: