[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: param expansion with single-character special vars in the environmen
From: |
Piotr Grzybowski |
Subject: |
Re: param expansion with single-character special vars in the environment |
Date: |
Thu, 28 Apr 2016 00:47:56 +0200 |
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:
diff --git a/builtins/declare.def b/builtins/declare.def
index a1e9b4e..53b688c 100644
--- a/builtins/declare.def
+++ b/builtins/declare.def
@@ -719,7 +719,7 @@ declare_internal (list, local_var)
if (onref)
aflags |= ASS_NAMEREF;
v = bind_variable_value (var, value, aflags);
- if (v == 0 && onref)
+ if (v == 0 && onref || ( onref && !legal_identifier(value)))
{
sh_invalidid (value);
assign_error++;
2. the other matter that you, Grisha, reported, and Eduardo commented heavily
on, is not a matter of creating a nameref, but a matter of overriding readonly
variables identifiers, a matter of discussion if it should be allowed (coproc
bugs and getopt discussed lately being other examples). But it is not a bug,
the decision was made to allow namerefs, they work as documented, the readonly
variables are not touched, they identifiers are used as per definition of
nameref. A matter of discussion should be: how to protect some variables, like
the ones that were mentioned (PATH, TMOUT, etc). If the readonly means also "do
not give and attributes" then declare -n (and others) should be forbidden on
readonly variables. On the other hand we can think of declaring variable as:
`protected a' which would mean that no modification of attributes is possible,
but variable data can be changed, as opposed to `readonly a' which could mean
"data of the variable cannot be changed" and finally both as, e.g.: `exclusive
a' meaning readonly|protected.
3. I have no idea about this global/local thing Grisha reported.
cheers,
pg
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, even for variables that bash is using internally:
>
> $ TIMEFORMAT='%R'
>
> $ time bash -c
> 'readonly TMOUT=5; read'
> 5.007
>
> $ time bash -c
> 'readonly TMOUT=5; ref=$TMOUT; declare -n ref; ref=10; declare -n TMOUT; read'
> 10.004
> The same technique works for circumventing PATH in a restricted shell:
>
> $ PATH='/restricted/bin' $BASH -r -c 'type sed; ref=$PATH; declare -n ref;
> ref=/usr/bin; declare -n PATH; type sed'
> bash
> bash: line
> 0: type
> : sed: not found
> sed is /usr/bin/sed
>
- Re: param expansion with single-character special vars in the environment, (continued)
- Re: param expansion with single-character special vars in the environment, Eduardo A . Bustamante López, 2016/04/27
- Re: param expansion with single-character special vars in the environment, Eduardo A . Bustamante López, 2016/04/27
- Re: param expansion with single-character special vars in the environment, Piotr Grzybowski, 2016/04/27
- Re: param expansion with single-character special vars in the environment, Eduardo A . Bustamante López, 2016/04/27
- Re: param expansion with single-character special vars in the environment, Eduardo A . Bustamante López, 2016/04/27
- Re: param expansion with single-character special vars in the environment, Grisha Levit, 2016/04/27
- Re: param expansion with single-character special vars in the environment, Piotr Grzybowski, 2016/04/27
- Re: param expansion with single-character special vars in the environment, Piotr Grzybowski, 2016/04/27
- Re: param expansion with single-character special vars in the environment, Grisha Levit, 2016/04/27
- Re: param expansion with single-character special vars in the environment, Piotr Grzybowski, 2016/04/27
Re: param expansion with single-character special vars in the environment,
Piotr Grzybowski <=
- Re: param expansion with single-character special vars in the environment, Piotr Grzybowski, 2016/04/27
- Re: param expansion with single-character special vars in the environment, Grisha Levit, 2016/04/27
- Re: param expansion with single-character special vars in the environment, Piotr Grzybowski, 2016/04/28
- Re: param expansion with single-character special vars in the environment, Piotr Grzybowski, 2016/04/28
- Re: param expansion with single-character special vars in the environment, Grisha Levit, 2016/04/28
Re: param expansion with single-character special vars in the environment, Eduardo A . Bustamante López, 2016/04/27