Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.unix.programmer Subject: Re: Long filenames in DOS/Windows and Unix/Linux Date: Tue, 03 Sep 2024 15:16:36 -0700 Organization: None to speak of Lines: 63 Message-ID: <87seug1iyj.fsf@nosuchdomain.example.com> References: <9e7a4bd1-bfbb-4df7-af1a-27ca9625e50bn@googlegroups.com> <20240903084440.0000663d@gmail.com> <20240903103327.395@kylheku.com> <20240903113937.000008a3@gmail.com> <20240903130000.933@kylheku.com> <20240903132547.00000656@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Wed, 04 Sep 2024 00:16:37 +0200 (CEST) Injection-Info: dont-email.me; posting-host="0c8cc2609bc8d9fbbbb3d106ce45f413"; logging-data="3664048"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+HnX6+/KVjy/r7z2f5qCe" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:ETDWlLvEEsqL0Hz3Z41dp+NYfCQ= sha1:2RKlvdanfi4aIQ3Bi9ww1RVYOo4= Xref: csiph.com comp.unix.programmer:16269 John Ames 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 */