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

[Gene Heskett]

Greetings all;

I just installed buster on a Dell 7010 and I have added two stanza's to
my .profile, to find a logout and back in does not establish a new
$PATH.

The first of them will be added but not the other if I
. .profile

The additions to .profile are:
=====
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi

# set PATH so it includes user's private AppImages if it exists
if [ -d "$HOME/AppImages" ] ; then
PATH="$HOME/AppImages:$PATH"
fi
=====
Both directories do exist.

Any idea why its not working?

Thanks all.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[IL Ka]

The first of them will be added but not the other if I
. .profile

Try to debug it. First of all, run this from the command line:

[  -d "$HOME/AppImages" ] ; echo $?

result should be "0". If not, then there must be some problem with this directory (check name, case, etc).

Then try 

set -v

. .profile

and check output carefully

[Greg Wooledge]

On Wed, Apr 07, 2021 at 08:16:43AM -0400, Gene Heskett wrote:
> I just installed buster on a Dell 7010 and I have added two stanza's to
> my .profile, to find a logout and back in does not establish a new
> $PATH.

> Any idea why its not working?

How do you log in? Probably with a GUI, yes?

https://wiki.debian.org/Xsession

[David Wright]

On Wed 07 Apr 2021 at 08:16:43 (-0400), Gene Heskett wrote:
>
> I just installed buster on a Dell 7010 and I have added two stanza's to
> my .profile, to find a logout and back in does not establish a new
> $PATH.
>
> The first of them will be added but not the other if I
> . .profile
>
> The additions to .profile are:
> =====
> # set PATH so it includes user's private bin if it exists
> if [ -d "$HOME/bin" ] ; then
> PATH="$HOME/bin:$PATH"
> fi
>
> # set PATH so it includes user's private AppImages if it exists
> if [ -d "$HOME/AppImages" ] ; then
> PATH="$HOME/AppImages:$PATH"
> fi
> =====
> Both directories do exist.

Sure?

> Any idea why its not working?

Singular, or plural?

https://lists.debian.org/debian-user/2020/08/msg00183.html

Cheers,
David.

[Lee]

On 4/7/21, Gene Heskett <ghes...@shentel.net> wrote:
> Greetings all;
>
> I just installed buster on a Dell 7010 and I have added two stanza's to
> my .profile, to find a logout and back in does not establish a new
> $PATH.

Probably because you've got a window manager that does the login stuph for you..

> The first of them will be added but not the other if I
> . .profile
>
> The additions to .profile are:
> =====
> # set PATH so it includes user's private bin if it exists
> if [ -d "$HOME/bin" ] ; then
> PATH="$HOME/bin:$PATH"
> fi
>
> # set PATH so it includes user's private AppImages if it exists
> if [ -d "$HOME/AppImages" ] ; then
> PATH="$HOME/AppImages:$PATH"
> fi
> =====
> Both directories do exist.
>
> Any idea why its not working?

A typo in your script? Add an else clause that shows the error and
that will probably show you what's wrong -- eg

dir="$HOME/AppImages"
if [ -d "$dir" ] ; then
PATH="$dir:$PATH"
else
echo "OnNoes!! The directory \"$dir\" does not exist!"
fi

note that $HOME/AppImages is listed only once. That makes sure that
your test, path and diagnostic output are all using the same directory
name.

Regards,
Lee

[Gene Heskett]

And it worked. Why? Set +v turns off the echo and it still works.
Go figure. Thanks Oh wait, go try it on the machine its not woking on.

[Gene Heskett]

On Wednesday 07 April 2021 08:28:49 IL Ka wrote:

found it, missing $ sign in .profile.
Thanks, I wasn't aware of the +-v effect till now

[Greg Wooledge]

On Wed, Apr 07, 2021 at 03:16:41PM +0000, Lee wrote:
> On 4/7/21, Gene Heskett <ghes...@shentel.net> wrote:
> > Greetings all;
> >
> > I just installed buster on a Dell 7010 and I have added two stanza's to
> > my .profile, to find a logout and back in does not establish a new
> > $PATH.
>
> Probably because you've got a window manager that does the login stuph for you..

Display Manager.

> > The first of them will be added but not the other if I
> > . .profile

> > # set PATH so it includes user's private AppImages if it exists
> > if [ -d "$HOME/AppImages" ] ; then
> > PATH="$HOME/AppImages:$PATH"
> > fi
> > =====
> > Both directories do exist.

