Hello,

When invoked as "sh -l" bash, for compatibility reasons old sh implementations, always read /etc/profile. Startup files are read with bashism allowed, and then fall back into posix mode.

When invoked as "bash --posix -l", bash follows posix spec more closely and only load startup file in $ENV and load them in posix mode enabled (no bashism mode).

The test $POSIXLY_CORRECT is here to prevent loading bash.bashrc, which is expected to be a file with bashism. I don't think removing it is a good idea. For example, "ENV=/etc/profile bash --posix", would read this file and bashism will fail. But, it doesn't fix  FS#46450  for the reason you pointed.

I guess bash dev introduced this subtle difference, of reading startup files in posix mode disabled when invoked as sh, for a reason. Maybe they want us to be able to parse our bash files at some point.

Loading in /etc/profile of /etc/bash.bashrc is a hacky way to get interactive login shells loads non-login shell startup files. bash invoked as a non login shell "sh" doesn't read /etc/bash.bashrc, so it makes sense to not load this file when started as a login shell.

I think we could _not_ rely on $BASH content, to know if we were invoked as sh. There is no guaranty that the bash binary even contains the bash string. We test this vars to assume we are running into bash.
Instead, I suggest instead to use $0, like in the following:

-# Source global bash config
-if test "$PS1" && test "$BASH" && test -z ${POSIXLY_CORRECT+x} && test -r /etc/bash.bashrc; then
+# Source global bash config, when interactive but not posix or sh mode
+if test "$BASH" -a "$PS1" -a -z "$POSIXLY_CORRECT" -a "${0#-}" != sh -a -r /etc/bash.bashrc; then
. /etc/bash.bashrc
fi

I'm testing it locally.

filesystem 2020.05-1 will land in testing soon.

Thank you for explaining these subtleties, the rationale makes sense and the fix you suggested seems manage all these cases properly.

Note that I think we should still use ${POSIXLY_CORRECT+x} for the reasons pointed out in  FS#46450 .
Also the use of -a is inherently ambiguous and less readable IMHO.

Well, ${POSIXLY_CORRECT+x} without quoting doesn't works with dash. That's why I changed.

$ bash --posix -x -c 'test "$BASH" -a "$PS1" -a -z ${POSIXLY_CORRECT+x} -a "${0#-}" != sh -a -r /etc/bash.bashrc'
+ test /usr/bin/bash -a '' -a -z x -a bash '!=' sh -a -r /etc/bash.bashrc
$ zsh --emulate sh -x -c 'test "$BASH" -a "$PS1" -a -z ${POSIXLY_CORRECT+x} -a "${0#-}" != sh -a -r /etc/bash.bashrc'
+ test '' -a '' -a -z -a zsh '!=' sh -a -r /etc/bash.bashr
$ dash -x -c 'test "$BASH" -a "$PS1" -a -z ${POSIXLY_CORRECT+x} -a "${0#-}" != sh -a -r /etc/bash.bashrc'
+ test -a $ -a -z -a dash != sh -a -r /etc/bash.bashrc
dash: 1: test: -a: unexpected operator

Ok, couldn't we just quote it then? IIUC it would not break the behavior.

test ... -a ...

is a deprecated, ill-advised construct. POSIX defines the "-a" and "-o" binary primaries as "many implementations will continue to support these obsolescent forms", while noting that they are error prone.

As obsolescent features, a future version of POSIX may remove them entirely, and strictly conforming POSIX applications MUST NOT use them.

As Stéphane pointed out, you don't even get enhanced readability as a consolation prize for using them. Quite the reverse.

There is zero downside to using multiple invocations of the test utility chained together with shell syntax '&&'. Please switch back, and for safety, forget that these obsolescent features exist.

Thanks for pointing the POSIX standard extra information about this syntax. It completely went out of my mind.

For rationale of the initial switch, the "-a" form is shorter, without the useless repetition of the test word, which IMHO improve readability. But, Indeed, the problem of parsing makes them undesirable.