Re: .profile not being src'd at login on uptodate buster
On Sun 11 Apr 2021 at 10:41:31 (-0400), Greg Wooledge wrote:
> On Sun, Apr 11, 2021 at 09:11:47AM -0500, David Wright wrote:
> > On Sat 10 Apr 2021 at 15:21:57 (-0400), Greg Wooledge wrote:
> > > I'm not a fan of it, because I actually like to export PS1, rather
> > > than setting it in .bashrc every time. I may be in the minority there.
> >
> > Exported from .[bash_]profile? I don't do that because the terminal
> > type might be different (login on VC, but prompt in an xterm).
>
> >From .profile, typically. Although I'm actually not doing it right now.
>
> The terminal type is irrelevant. I don't put terminal escape sequences
> in my PS1. I suppose that if you *do*, that would weigh extremely
> heavily on the .bashrc approach.
I do use them, but I may have misremembered about terminal type being
the cause. Like you, I don't revisit this stuff very often.
> > > Testing whether stdout is a terminal is a more reliable test than seeing
> > > whether PS1 happens to be set.
> >
> > But you do actually lose the distinction between sourcing the file
> > and executing it. Only the former has PS1 set, whereas both have
> > stdout to a terminal.
>
> PS1 *could* be set by anything. It's just a variable. Counting on it
> *not* being set is an unreliable test. That's all I was saying.
I write my startup files, just like you, so I'm not sure what you mean
by "anything". Bash has quite a few variables where one would be
unwise to set them oneself as they would lose their special meaning,
but PS1 is not one of them. Many people modify their PS1, and it's one
thing you're likely to notice if it gets changed, as it's always
staring you in the face.
> I thought we were talking about "protecting" a section of a dot file so
> that the noisy commands (fortune, cal, date, etc.) would only execute
> when you're actually logging in, or actually launching a terminal,
> and not when you're running scp, or other scripted stuff.
>
> In those cases, it's not "was it sourced or not" that matters, because
> dot files are essentially always "sourced". What matters is whether
> the output of your protected section is going to be seen by a human
> (safe), or get injected into some parsed data stream (unsafe). So the
> correct test is whether stdout is a terminal. If stdout is a terminal,
> then it's safe to run the noisy commands.
>
> Checking whether PS1 is set is not the correct way.
I'm not using PS1 to test whether stdout is a terminal, but whether
the file is running interactively. From man bash:
"PS1 is set and $- includes i if bash is interactive, allowing a
shell script or a startup file to test this state.
> In addition to this, your statement was factually incorrect. Bash sets
> the PS1 variable automatically under these conditions:
>
> An interactive shell is one started without non-option arguments (un‐
> less -s is specified) and without the -c option whose standard input
> and error are both connected to terminals (as determined by isatty(3)),
> or one started with the -i option. PS1 is set and $- includes i if
> bash is interactive, allowing a shell script or a startup file to test
> this state.
Glad you agree.
> It has nothing to do with "sourced vs. executed".
All I was pointing out is that testing PS1 gives different results
when sourced or executed, whereas -t doesn't.
I use PS1 in this documented manner when my startup scripts are
sourced interactively (I'm present) and when I source them myself
by typing . whatever into a terminal. I'm interactively present
to read them. That's different from the system determining whether
the output is going to a terminal. If the latter is all that concerns
you, by all means use [[ -t 1 ]] instead. I haven't said a word
against it—any criticism didn't come from me.
$ cat some-nonexecutable-file
#!/bin/bash
[ -n "$PS1" ] && printf '%s\n' "Testing -n PS1 gives true"
[[ -t 1 ]] && printf '%s\n' "Testing -t 1 gives true"
#
$ cmp some-nonexecutable-file some-executable-file
$ . ./some-nonexecutable-file
Testing -n PS1 gives true
Testing -t 1 gives true
$ bash some-nonexecutable-file
Testing -t 1 gives true
$ . ./some-executable-file
Testing -n PS1 gives true
Testing -t 1 gives true
$ bash ./some-executable-file
Testing -t 1 gives true
$ ./some-executable-file
Testing -t 1 gives true
$
Cheers,
David.
Reply to: