Neal Gompa (ニール・ゴンパ) 

🌶️🌶️🌶️🌶️ take: The fact that UNIX tools haven't adapted to LFNs properly in over fifty years is terrible. Normal people want natural file names (and even technical people like myself do too).

It's a massive failing that Linux userspace has not adapted to make natural language name conventions easier to use. Computers should adapt to user needs, not the other way around.

Mar 1 at 2:17pmWeb
Show threadHenriMar 1
@neal MS really forced everyone to support it when they introduced C:\Program Files
Show threadMegabot#33  Mar 1
@slyecho @neal You would have UNIX purists complain how it's wasting resources and it's too much to type 
Show threadmirabilosMar 1

@neal ?

All Unix filenames are technically LFNs, as the limit was 14 > 8 + 3 always.

Show threadmirabilosMar 1
@neal and not all-uppercase either
Show threadNeal Gompa (ニール・ゴンパ) Mar 1
@mirabilos They are, but lots of tools assume you don't take advantage of that. It also is reflected in usernames and other things which technically permit these things, but enough tools assume otherwise that you can't. 😦
Show threadAnisseMar 1
@neal I blame the bad shells and the text processing tools without -0
Show thread_L4NyrlfL1I0Mar 1

@neal which unix tools still have problems with that?

I know that GNU make still has some problems with quoting spaces, which means that some Makefiles of some projects don't work well in directory hierarchies with spaces in them, but most other tools work pretty well with spaces and most special characters.

I'm not quite sure about toops like grep and unicode support (grepping for "ö" for example), I think unicode might still be less well-supported.