begin quoting John H. Robinson, IV as of Sun, Mar 05, 2006 at 12:34:38PM -0800:
> Stewart Stremler wrote:
[snip - emphasis of "legal character"]
> > And nulls. Don't forget nulls.
>
> Outside the scope. Nulls are not allowed in filenames.
Baloney. It's such an arbitrary restriction. It's a legal ASCII value;
surely it should be allowed in a filename, by your own argument.
> > > 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.
I see it as either disallowing arbitrary character sets, or not. The
oblique stroke is just a character, as is null -- but the current
situation grants special privelege to some characters, but not others.
Why is this a good thing?
Your argument seems to be that limitations are bad -- so null and slash
ought to be allowed. My argument is that arbitrary characters ought to
be disallowed -- allowing null, slash, and space to be marked as illegal.
If we disallow some, we have to disallow any.
[snip]
> > 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.
Um, no. We parse out _sentences_ using periods. We tokenize words on spaces.
(I've read prose where words are tokenized using slashes. Terribly hard
to read, but apparently one can learn to do so in a fairly short period
of time.)
[snip]
> > And it is, given the reasonable constraints.
>
> I don't see saying ``no whitespace in filenames under any
> circumstances'' is a reasonable contraint.
I don't see how it isn't a reasonable constraint.
> As we can see, the tools can
> deal with it quite well. It is only certain uses of shell variables that
> we have problems.
Shell variables, display issues, data entry issues... the problems are
legion. Any feature that causes more problems than it solves isn't a
worthwhile features.
> I would say that someone putting backspaces in a filename is probably up
> to something no good.
>
> $ cp trojanfile ..^H.
Yup. I've created files with all manner of strange characters, just to
do so. I'm not saying that you shouldn't be allowed to do so -- but I
want the control on _my_ systems to disallow such thing. I want complete
mediation of all input data is a _good_ thing.
> > 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.
COMMAND/OPT/FFILENAME/SUB/BLAH/BLAH
Nice and easy to read, no?
> It is just a
> different way of doing it. How you describe Fortran, though, just sounds
> to be complete brain-death.
IFI.EQ.1GOTO10
Like most rules about whitespace, you can adapt, but it's generally far
better (IMNSHO) to make the computer do the hard work.
> 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.
That's a feature, actually. Building up a list of options by
concatenating and/or string-replacement in a string is a simple
and useful technique. Except that you can't do such things with
filenames, which means that a simple technique needs to be replaced
with something more complicated.
The problem is that there are two interpretations...both valid, but
at odds. Spaces are for tokenization; embedding tokenization characters
in tokens is just asking for trouble.
> Even putting quotes in the
> assignment does not help:
>
> $ a='"one two three"'; set $a; echo $1.$2.$3
> "one.two.three"
Hmm....
% sh
$ a="one two three"; set $a; echo $3 $2 $1
three two one
$ a="one two three"; set $a; echo "$3 $2 $1"
three two one
$ a="one two three"; set "$a"; echo $3 $2 $1
one two three
$
Quoting does help, if you quote the right piece. But quoting is
annoying, and most folks get to a point pretty soon that they find
is best described as "quoting hell". Finding the right places to
quote is typically a trial-and-error process until you find the trick
that works.
I suppose one of the reasons why I the ability to disallow arbitrary
characters is that I don't see a good reason to _allow_ spaces on my
systems, nor backspaces, carriage returns, tabs, ampersands, parens,
or any of a number of other characters. My system, I should get to
set the rules, right? You can use a different set of rules on your
system, and we can argue about the relative benefits of our respective
rulesets.
--
_ |\_
\|
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