Prove it, by running ls -ld $HOME/AppImages in a terminal, and then
pasting the shell prompt, the command, and its output from the terminal
session into the body of the email. For example,

unicorn:~$ ls -ld $HOME/AppImages
ls: cannot access '/home/greg/AppImages': No such file or directory

> > Any idea why its not working?
>
> A typo in your script? Add an else clause that shows the error and
> that will probably show you what's wrong -- eg
>
> dir="$HOME/AppImages"
> if [ -d "$dir" ] ; then
> PATH="$dir:$PATH"
> else
> echo "OnNoes!! The directory \"$dir\" does not exist!"
> fi

Writing error messages to stdout from a .profile isn't generally the
best idea. Writing to stderr would be slightly better, but both of
them should be avoided in a permanent configuration if possible. Profiles
that scribble to stdout or stderr during login can break things like scp.

As a *temporary* debugging measure, it's fine.

> note that $HOME/AppImages is listed only once. That makes sure that
> your test, path and diagnostic output are all using the same directory
> name.

That's good advice in general, yeah.

[David Wright]

On Wed 07 Apr 2021 at 11:33:02 (-0400), Greg Wooledge wrote:
> On Wed, Apr 07, 2021 at 03:16:41PM +0000, Lee wrote:
> > A typo in your script? Add an else clause that shows the error and
> > that will probably show you what's wrong -- eg
> >
> > dir="$HOME/AppImages"
> > if [ -d "$dir" ] ; then
> > PATH="$dir:$PATH"
> > else
> > echo "OnNoes!! The directory \"$dir\" does not exist!"
> > fi
>
> Writing error messages to stdout from a .profile isn't generally the
> best idea. Writing to stderr would be slightly better, but both of
> them should be avoided in a permanent configuration if possible. Profiles
> that scribble to stdout or stderr during login can break things like scp.
>
> As a *temporary* debugging measure, it's fine.

Where I want output, I protect it with:

[ -n "$PS1" ] && printf …

> > note that $HOME/AppImages is listed only once. That makes sure that
> > your test, path and diagnostic output are all using the same directory
> > name.
>
> That's good advice in general, yeah.

As so often, we're reduced to guessing, because we're not shown
the *actual* text of the problem, but just some paraphrase.

Cheers,
David.

[Marco Ippolito]

> Where I want output, I protect it with:
>
> [ -n "$PS1" ] && printf …

Maybe consider:

[[ -t 1 ]] && printf ...

[Lee]

On 4/7/21, Greg Wooledge <gr...@wooledge.org> wrote:
> On Wed, Apr 07, 2021 at 03:16:41PM +0000, Lee wrote:
>> On 4/7/21, Gene Heskett <ghes...@shentel.net> wrote:

<.. snip ..>

>> > Any idea why its not working?
>>
>> A typo in your script? Add an else clause that shows the error and
>> that will probably show you what's wrong -- eg
>>
>> dir="$HOME/AppImages"
>> if [ -d "$dir" ] ; then
>> PATH="$dir:$PATH"
>> else
>> echo "OnNoes!! The directory \"$dir\" does not exist!"
>> fi
>
> Writing error messages to stdout from a .profile isn't generally the
> best idea. Writing to stderr would be slightly better, but both of
> them should be avoided in a permanent configuration if possible. Profiles
> that scribble to stdout or stderr during login can break things like scp.

Interesting.. "echo foo" in .bashrc does break scp, but not "echo foo >2"
.. but that doesn't work for bash, so hhrmm.. > /dev/stderr seems to
work in all cases:

$ head -12 .bashrc
lee@izzy:~$ head -12 ~/.bashrc
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

if [ -n "$DEBUG" ]; then
# don't bother with the rest if I've been here before
echo "bashrc: DEBUG already set: $DEBUG" >/dev/stderr
return
else
echo ".bashrc: First time here!" >/dev/stderr
fi

> As a *temporary* debugging measure, it's fine.

I don't see any breakage, so I'd disagree with you. Especially here,
where the test is a belt & suspenders thing because the directory is
always supposed to exist.

Regards,
Lee

[Lee]

Until your script that was started via crontab silently fails. I
*like* always having error messages enabled.

Lee

[Greg Wooledge]

