From owner-freebsd-questions@freebsd.org Mon Sep 21 11:21:51 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3CF513EE727 for ; Mon, 21 Sep 2020 11:21:51 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bw28G1bRtz470L for ; Mon, 21 Sep 2020 11:21:49 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([178.12.34.202]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPA (Nemesis) id 1MF3U0-1kDlOO1lAO-00FPnv; Mon, 21 Sep 2020 13:21:40 +0200 Date: Mon, 21 Sep 2020 13:21:39 +0200 From: Polytropon To: David Christensen 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> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:F6Re92E3xgmC+VoJuwzY8sBxIJXBD33KTDbaBD2Yq/bEOD0oH+v GWyuybLzg7oMR1U6ev6dBgS/8R7VOL/pnGPLGuHGZhHQjB7Fq4A6d7AVO1IkDEBFwWRCjzZ hMR3HBx36ddupx3oVrYeCky3+zneao6SnSRkmeRLN3aAC9waZjMO1NJaRKBENROjv805R+m fYl7G4SIRi8j905JnmLkA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:zBJ/V77b37Q=:NU/JscTGn1CwfDic2SSAfq 9DdAhU+37wGoqf32urzcndjg8noNaXjO4PgEXVvSSJJvadtJYYh9QEbvN0qnWNENANEYHZ6ir GQuSTpFLVlYfZa9GA927jO8ZINAq6ks9ngqVPov3qL4n8U6/sgi13bGbGUz4IqQce1h5bq2Rh 8+7CWSyai6ply/N9Ddt9D33vvmilMZElIKhf8ek5oa9IF1abLPsEOCT5AesMtb9c9KXF0Qg+9 9/BOhwg9HHXN5ibMVtI38ZQr4QJZoXJG7wHSlfBeYfQwa/VDCyda5IyAjBhOgGwNW51l2ZI48 kmeFbJJKUFwYY9PmtSkHh4gv1R+BacjQ5pGyoso0RQrHwd5J7IPlJHNpH2ULAbGnuF07RqVYZ sQzgmXL8+W0RKbZjGdlzblC84CQY/fIXtQkq8fZoWznDs+c8R8buUj7O+kvbtlXAJiInv7c4M IkPnmSUZ4bSMccGyWcgwhztDd9hjWemzT9q8yFaU6oO+ByMxhFCxDJLBoqrlAEOXP4idfFlyG xwUSqMNkybMIjGSZAueTIaeq6UXDVuHWgFR2cqHK/U+FNwJBwdZyhzgnyC3gJq3xbX68TNQin tSR0ZJ0vSBa1OfGiIT/vQJLTfvXP/VldS3Hd1yn/2Dag4+P7Uim3W+j0Eg76ByiWWPKYn65ZK 4xa9EngfB9QIedMWBK+oQd6MQbMRyFt8mxNqsG52Dka6G74bwDOSW0ocTypm5OEPSJ/edcu92 /rNtHqACLUXjNmwqW3ui8XPLPBkHZImAQakR6sVKdePHdXDSq1ln+RUMK11ZLLWfLLOMdVKFm 7spTj9y3T5pjDZEVHexTHdAPvViuE6uFmjxL+hzPMF6OCUrEpXU3frW2eIH954ORZ7aCvTp X-Rspamd-Queue-Id: 4Bw28G1bRtz470L X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 212.227.126.130) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [0.87 / 15.00]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.05)[-0.048]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[178.12.34.202:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.53)[-0.535]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.950]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[212.227.126.130:from]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.126.130:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 11:21:51 -0000 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, ...