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/