On Wed, Apr 07, 2021 at 09:41:51PM +0000, Lee wrote:
> Interesting.. "echo foo" in .bashrc does break scp, but not "echo foo >2"

That redirects to a file named "2".

> .. but that doesn't work for bash, so hhrmm.. > /dev/stderr seems to
> work in all cases:

You wanted >&2 .

[Curt]

What about addressing his primary point rather than what in my
benefit-of-the-doubt humor I construe as a typographical oversight?

[Tixy]

Given Lee's statement it seems likely to me that he indeed tried the
incorrect redirection ">2" and it would be worthwhile pointing this
out, certainly not warrant criticism.

I believe ">/dev/stderr" is not Posix standard and knowing the correct
standard way of doing this could be beneficial.

--
Tixy

[Greg Wooledge]

On Thu, Apr 08, 2021 at 11:14:48AM +0100, Tixy wrote:
> I believe ">/dev/stderr" is not Posix standard and knowing the correct
> standard way of doing this could be beneficial.

That's correct -- it's not portable.

On systems where /dev/stderr actually exists (such as Debian GNU/Linux),
according to the man page, bash will actually open /dev/stderr and the
semantics will be those of whatever the underlying operating system
implements.

Testing for confirmation:

unicorn:~$ strace -eopen,openat bash -c 'echo hi >/dev/stderr' 2>&1 | tail -3
openat(AT_FDCWD, "/dev/stderr", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
hi
+++ exited with 0 +++

A redirection to /dev/stderr on systems where a real /dev/stderr does NOT
exist is handled internally by bash, and is treated similarly to >&2.
(I actually wish bash would do this on ALL systems for consistency,
but alas.)

Any other use of /dev/stderr (not a redirection) relies on the operating
system's actual /dev/stderr node, which may not exist on commercial Unix
systems, and whose semantics are different across different systems
where it does exist.

Why is that an issue? On some systems, /dev/stderr is a symlink to
something like /dev/fd/2 which means you get the file descriptor
duplication semantics that you want. On other systems, it's a symlink
directly to some device node, and opening it gives you a second,
independent file descriptor pointing to that device. Writes to the
two file descriptors are therefore NOT synchronized, the way they
would be if you had used >&2.

And of course, if the shell reading the script is NOT bash, then you
would have to consult the documentation for whichever shell it is.
In many cases, you'll be relying on the operating system's /dev/stderr
node.

tl;dr: Just use >&2.

[Greg Wooledge]

On Thu, Apr 08, 2021 at 07:50:23AM +0000, Curt wrote:
> What about addressing his primary point rather than what in my
> benefit-of-the-doubt humor I construe as a typographical oversight?

I don't remember what the "primary point" was. Was it the same as
the Subject: header -- .profile not being read at login? Yeah, we
know about that. We've already addressed that.

.profile is only read at login time if you login to a shell -- e.g.
using ssh or a text console login. (And of course, only if your
login shell actually reads .profile. Shells like tcsh which read
different files obviously won't read it -- and they wouldn't be
able to handle it anyway, because they use different syntax.)

It is not read if you login to an X session using a graphical Display
Manager.

It MAY be read if you login to a Wayland session using a graphical
Display Manager. I don't have Wayland stuff installed to test.

[Marco Ippolito]

> >> Where I want output, I protect it with:
> >>
> >> [ -n "$PS1" ] && printf …
> >
> > Maybe consider:
> >
> > [[ -t 1 ]] && printf ...
>
> Until your script that was started via crontab silently fails. I
> *like* always having error messages enabled.

I like logs too but -t was in the spirit of -n $PS1, only slightly more robust,
I think.

[David Wright]

Here's the context, from Greg, again:

> Writing error messages to stdout from a .profile isn't generally the
> best idea. Writing to stderr would be slightly better, but both of
> them should be avoided in a permanent configuration if possible. Profiles
> that scribble to stdout or stderr during login can break things like scp.

Agreed, you certainly don't want that to happen when they're doing
their job non-interactively, because it could have major consequential
effects.

> As a *temporary* debugging measure, it's fine.

My start-up files, .bash_profile, .bashrc, and other files that
they source, contain permanent printf commands. When they finish
printing their output, the next thing that's going to happen is
that the shell will emit a prompt. So there's a certain elegance
in using that very prompt as the condition.

The thread, and my comment, was about the topic under discussion,
startup files, not scripts in general. Using PS1 as a condition
in the latter is unlikely to make much sense at all.

Cheers,
David.

[Lee]

On 4/10/21, David Wright <deb...@lionunicorn.co.uk> wrote:
> On Wed 07 Apr 2021 at 21:46:30 (+0000), Lee wrote:
>> On 4/7/21, Marco Ippolito <marol...@gmail.com> wrote:
>> >> Where I want output, I protect it with:
>> >>
>> >> [ -n "$PS1" ] && printf …
>> >
>> > Maybe consider:
>> >
>> > [[ -t 1 ]] && printf ...
>>
>> Until your script that was started via crontab silently fails. I
>> *like* always having error messages enabled.
>
> Here's the context, from Greg, again:
>
>> Writing error messages to stdout from a .profile isn't generally the
>> best idea. Writing to stderr would be slightly better, but both of
>> them should be avoided in a permanent configuration if possible.
>> Profiles
>> that scribble to stdout or stderr during login can break things like scp.
>
> Agreed, you certainly don't want that to happen when they're doing
> their job non-interactively, because it could have major consequential
> effects.

Can you give an example of profiles that scribble to stderr during
login breaking things like scp? I've tried to create that situation,
but can't.

>> As a *temporary* debugging measure, it's fine.
>
> My start-up files, .bash_profile, .bashrc, and other files that
> they source, contain permanent printf commands. When they finish
> printing their output, the next thing that's going to happen is
> that the shell will emit a prompt. So there's a certain elegance
> in using that very prompt as the condition.
>
> The thread, and my comment, was about the topic under discussion,
> startup files, not scripts in general.

The thread was started by Gene Heskett, so in my mind anything that
makes scripts more bullet-proof/easier to troubleshoot was relevant.
Especially the bit about there's no such thing as a temporary
debugging measure.. If nothing else, if you needed debugging output
once you'll probably need it again years from now when you move to a
new machine.

Regards,
Lee

[Greg Wooledge]

On Sat, Apr 10, 2021 at 01:21:21PM -0500, David Wright wrote:
> My start-up files, .bash_profile, .bashrc, and other files that
> they source, contain permanent printf commands. When they finish
> printing their output, the next thing that's going to happen is
> that the shell will emit a prompt. So there's a certain elegance
> in using that very prompt as the condition.
>
> The thread, and my comment, was about the topic under discussion,

> startup files, not scripts in general. Using PS1 as a condition
> in the latter is unlikely to make much sense at all.

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.

Testing whether stdout is a terminal is a more reliable test than seeing
whether PS1 happens to be set.

On Sat, Apr 10, 2021 at 06:59:21PM +0000, Lee wrote:
> Can you give an example of profiles that scribble to stderr during
> login breaking things like scp? I've tried to create that situation,
> but can't.

Maybe you're right. I haven't touched that stuff in many years, so I
might be repeating outdated advice, or I might have been making incorrect
assumptions all along.

[David Wright]

On Sat 10 Apr 2021 at 15:21:57 (-0400), Greg Wooledge wrote:
> On Sat, Apr 10, 2021 at 01:21:21PM -0500, David Wright wrote:
> > My start-up files, .bash_profile, .bashrc, and other files that
> > they source, contain permanent printf commands. When they finish
> > printing their output, the next thing that's going to happen is
> > that the shell will emit a prompt. So there's a certain elegance
> > in using that very prompt as the condition.
> >
> > The thread, and my comment, was about the topic under discussion,
> > startup files, not scripts in general. Using PS1 as a condition
> > in the latter is unlikely to make much sense at all.
>
> 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).

