Date: Tue, 22 Sep 2020 19:30:19 +0200 From: Polytropon <freebsd@edvax.de> To: Kurt Hackenberg <kh@panix.com> Cc: freebsd-questions@freebsd.org Subject: Re: Error message output Message-ID: <20200922193019.9ddd63f7.freebsd@edvax.de> In-Reply-To: <25dc8a18-e276-6f6b-685b-377bdf0ffa73@panix.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> <25dc8a18-e276-6f6b-685b-377bdf0ffa73@panix.com>
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:
>=20
> > Providing a fractional base file name as an argument and computing inpu=
t=20
> > and output file names is unconventional.=A0 The FreeBSD convention seem=
s=20
> > to be to use complete file names for arguments.=A0 This allows the user=
to=20
> > use shell globbing, find(1) and xargs(1), etc., or to wrap this script=
=20
> > in another script that computes the arguments.
> ...
> > When given no options or arguments, the FreeBSD convention seems to be=
=20
> > to run the program with a default argument.=A0 If no default makes sens=
e,=20
> > then to print the usage message.
>=20
>=20
> All true, except these are conventions for all Unixes, not just FreeBSD,=
=20
> 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=
=20
> no arguments it reads stdin.
>=20
> 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.)
>=20
> In Unix, the opposite convention is equally strong: a filename is just a=
=20
> 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=
=20
> with '.'. Executable programs usually have zero; "foo.tar.gz" has two.
>=20
> 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". :-)
--=20
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200922193019.9ddd63f7.freebsd>