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 2 of 2 — ← Prev page 1 [2]

#234133

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

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

#234136

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.

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

#234098

On Sat 10 Apr 2021 at 18:59:21 (+0000), Lee wrote:
> 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.

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.

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

#234104

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.

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

#234131

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.

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

#233964

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

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

#233968

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 .

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

#233978

On 2021-04-07, Greg Wooledge <greg@wooledge.org> wrote:
> 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 .

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

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

#233979

On Thu, 2021-04-08 at 07:50 +0000, Curt wrote:
> On 2021-04-07, Greg Wooledge <greg@wooledge.org> wrote:
> > 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 .
> 
> What about addressing his primary point rather than what in my
> benefit-of-the-doubt humor I construe as a typographical oversight?

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

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

#233981

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.

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

#233985

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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web