Re: Assigning to BASHPID fails silently

[Martijn Dekker]

Op 19-10-16 om 15:18 schreef Chet Ramey:
> On 10/17/16 2:38 PM, Martijn Dekker wrote:
>> bash 4.4.0 (I did not investigate other versions) does not produce an
>> error message if you try to assign something to the BASHPID readonly
>> using either arithmetic or normal assignment. Other readonlies produce a
>> message on an assignment attempt. BASHPID seems to be an exception.
> 
> BASHPID is a dynamic variable.  There should be a sentence in the man
> page that says assignments to it have no effect (as it does for GROUPS
> and FUNCNAME, for example).

Assigning to BASHPID most certainly does have an effect. Since you
didn't quote that part, I think you might have missed my point that
attempting this will silently exit the shell without any error message,
causing the problem to be hard to track down. This is different from
GROUPS and FUNCNAME, where the shell silently continues (causing the
problem to be hard to track down in a completely different way -- if
anything, that's worse!).

> It probably should not be readonly, though
> it has been marked as such in previous versions of bash.

In what possible context would assigning to any of these variables make
sense, or be an indication of anything other than a fatal bug in the
script? I think they should all be readonly, and produce a proper
diagnostic error message upon exit if assigning is attempted.

If you're keeping them non-readonly for backwards compatibility reasons,
then IMHO that is misguided; assignments silently fail, which is far
worse than erroring out. Unsetting GROUPS and FUNCNAME first does work,
but it's a rare script that unsets variables before use. Maybe a
compromise would be to introduce a semi-readonly state, where unset
works but assignments fail.

Thanks,

- Martijn