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