Stewart Stremler wrote:
> begin quoting John H. Robinson, IV as of Sun, Mar 05, 2006 at 09:01:54AM
> -0800:
> [snip]
> > Artificial limitations are eviler.
>
> Disallowing spaces is a special case of disallowing user-imposed limitations;
> the user should _always_ be allowed to impose whatever limitations they
> choose. It's their machine, after all.
>
> > I will stick with being able to
> > handle any legal character, this includes backspaces, newlines, and
^^^^^^^^^^^^^^^
> > horizontal tabs in addition to spaces.
>
> And nulls. Don't forget nulls.
Outside the scope. Nulls are not allowed in filenames.
> > What is truly evil is disk-editing a solidus into a filename.
>
> Nah. Ignoring the user's wishes, that's the problem. "This is what I
> think you ought to want to do, therefore, I'm going to enforce that."
Again, outside the scope. The two ASCII characters not allowed in a
filename are Null and solidus. One is the end of the name, the other is
a directory delimiter. In a pathname, solidus is certainly allowed. Null
still isn't, though.
> > The only reason I can think that a space in a filename would be
> > considered evil is because the space is a token separator on the shell
> > command line.
>
> It's also the token separator when reading prose; the eye is trained to
> tokenize on spaces.
True. If we followed written conventions, the thing to do would be to
end all filenames with a ., and we would not have these problems. We'd
have different ones, instead.
>
> [snip - bourne-shell brokenness]
> > Since no one put spaces in
> > filenames, people got used to thinking that $a was sufficient for
> > filename use.
>
> And it is, given the reasonable constraints.
I don't see saying ``no whitespace in filenames under any
circumstances'' is a reasonable contraint. As we can see, the tools can
deal with it quite well. It is only certain uses of shell variables that
we have problems.
I would say that someone putting backspaces in a filename is probably up
to something no good.
$ cp trojanfile ..^H.
> Remember, the computer is there for the human; if there's tedious
> manual work involved, it should be performed by the computer, not the
> human.
Agreed.
> > This is, what I consider, a poor design initially. However, the mind-set
> > has stuck, and some modern shells still maintain this broken behaivour
> > even though they have proper array variables now.
>
> There have been systems that did not use spaces for tokenization; they
> are generally (in my opinion) more difficult to use; this is reflected
> in the MSDOS use of / as an option indicator -- and all the fun that
> results from that. And fortran had the worst of both worlds: mandatory
> leading whitespace and optional whitespace everywhere else.
I don't see a problem with / instead of - for options. It is just a
different way of doing it. How you describe Fortran, though, just sounds
to be complete brain-death.
I am not objecting to whitespace as a token delimiter; it works very
well. The problem, as I see it, is:
$ a="one two three"; program $a
program will see THREE tokens, not one. Even putting quotes in the
assignment does not help:
$ a='"one two three"'; set $a; echo $1.$2.$3
"one.two.three"
-john
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
