[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: .profile not being src'd at login on uptodate buster



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.

> > 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 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.

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.

It has nothing to do with "sourced vs. executed".


Reply to: