On Sat 10 Apr 2021 at 18:59:21 (+0000), Lee wrote: > On 4/10/21, David Wright <[email protected]> wrote: > > On Wed 07 Apr 2021 at 21:46:30 (+0000), Lee wrote: > >> On 4/7/21, Marco Ippolito <[email protected]> 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.
