Re: .profile not being src'd at login on uptodate buster
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.
Reply to: