On Sat, Aug 27, 2022 at 09:52:11AM -0400, Greg Wooledge wrote: > I also can't explain this (still inside the ssh localhost session): > > > unicorn:~$ (bash -c 'declare -p PS1') > declare -- PS1="\\h:\\w\\\$ " > unicorn:~$ (bash -cu 'declare -p PS1') > /etc/bash.bashrc: line 7: PS1: unbound variable > /etc/bash.bashrc: line 1: declare: PS1: not found > > > Why would adding the -u option change whether PS1 gets unset? Not a clue.
It turns out, this is a bit of an illusion. It's not -u causing PS1 to be unset. bash -c unsets PS1 (because it's launching a non-interactive shell) -- but since it's inside an ssh session and has shell_level < 2, it *also* reads the startup files. In the first example above, reading the startup files succeeds, because there is no -u. In the second example above, reading the startup files fails, because of -u. Thus, PS1 remains unset. The part of the startup files that would have set PS1 never gets executed. I believe all of the behaviors have been explained now.