Exported from .bashrc? I'm not sure of the benefits.

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

Cheers,
David.

[David Wright]

On Sat 10 Apr 2021 at 18:59:21 (+0000), Lee wrote:
> On 4/10/21, David Wright <deb...@lionunicorn.co.uk> wrote:
> > On Wed 07 Apr 2021 at 21:46:30 (+0000), Lee wrote:
> >> On 4/7/21, Marco Ippolito <marol...@gmail.com> wrote:
> >> >> Where I want output, I protect it with:
> >> >>
> >> >> [ -n "$PS1" ] && printf …
> >> >
> >> > Maybe consider:
> >> >
> >> > [[ -t 1 ]] && printf ...
> >>
> >> Until your script that was started via crontab silently fails. I
> >> *like* always having error messages enabled.
> >
> > Here's the context, from Greg, again:
> >
> >> Writing error messages to stdout from a .profile isn't generally the
> >> best idea. Writing to stderr would be slightly better, but both of
> >> them should be avoided in a permanent configuration if possible.
> >> Profiles
> >> that scribble to stdout or stderr during login can break things like scp.
> >
> > Agreed, you certainly don't want that to happen when they're doing
> > their job non-interactively, because it could have major consequential
> > effects.
>
> Can you give an example of profiles that scribble to stderr during
> login breaking things like scp? I've tried to create that situation,
> but can't.

