Re: [PATCH] data: Avoid attempting to assign readonly shell vars

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2014-12-18 at 14:18 -0600, Richard Tollerton wrote:
> Richard Purdie <richard.purdie@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?

It might be an idea, it seems crazy that scripts can't tell if a given
action is going to result in their termination.

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.

Cheers,

Richard