Re: Weird set -u error
On Sun, 28 Aug 2022 at 00:17, Greg Wooledge <greg@wooledge.org> wrote:
> 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.
Thanks for sharing your explanation, that's quite an impressive
investigation. My C skills are pretty minimal so I would have no hope to to
figure any of that out. Although I can follow the syntax at the statement
level and have occasionally written or patched some useful C code myself,
I struggle to comprehend other people's real-world C at any higher level.
I think there might be one remaining aspect still mysterious, so there
might be yet another factor beyond the FIVE you identified ...
The fact that this statement, first shown by Tim, does NOT error:
$ ( bash -uc : ; : )
[david@kablamm ~]$ ssh kablamm
Linux kablamm 5.10.0-16-amd64 #1 SMP Debian 5.10.127-2 (2022-07-23) x86_64
Last login: Sat Aug 27 17:02:53 2022 from 10.1.1.2
[david@kablamm ~]$ ( bash -cu : )
/etc/bash.bashrc: line 7: PS1: unbound variable
[david@kablamm ~]$ ( bash -cu : ; : )
[david@kablamm ~]$
Reply to: