Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Sep 2020 19:30:19 +0200
From:      Polytropon <>
To:        Kurt Hackenberg <>
Subject:   Re: Error message output
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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 inpu=
> > and output file names is unconventional.=A0 The FreeBSD convention seem=
> > to be to use complete file names for arguments.=A0 This allows the user=
> > 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.=A0 If no default makes sens=
> > 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=20
> "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=20
> adds extensions, is strong in some other OSes, including those from=20
> Microsoft and Digital Equipment Corporation. This is tied to the idea,=20
> more or less built into those systems, that the file extension is=20
> separate and special, and has meaning. In fact, in those filesystems,=20
> the file extension is stored separately from the base name, and the '.'=20
> 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.=20
> In a Unix filename, '.' is stored as part of the name, and has no=20
> 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=20
> 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". :-)

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

Want to link to this message? Use this URL: <>