bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Race in bash-4.3 'typeset'?


From: Stuart Shelton
Subject: Re: Race in bash-4.3 'typeset'?
Date: Tue, 25 Oct 2016 21:09:23 +0100

> On 25 Oct 2016, at 20:45, L. A. Walsh <bash@tlinx.org> wrote:
> Stuart Shelton wrote:
>> I have some code which evals a configuration file - but before doing so 
>> attempts to validate the content.  It does this by taking each potential 
>> keyword from the file and then doing:
>> 
>> if typeset -p | grep -q "^declare -. ${var}$”; then
>> 
>> … to determine whether the keyword in question exists as a declared but 
>> unset variable in the script.
>>  
> ---
>   I don't think you can do that, primarily because
> you can't see the fact that something is declared but unset.
> "typeset -p" displays "attributes" AND "values".  If the variables has
> no value, then how would it display that?

The cases appear, purely by inspection, to be:

Not declared: trivially, `typeset -p` doesn’t include the value;
Declared (even as local) but unassigned: `typeset -p` includes "declare -- 
varname";
Declared and assigned: `typeset -p` includes "declare -- varname=‘value’”

… although how much of this is by design and how much by chance I’m not sure ;)


>   Also, in the above, what if the variable is declared as an
> integer and exported?  Your grep-expression won't match, as
> it only allows for 1 flag.  You might want to use grep -Pq and
> put a "+" after the "-." 

This is a very good point - I only coded for the cases I’ve seen, and the 
single-flag situation covers this.  I will update it, though, to reflect the 
wider range of possible values...


> Also, what is ${var} supposed to contain?  I'm guessing that var
> isn't your variable you are testing for but maybe the name of the
> var?

Yes, in this case ‘var’ is a loop-variable which cycles through each keyword in 
the configuration file to be validated.


> I've had that confusion in some scripts where I had functions taking
> arrays of 'var' -- which for some meant arrays of values, but in
> other cases I needed the names of the vars that contained those values.
> I ended up with a weak rule to try to always append "nam[e]" or "str[ing]"
> to things that were to be interpreted as names or strings, then
> using nothing, or 'ptr' or 'ref' on the end to indicate it was
> a reference to the value, like:
> 
> var=33
> varname=var
> echo "name of var=$varname, value=$var"

Also a very good point :)


>> However, I am seeing cases where the above incorrectly fails, or where 
>> executing this line twice in immediate succession will fail on the first 
>> invocation and then succeed on the second.  
> ----
>   Is it being assigned a value between invokations?

Nope - literally run the same command twice in immediate succession, and the 
output differs, with the first omitting any value or causing a SIGPIPE to be 
generated, and the second with the expected value which reflects the 
environment.  The second call always appears to do the right thing, though - 
and given that a sleep before (or between, although the second case has always 
succeeded) the command appears to have no effect, I wonder whether there’s some 
counter or flag not being updated correctly?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]