Deutsch   English   Français   Italiano  
<wwv34mlm70f.fsf@LkoBDZeT.terraraq.uk>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.net!news.chmurka.net!nntp.terraraq.uk!.POSTED.tunnel.sfere.anjou.terraraq.org.uk!not-for-mail
From: Richard Kettlewell <invalid@invalid.invalid>
Newsgroups: comp.unix.programmer
Subject: Re: Long filenames in DOS/Windows and Unix/Linux
Date: Sat, 31 Aug 2024 09:27:44 +0100
Organization: terraraq NNTP server
Message-ID: <wwv34mlm70f.fsf@LkoBDZeT.terraraq.uk>
References: <9e7a4bd1-bfbb-4df7-af1a-27ca9625e50bn@googlegroups.com>
	<ubg6o7$3jrsn$1@news.xmission.com> <ubg853$2ssj8$1@dont-email.me>
	<ubg8a8$2t20l$1@dont-email.me> <vaubbo$1d324$1@news.xmission.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: innmantic.terraraq.uk; posting-host="tunnel.sfere.anjou.terraraq.org.uk:172.17.207.6";
	logging-data="42877"; mail-complaints-to="usenet@innmantic.terraraq.uk"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:em/GJOIsRdOhHWJQJ38MarBnkWY=
X-Face: h[Hh-7npe<<b4/eW[]sat,I3O`t8A`(ej.H!F4\8|;ih)`7{@:A~/j1}gTt4e7-n*F?.Rl^
     F<\{jehn7.KrO{!7=:(@J~]<.[{>v9!1<qZY,{EJxg6?Er4Y7Ng2\Ft>Z&W?r\c.!4DXH5PWpga"ha
     +r0NzP?vnz:e/knOY)PI-
X-Boydie: NO
Bytes: 3205
Lines: 37

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/