Date: Mon, 21 Sep 2020 13:21:39 +0200 From: Polytropon <freebsd@edvax.de> To: David Christensen <dpchrist@holgerdanske.com> Cc: freebsd-questions@freebsd.org Subject: Re: Error message output Message-ID: <20200921132139.286b5bda.freebsd@edvax.de> In-Reply-To: <528b2c90-18c4-9e95-a150-67344154c66c@holgerdanske.com> References: <20200920191108.22864e5c.freebsd@edvax.de> <528b2c90-18c4-9e95-a150-67344154c66c@holgerdanske.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 Sep 2020 22:12:24 -0700, David Christensen wrote:
> On 2020-09-20 10:11, Polytropon wrote:
> > I have a general question. Is it still considered useful to
> > output error messages of a script to standard error?
> >
> > Example:
> >
> > if [ something not okay ]; then
> > echo "the error message" > /dev/stderr
> > exit 1
> > fi
> >
> > While progress messages will per default go to standard output,
> > error messages should be printed to standard error. The reason:
> > If a program is silenced to > /dev/null, error messages will
> > still be visible (no "silent failing"); if a user wants to
> > explicitely mute all messages, > /dev/null 2>&1 has to be
> > specified for the redirection. The judgement if a message is
> > a regular progress message, an information about some slightly
> > problematic case, or a real fatal error depends on the programmer.
>
> I have been migrating my programming style towards a data flow paradigm,
> which includes "command-line filters". So, an "ideal" command-line
> program or script would:
>
> * Use stdin for the input data.
>
> * Use stdout for the output data.
>
> * Use configuration files, command-line options and arguments, received
> signals and direct tty reads for out-of-band/ non-data input.
>
> * Use stderr, log files, and the exit value for out-of-band/ non-data
> output.
>
>
> This model doesn't work for all programs, but it is nice when it does.
Correct, that's what I thought, and what I try to follow,
depending on program abilities; for example, if there are
no options the user can select from, then there will be
no command line options or configuration file. The choice
of / if there needs to be options and / or configuration
file(s) depends on what the program does. Same regarding
log files (long term storage of logs or just displaying
them on the terminal).
> A mouse and/or graphical environment adds even more possibilities.
My consideration was exclusively aimed at command line programs,
but of course the increased complexity of GUI programs, no matter
if it is native GUIs or web front-ends, offers more flexibility
and options.
> > For example:
> >
> > echo "${FILE] processed, ${RECS} records counted."
> > -> standard output
>
> If the above message represents the output data of the program, I would
> send it to stdout -- wc(1), for example.
>
>
> Otherwise, I would send it to stderr -- dd(1), for example.
>
>
> In the latter case, the message might be enabled or disabled by a
> configuration file setting and/or command-line option.
Thank you - that is an interesting inspiration and something
to really consider.
> > echo "${DEV} is read only, aborting."
> > exit 1
> > -> standard error (fatal error)
>
> Yes, but don't you need to redirect echo(1) output to stderr?
>
> echo "writing to stderr" >&2
>
>
> In some cases, it could be useful to print a warning to stderr and
> prompt the user to retry; again per configuration settings/ options.
Good catch, I missed to add that in the example.
What about form?
echo "the error message" > /dev/stderr
or
echo "the error message" >&2
WHich one is considered better form, leaving aside the "amount of
symbols needed"?
> > At least that's what I've learned centuries ago.
> >
> > Is that still valid?
>
> As the author of a program, you decide what is valid.
I'm primarily interested in what currently the consensus is
about good form and style, common approach and accepted ways
of doing things. I could keep spamming the system log with
progress messages, but that wouldn't be nice, would it? ;-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200921132139.286b5bda.freebsd>