When you run scp, you don't login, so the profile under consideration
is .bashrc rather than .profile or .bash_profile (just in case you
only edited one of the latter).

For stderr, the problem is that the person running scp receives the
profile output from the other end, and they won't know what to make
of it. It precedes any output the sender does expect, and could
interfere with their parsing the response from scp in their script.

For stdout, the problem is more serious. Every time you press TAB
expecting remote filename completion, you receive the profile output
from the other end, double-escaped (so a forest of backslashes). It's
displayed such that it appears to be the first (set of) completed
filename(s). When the scp command completes successfully, an error
code is returned.

> >> As a *temporary* debugging measure, it's fine.
> >
> > My start-up files, .bash_profile, .bashrc, and other files that
> > they source, contain permanent printf commands. When they finish
> > printing their output, the next thing that's going to happen is
> > that the shell will emit a prompt. So there's a certain elegance
> > in using that very prompt as the condition.
> >
> > The thread, and my comment, was about the topic under discussion,
> > startup files, not scripts in general.
>
> The thread was started by Gene Heskett, so in my mind anything that
> makes scripts more bullet-proof/easier to troubleshoot was relevant.
> Especially the bit about there's no such thing as a temporary
> debugging measure.. If nothing else, if you needed debugging output
> once you'll probably need it again years from now when you move to a
> new machine.

That's fine. I was just making it clear that I only use my avoidance
technique in start-up files rather than more generally. I agree about
wanting to see/know about errors occurring. Naturally, when I make
changes in the start-up files, I can test them just by running them
with PS1 set, ie by typing . <filename> interactively in an xterm.

Cheers,
David.

[Greg Wooledge]

On Sun, Apr 11, 2021 at 09:10:24AM -0500, David Wright wrote:
> For stdout, the problem is more serious. Every time you press TAB
> expecting remote filename completion, you receive the profile output
> from the other end, double-escaped (so a forest of backslashes).

...? What the *hell* are you even doing?

Is this some sort of bash-completion nonsense? It's gotta be.

So, yeah, if you're actually using bash-completion (*shudder*) and if
your bash-completion is set up to issue ssh commands to retrieve the
names of remote files while you type, then having unprotected noisy
commands in your dot files is an *extremely* bad idea.

[Greg Wooledge]

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

[Lee]

On 4/11/21, Greg Wooledge <gr...@wooledge.org> 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.

<aside>
really?!! What do you have in PS1?
</aside>

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

That was probably me, forgetting how to redirect to stderr (fd 2?) and
sidetracking the conversation into "echo foo" is a Really Bad Thing in
a dot file and How To Do It Right.

What I'm more interested in is how to prevent this kind of exchange:

> > # set PATH so it includes user's private AppImages if it exists
> > if [ -d "$HOME/AppImages" ] ; then
> > PATH="$HOME/AppImages:$PATH"
> > fi
> > =====
> > Both directories do exist.
>
> Prove it, by running ls -ld $HOME/AppImages in a terminal, and then
> pasting the shell prompt, the command, and its output from the terminal
> session into the body of the email.

IMO, the if test needs an else and the directory name shouldn't be
typed out multiple times -- it belongs in an e-var:

dir="$HOME/AppImages"
if [ -d "$dir" ] ; then
PATH="$dir:$PATH"
else

echo "OnNoes!! The directory \"$dir\" does not exist!" >&2
fi

Regards,
Lee

[Greg Wooledge]

On Sun, Apr 11, 2021 at 05:00:23PM +0000, Lee wrote:
> <aside>
> really?!! What do you have in PS1?
> </aside>

PS1='\h:\w\$ '

