Sujet : Re: Case Insensitive File Systems -- Torvalds Hates Them
De : invalid (at) *nospam* invalid.invalid (Richard Kettlewell)
Groupes : comp.os.linux.miscDate : 07. May 2025, 22:41:36
Autres entêtes
Organisation : terraraq NNTP server
Message-ID : <wwv7c2sf69b.fsf@LkoBDZeT.terraraq.uk>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
"Carlos E.R." <
robin_listas@es.invalid> writes:
On 2025-05-07 12:00, Richard Kettlewell wrote:
Forbidding newlines in extfs and its successors would be
straightforward indeed - no harder than forbidding ‘/’ in
filenames. But as well as swimming against the Unix tide it wouldn’t
actually eliminate the higher-level problem that shell copes badly
with filenames with spaces, newlines, etc, since there’s more to life
than Linux’s native filesystem. Early versions of Linux used the
Minix filesystem, and today the kernel includes a large collection of
‘foreign’ filesystems.
>
Using almost any other language than shell, on the other hand, makes
the problem go away.
>
Except if you hardcode a filename inside a C program, for
instance. You still have to escape the quotes.
I’m not sure what you mean. First, no quotes need escaping.
FILE *fp = fopen("whatever\n", "r");
i.e. the normal way of representing newlines in C programs.
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.
(Strings with nulls in are another matter, but not relevant to filenames
in Unix filesystems, and AFAIK not common anywhere either.)
-- https://www.greenend.org.uk/rjk/