Re: Case Insensitive File Systems -- Torvalds Hates Them

Rich <rich@example.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

Richard Kettlewell <invalid@invalid.invalid> 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

 
That is not the "find" documentation, that is the documentation for
locate/updatedb and the db format they use to make locating a filename
faster than a raw disk scan.  That 'running of sort' is done by
'updatedb', not find. 

OK sorry, the GNU Findutils documentation, there talking about GNU
locate.

Of course a C program can use any character to separate strings

 
A C program uses (if it uses libc's string routines) ASCII nulls to
mark the end of a C string in memory.  Of course if you want to build
your own "C string" library (C's strings are provided by libc, not the
C language itself) you can choose to delimit strings however you wish.

There's some miscommunication here, I'm talking about when a C
program reads in/out strings from/to a file, pipe, etc., not how
it stores them in memory itself. Find, sort, uniq etc. use newlines
for that by default.

But it means assuming that newlines in filenames won't actually
appear.

 
Which, in reality, is all but true unless someone is going out of their
way to experiment or be very odd.  The only time I've ever encountered
filenames with newlines has been when I've deliberately created them to
verify some bit of code (or to try to break some bit of code, although
verify/break often go hand in hand).

That's my point exactly, all these work-arounds in specific
programs like "find -print0" in GNU Find have been written even
though use of newlines in filenames is so rare. We'd have been
better off with newlines forbidden in filenames so that all the
special handling just for the sake of someone "going out of their
way to experiment or be very odd" could be avoided. Probably more
secure against people hacking software whose authors didn't think
about it too.

Yes it's too late to change now, _someone_ will be using filenames
with newlines in a major way, but I'd say the same about the case
insensitivity feature which "Torvalds Hates".

--
__          __
#_ < |\| |< _#