> IMO, the if test needs an else and the directory name shouldn't be
> typed out multiple times -- it belongs in an e-var:
>
> dir="$HOME/AppImages"
> if [ -d "$dir" ] ; then
> PATH="$dir:$PATH"
> else
> echo "OnNoes!! The directory \"$dir\" does not exist!" >&2
> fi

That's fine, but it's not an "e-var" (environment variable). It's just
a regular variable.

[David Wright]

On Sun 11 Apr 2021 at 10:45:22 (-0400), Greg Wooledge wrote:
> On Sun, Apr 11, 2021 at 09:10:24AM -0500, David Wright wrote:
> > For stdout, the problem is more serious. Every time you press TAB
> > expecting remote filename completion, you receive the profile output
> > from the other end, double-escaped (so a forest of backslashes).
>
> ...? What the *hell* are you even doing?

Steady on—you're the one who wrote "Profiles that scribble to stdout

or stderr during login can break things like scp."

I agreed with you, but Lee asked "Can you give an example of profiles

that scribble to stderr during login breaking things like scp?
I've tried to create that situation, but can't."

You replied "Maybe you're right. I haven't touched that stuff in many

years, so I might be repeating outdated advice, or I might have been
making incorrect assumptions all along."

So I temporarily modified my .bashrc to output, in turn, on stderr
and stdout, just as a demonstration of what could happen, for Lee.
That's what we do here.

> Is this some sort of bash-completion nonsense? It's gotta be.
>
> So, yeah, if you're actually using bash-completion (*shudder*)

Isn't that something of a value judgment?

I think we can agree that we all use bash completion, even if
we don't use bash-completion itself. We interrogate and complete
filenames by pressing TAB, yes?

> and if
> your bash-completion is set up to issue ssh commands to retrieve the
> names of remote files while you type,

It's not "my bash-completion", but just the regular Debian package.
I use it exactly how it comes out of the tin. (Obviously one needs
to be using ssh keys rather than passwords, if anybody is thinking
of trying this out.)

Without bash-completion, when you type, say,

$ scp -p foo someuser@somehost:bar

and press TAB, what happens? The partial string "bar" gets matched
against filenames that bash sees on the *local* machine. Where's
the much-vaunted Network Transparency in that? I want to complete
filenames and directories with those that exist on the remote host.

Similarly, without bash-completion, you can type:

$ scp -p someuser@somehost:bar

but TAB won't be able to help you find a file you haven't got, but
only to match ones you already have.

Normal completion by bash doesn't give you that network transparency,
bash-completion does.

> then having unprotected noisy
> commands in your dot files is an *extremely* bad idea.

Correct, QED.

Cheers,
David.

[David Wright]

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.

[Greg Wooledge]

On Mon, Apr 12, 2021 at 10:18:19AM -0500, David Wright wrote:
> 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.

The second half of that sentence is referring to the $- part. That's
what you're supposed to test to see whether the shell is interactive.

# bash
if [[ $- = *i* ]]; then
echo "I am an interactive shell"
echo

# sh
case $- in
*i*) echo "I am an interactive shell" ;;
esac

[David Wright]

On Mon 12 Apr 2021 at 11:26:49 (-0400), Greg Wooledge wrote:
> On Mon, Apr 12, 2021 at 10:18:19AM -0500, David Wright wrote:
> > 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.
>
> The second half of that sentence is referring to the $- part. That's
> what you're supposed to test to see whether the shell is interactive.
>
> # bash
> if [[ $- = *i* ]]; then
> echo "I am an interactive shell"

> fi

>
> # sh
> case $- in
> *i*) echo "I am an interactive shell" ;;
> esac

Thanks for going to the trouble of typing that for us
(which you obviously did, as there was a typo).
I've made the change here, and it will propagate to my
other machines. I see the logic of using a ro option.

Cheers,
David.

[David Wright]

On Mon 12 Apr 2021 at 11:26:49 (-0400), Greg Wooledge wrote:

I happened to come across one place where I might have originally
found the construction I no longer use, and that's in man lesspipe,
very near the end, where it says:

if [ -z "$PS1" ]; then

Cheers,
David.

[Greg Wooledge]

Well, that's not a reliable test. You could have PS1 set via the
environment in a non-interactive shell. The number of people who export
PS1 from their profiles or bashrc files is non-negligible.