Date: Tue, 22 Sep 2020 12:53:19 -0400 From: Kurt Hackenberg <kh@panix.com> To: freebsd-questions@freebsd.org Subject: Re: Error message output Message-ID: <25dc8a18-e276-6f6b-685b-377bdf0ffa73@panix.com> In-Reply-To: <0dc8a3a4-85d9-7168-f118-b456aafd3910@holgerdanske.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25dc8a18-e276-6f6b-685b-377bdf0ffa73>