4 ms·
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: "00000000
by harrytuttle 13y ago
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"
- icebraining 13y agoThe 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.
- harrytuttle 13y agoRubber 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
- icebraining 13y agoValidity? 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?
- harrytuttle 13y agoIt is merely an illustration. The reality is stuff like that occasionally does happen when you use variables and parse results from other commands.
- phaemon 13y agoNo 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!
- harrytuttle 13y agoWhat if you do the following? VARX=".. " # by accident as the result of a command mkdir $VARX