Error message output

[Polytropon]

On Tue, 22 Sep 2020 12:53:19 -0400, Kurt Hackenberg wrote:
> 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.

Exactly. That's why I should add further development time to the
little script; not just that it makes assumptions about file names
which _may_ be true, but don't always apply ("base_nnn.png" needs
to be resolved where nnn, the counter, is replaced by * and then
evaluated by the scripting shell). More flexibility is always
better, be it different base names, names not following the
format expected, or input file lists generated by a different
tool or step.

In UNIX, a file can have generally any name, the extension(s) have
a meaning usually only to the user; "blah" could be a PDF file, and
"xpdf blah" would work, and a C compiler would happily compile a
source file named "perry_the_platypus".

The interpretation of special cases, such as leading "." by ls,
is program-specific. The filesystem adds special interpretation
for entries "." and "..", as well as for the character "/", but
anything else, non-printable characters, tabs and spaces, special
characters, even linebreaks could probably make a truly valid (!)
filename. Not all valid filenames are useful, though... ;-)

In systems where all parts interpret filenames as a concept of
"base.extension", and decide for actions according to extension,
the flexibility of UNIX filenames can cause confusion. If you
accidentally remove the ".pdf" from a PDF filename, the file can
no longer easily be opened (except maybe by "Open with...") until
the ".pdf" is added back again; adding ".mp3" instead causes much
more confusion for the system and the user.

Imagine what stops working if you add a VMS-like ";version". :-)





-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...