Re: How to handle whitespace in filenames ???
Erik Steffl wrote:
> > Of course, if you want to admit that MacOS and Win32 can do something
> > better than Unix can -- which is the obvious implication of a lot of
> > what you've said on this subject --, be my guest.
>
> ? how could that be? what's the difference (ms<->mac<->unix)? the only
> difference is that in unix you are more likely to use command line and
> so have to be aware of 'funny' characters that might be interpreted by
> shell.
Oh, there isn't much difference at all. The point is that Windows and
Mac users put spaces in filenames all the time and it's no problem, even
in shell scripts. So if Michael is right that spaces in filenames are
"bad" for Unix, then he's essentially admitting that Unix can't do
something that Windows and Mac already do. Which is patently inane.
> (almost) all the tools do handle filenames with spaces. the only
> problem is the shell, and in most cases it's solvable by being aware of
> what's actually going on. so there's no need to change thousands of unix
> tools.
Not just the shell. 'find' and 'ls' can't be told to put quotes around
filenames with spaces. But you're right that the shell's treatment of
variables is the worst problem, and you're also right that it isn't just
a filenames issue.
> IMO the only real way out of that mess is for shell variables to
> behave like variables in programming languages (e.g. perl - you still
> can get into similar kind of trouble but they are much easier to solve
> and there's a lot more of the frequent situations where it works
> properly). that would be fairly radical change for a shell...
>
> as long as the variable names are replaced by the values of variables
> and then the command is executed there will be the same kind of problems
> as there are now
I think 99% of the problem could be handled by just having the shell
put quotes around variable expansions that include embedded spaces:
%A="foo bar"
%echo $A
"foo bar"
This would ensure that in a situation like
for X in $A $B $C; do ... done
that the values of A, B, and C are kept intact. And you would also want
some trivial syntax to indicate that you don't want that behavior, so
that the practice of putting lists in variables would still work.
> there's nothing to prevent us to write another shell that would do it
> THE ONLY RIGHT WAY:-) it might be interesting experiment. there's
> already number of shells, some of them fairly different. isn't there
> even perl shell?
Could be. I know there's a scheme shell, but that's a pretty radical
difference, syntactically, from the Bourne-style shells.
> then again, what if there's a quote in the quoted string? users are
> crazy, they put the least expected characters into filenames. single
> quotes are quite common (used as apostrophes). etc. and why shouldn't
> they?
Yes, that's true. Spaces are really only one example. But you could
fairly easily handle all printable characters except double-quotes,
which is what Windows does. Bash will treat a single-quote as just
another character inside a double-quoted string, so apostrophes can be
handled that way -- likewise ampersands.
Fundamentally, the fact that the usual Unix filesystems let you put
pretty much any character, printable or otherwise, into filenames, makes
it very difficult for a command-line shell to handle all cases well.
However, it isn't that hard to deal with most printable characters,
because in a string encased in double-quotes, the shell will treat
single-quotes as ordinary text.
Personally, I avoid spaces in filenames (on Unix systems) religiously,
but it seems silly to claim there's something bad about them just
because the shell and a few other tools are misdesigned.
Craig
Reply to: