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

[Richard Tollerton]

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

> On Wed, 2014-12-17 at 19:11 -0600, Richard Tollerton wrote:
>> The fix is to attempt to modify the variable in a subshell before doing
>> the assignment.
>
> Isn't this going to involve fork() calls for every single shell
> variable?

Yes :(

I'm not quite sure how to rigorously check the performance difference;
is there a decent test case that exercises this and only this?

> 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?

The only *unambiguous* alternative that I see is to rewrite environment
setup to use env. That is, instead of generating:

export A=B
export C=D
...
do_fn () { fn; }
do_fn

We could do:

env - \
A=B \
C=D \
/bin/sh -c 'do_fn() { fn; }; do_fn;'

But obviously that is an extremely intrusive change.

[1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html
[2] http://stackoverflow.com/questions/4440842/test-if-a-variable-is-read-only
[3] http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_01
[4]
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_08_01

> Cheers,
>
> Richard

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