Error message output

[Kurt Hackenberg]

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.