On 1/22/25 8:03 AM, MacBeth wrote:
$ unset BASH_COMPAT $ declare -p BASH_COMPAT bash: declare: BASH_COMPAT: not found $ BASH_COMPAT=foobar bash: BASH_COMPAT: foobar: compatibility value out of range $ declare -p BASH_COMPAT declare -- BASH_COMPAT="foobar" $ BASH_COMPAT=4.4 /opt/homebrew/bin/bash --noprofile -l bash: BASH_COMPAT: foobar: compatibility value out of range bash-5.2$ declare -p BASH_COMPAT declare -x BASH_COMPAT="4.4" bash-5.2$ shopt compat44 compat44 on bash-5.2$It seems the child bash somehow acquires two versions of BASH_COMPAT, which each version is used in different parts of the bash code, and also converts BASH_COMPAT to EXPORT.
It does not. The child process sees BASH_COMPAT=4.4, since you explicitly added it to the environment passed to the process. The faulty assumption is that the child process is printing the error message.
Apparently the export is normal, although I was unaware of this phenomenon, as the below shows.
Bash auto-exports variables it inherits in its environment. This is longstanding shell behavior.
Or perhaps that second error is produced by the parent shell before starting the child shell. If so, I wonder why it is reevaluating BASH_COMPAT=foobar in the parent shell before initiating the child shell.
This is right, but the order is wrong. It's not reevaluating it `before
initiating the child shell.' It happens between the fork and wait, so
they're both running at that point.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
