Message-ID: <681be760@news.ausics.net> From: not@telling.you.invalid (Computer Nerd Kev) Subject: Re: Case Insensitive File Systems -- Torvalds Hates Them Newsgroups: comp.os.linux.misc References: <20250428111242.00007426@gmail.com> <6813f997@news.ausics.net> <68194581@news.ausics.net> <681aa121@news.ausics.net> <3aorelxelu.ln2@Telcontar.valinor> User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (Linux/2.4.31 (i586)) NNTP-Posting-Host: news.ausics.net Date: 8 May 2025 09:06:11 +1000 Organization: Ausics - https://newsgroups.ausics.net Lines: 25 X-Complaints: abuse@ausics.net Path: csiph.com!news.bbs.nz!news.ausics.net!not-for-mail Xref: csiph.com comp.os.linux.misc:67416 Richard Kettlewell wrote: > > Second, the issue in shell is is that newlines (or spaces) interact > badly with its approach to string handling: a filename can cause a > script to unexpectedly fail. For all that C has truly awful string > handling, it doesn't go awry just because there's a space or newline in > a string that it's working with. When dealing with programs like find, sort, uniq etc. it's more of a data format issue than a shell issue. As in the link from the GNU find documentation which I supplied before where "find" apparantly runs "sort" itself and needs that to support null-terminated line delimiters to handle newlines in filenames, rather than the default newline-terminated format: http://www.gnu.org/software/findutils/manual/html_node/find_html/Newline-Handling.html Of course a C program can use any character to separate strings, but newlines are most common in existing UNIX tools for text string processing, and most easily human-readable, so it's convenient to use that data format. But it means assuming that newlines in filenames won't actually appear. -- __ __ #_ < |\| |< _#