Michael D. Schleif wrote:
> How would you like to handle 0x08, 0x0a or 0x0d ??? Remember, we are
> talking about text handling here, not binaries . . .
We can sensibly limit ourselves to printable characters for filenames;
it's silly to suggest that if you let people use spaces, next they'll
want control characters.
There is a good reason to support spaces if you want your OS to appeal
to ex-Windows or ex-Mac users, who are used to creating filenames like
"Letter to Joe.doc" or "Smith Family Budget.xls".
Unfortuantely, since spaces in filenames have never been a priority for
Unix users, most Unix tools behave counter-intuitively (from the
perspective of someone new to the system) when confronted with such
things. For example, in Bourne-related shells:
A="foo bar"
B="baz"
for C in $A $B; do
echo $C
done
will not output, as you might intuitively expect,
foo bar
baz
but instead
foo
bar
baz
because $A expands to two separate strings, not a single string with an
embedded space. You have to be careful enough to write
for C in "$A" "$B"; do
to get the natural behavior regardless of the contents of A and B. In
other words, you ought to have to go out of your way to cause $A to be
interpreted as more than one thing, but in fact that's the default when
$A has a space in it. There are a lot of shell scripts in the world
today that break when given filenames-with-spaces precisely because of
this problem. And a lot of scripts that break (often with nasty effects
on security) because the author expected $A to be a single filename, but
someone passed in a set of filenames, or something even worse like a
filename, a semicolon, and some unrelated command (which ends up being
executed as root because the script is suid root).
If Unix were just being developed today, without thirty years of history
and backward-compatibility to worry about, I'd submit a bug report for
things like this. I understand why it works the way it does; I just
think it was a mistake.
Craig
