[bitbake-devel] [PATCH] data: Avoid attempting to assign readonly shell vars

[Richard Tollerton]

Richard Purdie <richard.purdie at linuxfoundation.org> writes:

> On Thu, 2014-12-18 at 14:18 -0600, Richard Tollerton wrote:
>> Richard Purdie <richard.purdie at linuxfoundation.org> writes:
>> > There must be a better way to do this?
>> 
>> Not unless we rewrite how we set up the environment. My reading of POSIX
>> is that no query facility exists for determining the read-only status of
>> a variable [1] [2], and that the only permitted action for attempting to
>> set a read-only variable is to exit [3] [4].
>> 
>> I suppose that enforcing a hard dependency on bash (via #!/usr/bin/env
>> bash) could work around this, since this only seems to appear in POSIX
>> mode; but I'm not yet convinced that the bash execution behavior when
>> run as bash (vs sh) won't change in the future. Should I bring this up
>> on bug-bash?
>
> It might be an idea, it seems crazy that scripts can't tell if a given
> action is going to result in their termination.

Looks like bash's behavior of not exiting on readonly assignment
attempts is fairly longstanding and explicit, although not particularly
well documented [1]. So yes, switching from sh to bash would work around
this.

[1] http://article.gmane.org/gmane.comp.shells.bash.bugs/18756/


> As for addressing the problem, from my reading of the bash environment
> variables, there looks like a finite list of them which could cause
> problems, so a blacklist may be an option, albeit an annoying one.
>
> There is a correctness issue here since if we set something, we really
> do want it set or an error in many cases.

What do you think about this for a fix:

This only appears to be an issue with code that's using bb.data as a
part of a shell script generation, which AFAIK is only done from
terminal.py to build a run.do_terminal. (Otherwise, nothing would be
building right now.) What if we run e.g. `env -i run.do_terminal`
instead of `run.do_terminal`? That will completely clear the environment
prior to execution.

I'll try to take a stab at implementing this.

> Cheers,
>
> Richard

-- 
Richard Tollerton <rich.tollerton at ni.com>