From owner-freebsd-questions@freebsd.org Tue Sep 22 16:53:22 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 6DC293EF9B2 for ; Tue, 22 Sep 2020 16:53:22 +0000 (UTC) (envelope-from kh@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwnSK6D6Vz4Jk5 for ; Tue, 22 Sep 2020 16:53:21 +0000 (UTC) (envelope-from kh@panix.com) Received: from rain.home (pool-173-48-64-3.bstnma.fios.verizon.net [173.48.64.3]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4BwnSK0ggSzXTR for ; Tue, 22 Sep 2020 12:53:21 -0400 (EDT) Subject: Re: Error message output To: freebsd-questions@freebsd.org References: <20200920191108.22864e5c.freebsd@edvax.de> <528b2c90-18c4-9e95-a150-67344154c66c@holgerdanske.com> <20200921132139.286b5bda.freebsd@edvax.de> <8b426d6f-6ebe-d1a7-13af-69cffbcb6222@holgerdanske.com> <20200922005552.4df3c123.freebsd@edvax.de> <0dc8a3a4-85d9-7168-f118-b456aafd3910@holgerdanske.com> From: Kurt Hackenberg Message-ID: <25dc8a18-e276-6f6b-685b-377bdf0ffa73@panix.com> Date: Tue, 22 Sep 2020 12:53:19 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <0dc8a3a4-85d9-7168-f118-b456aafd3910@holgerdanske.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4BwnSK6D6Vz4Jk5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kh@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=kh@panix.com X-Spamd-Result: default: False [-1.61 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[166.84.1.89:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:166.84.0.0/16]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.82)[-0.823]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.09)[0.088]; RCVD_IN_DNSWL_MED(-0.20)[166.84.1.89:from]; DMARC_NA(0.00)[panix.com]; NEURAL_HAM_MEDIUM(-0.38)[-0.375]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions]; RECEIVED_SPAMHAUS_PBL(0.00)[173.48.64.3:received] 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: Tue, 22 Sep 2020 16:53:22 -0000 On 2020-09-22 02:33, David Christensen wrote: > Providing a fractional base file name as an argument and computing input > and output file names is unconventional.  The FreeBSD convention seems > to be to use complete file names for arguments.  This allows the user to > use shell globbing, find(1) and xargs(1), etc., or to wrap this script > in another script that computes the arguments. ... > When given no options or arguments, the FreeBSD convention seems to be > to run the program with a default argument.  If no default makes sense, > then to print the usage message. All true, except these are conventions for all Unixes, not just FreeBSD, from sometime early in Unix history. An early example is the program "cat" (which is easy to write in C). Arguments are input filenames; with no arguments it reads stdin. The convention that the user supplies file base names, and the program adds extensions, is strong in some other OSes, including those from Microsoft and Digital Equipment Corporation. This is tied to the idea, more or less built into those systems, that the file extension is separate and special, and has meaning. In fact, in those filesystems, the file extension is stored separately from the base name, and the '.' is not stored at all. (Well, I don't know that about NTFS.) In Unix, the opposite convention is equally strong: a filename is just a single string, and is not parsed; the user supplies complete filenames. In a Unix filename, '.' is stored as part of the name, and has no special meaning. A filename can include zero or more suffixes that start with '.'. Executable programs usually have zero; "foo.tar.gz" has two. Yes, there are mild exceptions -- compilers, make, ls (by default ignores names that start with '.') -- but this is the origin.