On Tue, Jan 21, 2025 at 11:25 PM Lawrence Velázquez <v...@larryv.me> wrote:
> On Tue, Jan 21, 2025, at 9:49 PM, MacBeth wrote: > > "Bash-5.0 is the final version for which there will be an individual > shopt > > option for the previous version. Users should use BASH_COMPAT on bash-5.0 > > and later versions." > > > > ...Not sure if this means `shopt compat50` should work or not. > > It shouldn't, and never has. > > > https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/shopt.def?h=bash-5.1#n178 > > > > But either > > way, `shopt compat50` should be consistent with BUILTINS/shopt. > > Yeah, probably. > > Yes, as Koichi linked, that is what makes sense to me that should be removed to remove confusion: https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?h=devel&id=42c49d621d9341a530bca9422d7000087593e6bb#n11877 > > 2) Bash errors on valid BASH_COMPAT values? Am I missing something here? > > > > "BASH_COMPAT...For example, 4.2 and 42 are valid values that correspond > to > > the compat42 shopt option and set the compatibility level to 42. The > > current version is also a valid value." > > > >> BASH_COMPAT=4.4 bash --noprofile -l > > bash: BASH_COMPAT: compat44: compatibility value out of range > > bash-5.2$ shopt compat44 > > compat44 on > > > >> BASH_COMPAT=44 bash --noprofile -l > > bash: BASH_COMPAT: compat44: compatibility value out of range > > bash-5.2$ shopt compat44 > > compat44 on > > I'm not seeing this behavior. > > outer$ BASH_COMPAT=4.4 PS1='inner\$ ' bash --noprofile -l > inner$ shopt compat44 > compat44 on > inner$ echo "$BASH_VERSION" > 5.2.37(1)-release > > And those error messages don't make any sense. They ought to just > show the bad value: > > $ BASH_COMPAT=3.0 bash -c : > bash: BASH_COMPAT: 3.0: compatibility value out of range > $ BASH_COMPAT=5.3 bash -c : > bash: BASH_COMPAT: 5.3: compatibility value out of range > > Are you sure "bash" wasn't/isn't an alias or function or wrapper > script or something? > I don't use aliases and have every reason to believe "bash" was "/opt/homebrew/bin/bash", although I no longer have that shell instance open so I can't confirm that for the instance I gave above, nor the state/attributes/value of BASH_COMPAT in the parent shell. However I was able to reproduce the issue, unfortunately raising more questions than it answers (yes the first error in the parent shell is expected): $ 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. Apparently the export is normal, although I was unaware of this phenomenon, as the below shows. $ unset FOO $ declare -p FOO bash: declare: FOO: not found $ FOO=BAR /opt/homebrew/bin/bash --noprofile -l bash-5.2$ declare -p FOO declare -x FOO="BAR" bash-5.2$ 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. But I suppose that is besides the point that the child shell is not producing the error of the phantom value from the parent.
