I once accidentally did:

    $ touch ./~
    # Much later I noticed the "~" file in the directory
    # so I mindlessly decided to cleanup:
    $ rm -rf ~

Luckily $HOME was on a _really_ slow NFS mount so I didn't manage to remove anything too important before I killed it.

Ha that's a classic.

A friend of mine did a "rm -rf ~ /tmp" rather than "rm -rf ~/tmp" on a fast SCSI local disk on his Sun workstation.

His backup strategy of tarring up everything into ~/backup went with that one too. I lectured his ass on that one.

However...

The same guy, no less than 8 years later carried around a DVD-RAM with his single copy of his life's work on it (I assume this was only 8 years of his life) and jammed it in one of those dodgy Pioneer slot loader drives and proceeded to mount it.

bzzzt ... wheee ... clunk ... BANG! DVD span to full speed and promptly shattered taking the drive fascia off and spraying everyone with bits of "I told you so".

He now puts up scaffolding which worries me even more...

Luckily I was on an IT maintained machine that takes nightly snapshots of home partitions so I was safe in the worst case. Had I done that on one of my personal machines I wouldn't have been so lucky.

Now go and fire of "rm -rf ..". Now we're talking fun.

Exactly my point!

You can't plan for user stupidity. The system paths do not have spaces in them.

No but allowing leading and trailing spaces is not user stupidity. That is design stupidity.

You know like recording numbers as string in the format: "0000000000000000000000000123.23210000000000000"

The shell by default ignores spaces, you have to specifically force it to acknowledge them by enclosing the name in quotation marks or escaping with a backslash. In that situation, a command line tool should do what it's told, not disobey a direct command. Leave the rubber padded tools for the GUI land.

Rubber padded I do not expect. Retarded I also do not expect.

Explain the validity of:

   mkdir " "
   mkdir "  "
   mkdir "   "

?

It at least violates the principle of least surprise

Validity? It's a string like any other. It's not mkdir's job to second-guess what I tell it to do.

And I don't see how it violated such principle. You tell it to create a file with spaces - you even emphasized them with quotes -, and you're surprise it did so?

It is merely an illustration. The reality is stuff like that occasionally does happen when you use variables and parse results from other commands.

No it's not. If you type

    mkdir ..<space>

it tells you "cannot create directory". You have to explicitly tell it you want a space in by using quotes (as you well know).

Oh, and it's my computer. I don't want my shell telling me what I'm "allowed" to do. If I explicitly tell it to do something, it should damn well do it!

What if you do the following?

    VARX=".. " # by accident as the result of a command
    mkdir $VARX

Sure, but a non-ambiguous external representation should be mandatory when a semantic value conflates with a presentation one.

Here ' ' is part of both worlds: . .. ..

A first idea: . .. ..\

ls may also take inspiration from bash completion, where dirsep serves as a better delimiter than ' '

    noob ~ $ mkdir -pv lsb/wat
    noob ~ $ cd lsb/wat
    noob ~/lsb/wat $ mkdir ".. "
    noob ~/lsb/wat $ ls -lah
    total 12K
    drwxr-xr-x 3 noob noob 4,0K august  28 16:52 .
    drwxr-xr-x 3 noob noob 4,0K august  28 16:52 ..
    drwxr-xr-x 2 noob noob 4,0K august  28 16:52 .. 
    noob ~/lsb/wat $ cd ..<TAB-COMPLETION>
    ../  .. /