Craig Dickson 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.
> > Simply because something can be done does not warrant doing it . . .
>
> True, but in this case there's no sensible reason not to other than
> backwards-compatibility. I'm not really arguing in favor of changing all
> the thousands of Unix tools in the world to handle filenames with
> spaces. For that matter, most of them handle such filenames fine under
(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.
now I agree that some of the default behaviour could have been better.
about the only big time offender is xargs (but -0 in gnu version
solves most problems)
I almost agree with you but I don't think current situation is that
bad.
> limited circumstances, and it isn't that hard to write a shell script
> that will do so. My specific point was that the standard Unix shells, by
> default, expand variables in a way that causes a number of problems,
> filenames with spaces being only one example.
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
> > > 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".
> >
> > I'll leave that debate for others -- nevertheless, this is one
> > remarkable reason that windoze file handling is so weak ;>
>
> Windows is defective in many ways, but the use of spaces in filenames
in addition to that: windows doesn't handle spaces in different way
(compared to unix). and how is windows file handling extra bad? you can
install bash or some other shell and you have basically same behaviour
as on unix systems. not sure how the pipes behave (performance wise) but
those do not have anything to do with how the filenames are handled.
> has nothing to do with any of them. That has to be the lamest straw man
> argument I've ever come across; it amounts to nothing more than poking
> fun at something that's unpopular with the crowd you're playing to,
> without regard for truth or fairness.
>
> > Besides, my point, as stated previously, is this, "Perhaps, you ought to
> > ``correct'' the tools, then impose arbitrary complexity ???"
> >
> > Please, do not put the cart before the horse . . .
>
> You either haven't been reading very carefully, or aren't sufficiently
> informed to have a sensible opinion, to judge by what you've said so
> far. This "arbitrary complexity" thing is total nonsense.
>
> To be specific, I've suggested that things would be better today if one
> aspect of the Bourne shell had been designed better, namely how it
> treats the expansion of variables whose values contain embedded spaces.
> Right now, after the assignment A="foo bar", the expansion of $A is
> interpreted by the shell and all Unix tools as two separate strings, foo
no, not by the tools, just by shell. the tools genarally handle it as
one string (it doesn't even have to be filename, it depends on the tool
hot it interprets given argument.
and BTW this isn't really discussion about spaces in filenames, it it
how shell treats variables and all values (whether it's a filename or
any other string) are handled that way, filenames are just a specific
example...
> and bar, rather than the single string "foo bar", as it was originally
> given (with quotes). This default behavior breaks filenames with spaces
> (you have to remember to specify "$A", in quotes, to preserve the string
> properly), and allows for a number of other problems as well, such as
> the well-known security problems that can arise when setuid or cgi
> scripts expand variables whose values were originally read from user
> input.
>
> It would have been better for the default expansion of a quoted string
> to include the quotes, precisely to preserve strings with embedded
> spaces. There could have been some trivial syntax to cause such strings
> to be broken up, such as when you use a variable to store a list of
> space-delimited strings. It wouldn't have been a major change, and it
> would have been better.
>
> There are also minor implications for other tools here; for example,
> 'ls' and 'find' should be able to quote filenames with embedded spaces
> in their output, to allow them to be parsed correctly. But this is still
> a minor shift, and had it been made early enough in Unix's history, it
> would have been a small thing, and overall an improvement. I don't think
> it can happen now, at least not in the context of the sh-derived shells
> and the traditional Unix tools; you'd break too many things. If someone
> wants to design a new shell from the ground up, and get this right, it
> would be nice.
I don't think that would work, to make a consistent usable system
you'd have to go with 'real' variables, as mentioned above...
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?
> > > 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.
> >
> > In general, your examples are very weak. Are you familiar with $IFS and
> > its ilk?
>
> Sure. But there's absolutely no need to alter the basic token-parsing in
> the shell; it already understands strings with spaces as long as they're
> quoted. All that's necessary is that the expansion of variables
> containing such strings retain the quotes. It shouldn't be necessary to
> alter IFS just to get reasonable behavior out of the shell.
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?
let's note that it's mostly the shell, basically all other tools
handle any characters properly (not talking about shell scripts, those
all depend on how careful the author was).
so we are not talking about how unix handles space in filenames but
how shell handles space in its variables, that's really the main
discussion (filename are influenced by that, but so are any other
strings).
erik
