[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?
Re: Race in bash-4.3 'typeset'?, L. A. Walsh, 2016/10/25
- Re: Race in bash-4.3 'typeset'?,
Stuart Shelton <=