Path: ...!weretis.net!feeder9.news.weretis.net!xmission!nnrp.xmission!.POSTED.shell.xmission.com!not-for-mail From: gazelle@shell.xmission.com (Kenny McCormack) Newsgroups: comp.unix.programmer Subject: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) Date: Sat, 31 Aug 2024 05:57:12 -0000 (UTC) Organization: The official candy of the new Millennium Message-ID: References: <9e7a4bd1-bfbb-4df7-af1a-27ca9625e50bn@googlegroups.com> Injection-Date: Sat, 31 Aug 2024 05:57:12 -0000 (UTC) Injection-Info: news.xmission.com; posting-host="shell.xmission.com:166.70.8.4"; logging-data="1477700"; mail-complaints-to="abuse@xmission.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: gazelle@shell.xmission.com (Kenny McCormack) Bytes: 3184 Lines: 50 In article , wrote: >On Tue, 15 Aug 2023 16:12:19 -0000 (UTC) >kalevi@kolttonen.fi (Kalevi Kolttonen) wrote: >>Kenny McCormack wrote: >>> But do they know that??? >> >>"They" probably don't know it. But let's face it, >>nobody really wants to create a file having '-' >>filename on purpose. The filename is not descriptive >>at all, it would be just an insane choice for anything >>useful. > >I used to think the same thing about spaces in filenames. Then along came >Windows. > (I happened to be re-reading this 1 year old thread, so thought I'd add a post to it) 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. 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 have always thought that the right answer is to have both - a short name that is usable for the admin side of the game and a long label that the user can work with. There are two solutions of this nature that I like: a) The "Extend a name" idea. Where you have short names at the filesystem level, but then have a database linked to that that allows the user to think that long, descriptive filenames are supported. A long long time ago, there was a DOS product called "Extend a name" that did this. Also, 4DOS (and later versions) does this. b) The way VFAT does it (and NTFS emulates) - where, for any file with a long name, there is an 8.3 filename (usually with weird characters in the filename) as well, and either filename is usable by programs. This is one place where I think Windows really gets it right (and Unix could learn from it). -- He continues to assert that 2 plus 2 equals 4, despite being repeatedly told otherwise.