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

John Ames <commodorejohn@gmail.com> writes:

On Tue, 3 Sep 2024 20:11:28 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>

Because it is based on a strawman interpretation of the "no spaces"
rule. That strawman interpretation is that there are no other rules
used in combination with the "no spaces" rule, and thus that any
ridiculous name is fine, just as long as it doesn't contain spaces.
 
And so, look how unreadable is this 100 character name in CamelCase!
Q.E.D. no spaces is a bad recommendation!

>
Well, there were no other factors *presented* alongside the blanket
statement that spaces in filenames are unnecessary, so it would appear
on the face of it to be an accurate assessment of the claim being made,
which wasn't in a post of yours to begin with.
>
And I'd still like to know who died and made whom king where filenames
and spaces therein are concrned.

There is no official "rule" about spaces in filenames, though I can
imagine easily imagine that some organizations and projects have
rules forbidding them.  A couple of data points: The gcc git repo
contains 137394 files and none of them have spaces in their names.
The Linux kernel git repo contains 85803 files, and exactly one has
spaces in its name.  In either cases, I don't know whether this is
due to some hard rule.

Spaces in file names are likely not to be an issue if you interact
with the filesystem via a GUI like Windows Explorer *or* if you use
a scripting language like Perl or Python that requires strings used
as filenames to be enclosed in quotation marks.  In those contexts,
space is just another character.

It can be a real issue if you're interacting via shell commands.
If I happen to know that none of the files I'm working with have
spaces (or other problematic characters) in their names, a lot of
things become easier -- but risky if there's a funny character I'm
not aware of.  For example, I might type something like:

    for file in * ; do cp -p $file $file.bak ; done

(Yes, this skips files whose names start with '.'; I usually don't
need to worry about that) I never (well, hardly ever) create files
with spaces in their names.  I typically use '-' rather than '
' to delimit words in file names.  When I have to work with such
files, I can do it, but it requires a bit of extra effort.

And if, for example, I'm writing a shell script that needs to be
generally useful, I'll spend the extra effort to make sure it works
with arbitrary file names (or I'll write it in a scripting language
where it's not an issue).  But I don't typically bother if I know
I'm working with files that I created.

It would be ideal, I suppose, if interactive shells dealt better with
spaces in file names, but I'm not sure how that could be achieved.
In current shells, removing two files named "foo" and "bar" is easy, and
removing a single file named "foo bar" requires some extra effort.  I
find that to be a good tradeoff.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */