Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #233921 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  .profile not being src'd at login on uptodate buster Gene Heskett <gheskett@shentel.net> - 2021-04-07 14:20 +0200
    Re: .profile not being src'd at login on uptodate buster IL Ka <kazakevichilya@gmail.com> - 2021-04-07 14:30 +0200
      Re: .profile not being src'd at login on uptodate buster Gene Heskett <gheskett@shentel.net> - 2021-04-07 17:30 +0200
      Re: .profile not being src'd at login on uptodate buster Gene Heskett <gheskett@shentel.net> - 2021-04-07 17:40 +0200
    Re: .profile not being src'd at login on uptodate buster Greg Wooledge <greg@wooledge.org> - 2021-04-07 14:40 +0200
    Re: .profile not being src'd at login on uptodate buster David Wright <deblis@lionunicorn.co.uk> - 2021-04-07 17:10 +0200
    Re: .profile not being src'd at login on uptodate buster Lee <ler762@gmail.com> - 2021-04-07 17:20 +0200
      Re: .profile not being src'd at login on uptodate buster Greg Wooledge <greg@wooledge.org> - 2021-04-07 17:40 +0200
        Re: .profile not being src'd at login on uptodate buster David Wright <deblis@lionunicorn.co.uk> - 2021-04-07 18:40 +0200
          Re: .profile not being src'd at login on uptodate buster Marco Ippolito <maroloccio@gmail.com> - 2021-04-07 23:20 +0200
            Re: .profile not being src'd at login on uptodate buster Lee <ler762@gmail.com> - 2021-04-07 23:50 +0200
              Re: .profile not being src'd at login on uptodate buster Marco Ippolito <maroloccio@gmail.com> - 2021-04-08 14:30 +0200
              Re: .profile not being src'd at login on uptodate buster David Wright <deblis@lionunicorn.co.uk> - 2021-04-10 20:30 +0200
                Re: .profile not being src'd at login on uptodate buster Lee <ler762@gmail.com> - 2021-04-10 21:00 +0200
                  Re: .profile not being src'd at login on uptodate buster Greg Wooledge <greg@wooledge.org> - 2021-04-10 21:30 +0200
                    Re: .profile not being src'd at login on uptodate buster David Wright <deblis@lionunicorn.co.uk> - 2021-04-11 16:20 +0200
                      Re: .profile not being src'd at login on uptodate buster Greg Wooledge <greg@wooledge.org> - 2021-04-11 16:50 +0200
                        Re: .profile not being src'd at login on uptodate buster Lee <ler762@gmail.com> - 2021-04-11 19:10 +0200
                          Re: .profile not being src'd at login on uptodate buster Greg Wooledge <greg@wooledge.org> - 2021-04-11 20:00 +0200
                        Re: .profile not being src'd at login on uptodate buster David Wright <deblis@lionunicorn.co.uk> - 2021-04-12 17:20 +0200
                          Re: .profile not being src'd at login on uptodate buster Greg Wooledge <greg@wooledge.org> - 2021-04-12 17:30 +0200
                            Re: .profile not being src'd at login on uptodate buster David Wright <deblis@lionunicorn.co.uk> - 2021-04-12 18:10 +0200
                  Re: .profile not being src'd at login on uptodate buster David Wright <deblis@lionunicorn.co.uk> - 2021-04-11 16:20 +0200
                    Re: .profile not being src'd at login on uptodate buster Greg Wooledge <greg@wooledge.org> - 2021-04-11 16:50 +0200
                      Re: .profile not being src'd at login on uptodate buster David Wright <deblis@lionunicorn.co.uk> - 2021-04-12 17:20 +0200
        Re: .profile not being src'd at login on uptodate buster Lee <ler762@gmail.com> - 2021-04-07 23:50 +0200
          Re: .profile not being src'd at login on uptodate buster Greg Wooledge <greg@wooledge.org> - 2021-04-08 00:10 +0200
            Re: .profile not being src'd at login on uptodate buster Curt <curty@free.fr> - 2021-04-08 10:20 +0200
              Re: .profile not being src'd at login on uptodate buster Tixy <tixy@yxit.co.uk> - 2021-04-08 12:20 +0200
                Re: .profile not being src'd at login on uptodate buster Greg Wooledge <greg@wooledge.org> - 2021-04-08 13:30 +0200
              Re: .profile not being src'd at login on uptodate buster Greg Wooledge <greg@wooledge.org> - 2021-04-08 13:40 +0200

Page 1 of 2  [1] 2  Next page →

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

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>

[toc] | [next] | [standalone]

#233922

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#233939

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

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

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.

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>

[toc] | [prev] | [next] | [standalone]

#233941

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

> > 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
found it, missing $ sign in .profile.
Thanks, I wasn't aware of the +-v effect till now

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>

[toc] | [prev] | [next] | [standalone]

#233924

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

[toc] | [prev] | [next] | [standalone]

#233936

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.

[toc] | [prev] | [next] | [standalone]

#233937

On 4/7/21, Gene Heskett <gheskett@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

[toc] | [prev] | [next] | [standalone]

#233940

On Wed, Apr 07, 2021 at 03:16:41PM +0000, Lee wrote:
> On 4/7/21, Gene Heskett <gheskett@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.

[toc] | [prev] | [next] | [standalone]

#233945

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.

[toc] | [prev] | [next] | [standalone]

#233962

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

Maybe consider:

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

[toc] | [prev] | [next] | [standalone]

#233963

On 4/7/21, Marco Ippolito <maroloccio@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.

Lee

[toc] | [prev] | [next] | [standalone]

#233987

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

[toc] | [prev] | [next] | [standalone]

#234079

On Wed 07 Apr 2021 at 21:46:30 (+0000), Lee wrote:
> On 4/7/21, Marco Ippolito <maroloccio@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.

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

[toc] | [prev] | [next] | [standalone]

#234080

On 4/10/21, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Wed 07 Apr 2021 at 21:46:30 (+0000), Lee wrote:
>> On 4/7/21, Marco Ippolito <maroloccio@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

[toc] | [prev] | [next] | [standalone]

#234082

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.

[toc] | [prev] | [next] | [standalone]

#234099

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.

[toc] | [prev] | [next] | [standalone]

#234103

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

[toc] | [prev] | [next] | [standalone]

#234114

On 4/11/21, Greg Wooledge <greg@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

[toc] | [prev] | [next] | [standalone]

#234116

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.

[toc] | [prev] | [next] | [standalone]

#234132

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web