Ken Irving wrote:
>
> On Wed, Dec 19, 2001 at 09:46:41PM -0800, Erik Steffl wrote:
> > ...
> >
> > 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).
>
> The only reason the shell is special in this regard is that it's
> the middleman in the user-application transaction. It's parsing
> the user's input into neat packets based on conventions and clues,
> one of which is that whitespace delimits stuff. If the shell were
> to auto-quote, say, filenames with spaces, then I suspect that
> special treatment would be lost if the shell was part of a pipeline
> of commands. The receiving application typically doesn't want
> to deal with quote characters, after all, and those are handily,
> simply, and thankfully removed by the shell.
>
> In HTML they defined a space-looking character (sequence) to fix this
> sort of problem, but that'd be hell for every shelled application to
> have to deal with. So then maybe the last shell process in a pipe
> unspecializes the special space... sounds ugly to me. (I've always
> figured the underscore was that special space-looking character,
> and it works quite nicely as it is.)
true, just note that you are not responding to me but to some other
emails in this thread...
> > 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).
>
> But the instigating case was of filenames arriving from backtics
> enclosing a find command, so I don't see how variables apply here.
ok, in most cases I used more proper: in variables and literal
strings. and btw there's really no difference between `` and variable,
if the output of `` is the same as value of variable it would behave
same... the only reason to mention variables is that when it's a literal
string you immediately see it, when it's variable it's not directly
visible so it might fool user (into thinking there would be e.g. two
arguments but in the end there would be e.g. three arguments)
> find conveniently presents its output with each filename on a
> separate line; the backtics screw that up, as I suppose does xargs,
> by glomming them all on a line delimited by spaces. I think the
> appropriate answer is "don't do that", and not "fix the shell",
> but that's just my opinion.
note that tcsh works as one (well, I :-) would expect (even though if
you think about it it's somewhat tricky):
panther:~...pokusy/space>grep Jack "`find . -name name\*`"
./name list:Jack Secondname
./name list:Jack Again
./namelist:Jack Secondname
./namelist:Jack Again
panther:~...pokusy/space>grep Jack `find . -name name\*`
grep: ./name: No such file or directory
grep: list: No such file or directory
./namelist:Jack Secondname
./namelist:Jack Again
where:
panther:~...pokusy/space>ls -1 name*
name list
namelist
I am not a proponent to fix the shell though... for similar (maybe
same) reasons you specify above...
erik
