Re: Long filenames in DOS/Windows and Unix/Linux

gazelle@shell.xmission.com (Kenny McCormack) writes:

Two comments about spaces in filenames (and Windows vs. Unix):
>
    1) Windows is actually quite a bit more restrictive about characters in
filenames than Unix.  Which is a good thing.  I've always thought
the "anything other than NUL and /" in Unix was a bad thing and
encouraged all manner of bad/malicious outcomes.  Yet, there are
people (and I use the term loosely) who think otherwise.

The historical advantage of the free-for-all Unix approach is that
allowed flexibility in filename encoding. Today it’d work to say “UTF-8
only” (and maybe other restrictions) but that wasn’t always the case.
The original design has saved us from a bit of path dependency.

In the application-facing API (open, CreateFile, etc), the rule pretty
much has to be ‘anything goes’, because you may be dealing with a
‘foreign’ filesystem (e.g. via a network filesystem). I don’t want to be
unable to access an existing file just because two computers have
different sets of restrictions on filenames.

(I’ll be disappointed in extreme cases of course, e.g. filesystems that
permit ‘/’ in filenames, but the scale of the problem can be minimized.)

    2) Spaces in filenames are pretty much a necessity from the end-user
POV (but see below).  Yes, it makes things hard for us on the admin
side of the game.

I think the thing that makes it hard is not the spaces as such, but the
tooling that makes it inconvenient to handle them, which primarily means
Bourne shell parsing rules. The problem basically ceases to exist once
you’re outside the shell ecosystem.

The rest of Unix has evolved substantially since the 1970s but shell is
still stuck in this particular trap. It’s like we’re still making making
arrowheads out of flint but everything else from steel.

--
https://www.greenend.org.uk/rjk/