Error message output
freebsd at edvax.de
Tue Sep 22 17:30:26 UTC 2020
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". :-)
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions