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.
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 produce locally scoped va
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 self-referenc
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 a
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
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; decl
Hey,
confirmed, this is what happens by construction.
this one is going to be tricky, expansion happens on the shell line, way
before it comes to execution. I do not see reparsing again at execute_command
even if we had means, which we dont, to store the information from history
expansion to
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
On Thu, May 05, 2016 at 10:30:04AM +0200, Piotr Grzybowski wrote:
> 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 di
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
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
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:
h
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
13 matches
Mail list logo
