Error message output
freebsd at edvax.de
Mon Sep 21 22:56:06 UTC 2020
On Mon, 21 Sep 2020 15:33:40 -0700, David Christensen wrote:
> On 2020-09-21 04:21, Polytropon wrote:
> > 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?
> > 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"?
> "It depends". The former is dependent upon the system having a
> /dev/stderr. The latter is dependent upon the shell having redirection
> (which all Bourne-compatible shells should?). Both seem to work on
> FreeBSD, Debian, macOS, and Cygwin (Windows 7). But, that is likely to
> be untrue on every system. And, is it possible to have a situation
> where you have already redirect stderr and yet the script needs to emit
> an error message? Without a compelling reason either way, I have tended
> to use the latter; but the former is starting to look more idiot-proof.
So sadly there no way of saying "one is to be preferred over
the other". Sure, I agree that portability can be an issue
even among UNIXes and UNIX-likes (like Linux), and I don't
want to go that far and guess how sh script execution is
becoming more and more possible under other systems and
their layers or subsystems to make them able to do what
everyone else can do for decades already. Coming from a
heterogenous OS background, and especially one involving
UNIXes from different ages, you would assume that "sh is sh",
but it's not, and even if you think something is POSIX-
compliant, it turns out it's not, at least not entirely,
and that leads to all kinds of "careful coding". :-)
The problem "script called from within script" adds an
additional level of "didn't expect", such as
./something.sh > /dev/null 2>&1
where something.sh outputs stuff to stdout (like list of
files processed) and stderr (specified files not found).
In such cases, a log file which is handled independently
from any redirection will surely be a better solution.
Oh, and "idiot-proof" is always good, especially for idiot
programmers like me. :-)
> > 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? ;-)
> My ideal would be to put "less important" messages into a
> program-specific log(s) and to put "important" messages into both
> program-specific logs and the system log. Again, under configuration/
> option control.
I'm primarily thinking about dead-simple idiot programs
which are used interactively in order to perform some
tasks, often involving dealing with files.
Example (from a real script); the following normal usage
prints to standard output:
% png2pdf.sh mdcc_rg_2020-04-01
The typical error cases (input not found, no input specified)
output to standard error, and there is a non-zero exit code:
% png2pdf.sh nothing
Error: no matching source files for pattern nothing_*.png found, aborting.
Convert PNG image files and create PDF
Usage: /opt/bin/png2pdf.sh <pattern>
The source file pattern must lead to files named <pattern>_*.png.
The target file's name will be <pattern>.pdf.
Is that an acceptable solution?
> Truly sophisticated programs use a logging management layer. For
> example, in Perl:
No. Truly sophisticated programs use a web service with a dynamic
no-SQL database and API and ML and AI provided by a startup with
a name you cannot properly pronounce which will disappear in two
years after you signed a 10 years contract and made your whoole
business depend on it. ;-)
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions