begin quoting John H. Robinson, IV as of Mon, Mar 06, 2006 at 10:56:50AM -0800:
> Stewart Stremler wrote:
[snip]
> > 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.
>
> Should, yes. However, the original designers of the UFS filesystem used
> null terminated strings. Go bug them, not me.
And the original designers of shells used spaces as tokens.
"It was designed that way" is a _crappy_ argument.
[snip]
> > 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.
>
> Exactly. All interfaces give some tokens meaning, and not others. Try
And why do they do this? To make life easier for us. We could simply
use something completely arbitrary, such as 39-bit numbers, entered in
octal, to refer to everything.
> using ++ as a variable name in C, for instance. This is nothing new.
> What you are saying is that you wish to impose *additional* restrictions
> that the underlying object (filesystem, in this case) does not.
Yes. On my systems, I want to impose additional constraints. You indicate
to me that this is a bad idea. I claim otherwise.
> > Why is this a good thing?
>
> You are the one trying to add in additional characters _with no good
> technical reason_.
On the contrary. You've laid out the technical reasons yourself: it
screws up simple commands in the shell.
There's no good reason to have spaces, backspaces, tabs, and suchlike in
filenames, unless you really want to deal with those headaches.
> You see it as a benefit to you. On top of that, you
> decry only spaces. I can think of two characters that are even worse:
> newlines, and backspaces.
I decried the inability to choose arbitrary charactersets to (dis)allow.
Spaces are just the most commonly abused character; an EOT character
would be more dangerous for the command-line user.
> It takes tools that will null-terminate filenames, such as GNU find and
> GNU xargs, in order to handle files with newlines in their names. That
> is far worse. Spaces are a walk in the park in comparison. Backspaces
> change the apparent name, so it is very difficult to type them.
Yup.
If you really want to play those games with filenames, that's your
choice; if you don't, you ought to have the option to put into place
the rules to mediate those decisions.
[snip]
> However, newlines and backspaces are not nearly as common in filenames
> as spaces are.
That depends on the system and the user. Spaces in filenames are
generally rare on my systems, except when some software *enforces*
spaces -- and given a confrontation between software and the system
owner, it's my belief that the system owner should win.
This is not a common belief.
Many developers, geeks, and corporate decision-makers think otherwise.
[snip]
> You can make an argument for Null being allowed. You will have a far
> harder time convincing me that solidus should be legal in a filename.
> That is the token separator for directories.
Mere token separation isn't a sufficient argument to exclude spaces, but
is for directories? That seems a bit... inconsistent.
[snip]
> If you design a filesystem, then you are free to add in whatever
> restrictions you want. You can even make the directory delimiters be a
> colon instead.
I don't believe "directory delimiters" are part of the filesystem
design.
(And it's not really a filesystem choice, either... it's a syscall
choice. I had a project that started down the path of playing with
adding contraints to filenames, but the kernal-compilation mess was
just no fun at all, so I abaonded the project.)
[snip]
> > Um, no. We parse out _sentences_ using periods. We tokenize words on spaces.
>
> Please note that is not what I said.
You suggested that we tokenize filenames on periods:
"If we followed written conventions, the thing to do would be to
end all filenames with a ., ...."
If you are not suggesting that ending a filename with a period would
be "following written convention", what are you suggesting?
> No reason that a filename has to be
> one word. What is your name, again? I believe there at least three
> tokens in it.
Nope, just one.
I have many names, on the other hand. Different ones are used in
different contexts, and sometimes multiple names are used at once.
> We are used to dealing with multiple tokens in a name. No
> reason to exclude filenames from such a useful convention.
Except that it makes life more difficult for us -- I don't quote my
name to keep the tokens together, which is what we're looking at.
If you want gaps in filenames -- so that you can use sentences or
phrases or multi-word names, what you need is a space-that-isn't-a-space.
Oddly enough, that's where underscore really seems to be useful: "here
is a gap that isn't really a gap".
> > > 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.
>
> Space in filenames are just too useful, besides being completely legal,
> to disallow out of hand.
Space in a filenames are just too problematic to be considered useful.
The require Special Care to be taken.
(This is true of many other characters as well -- greater-than, less-than,
parens, ampersand, EOT, BEL, BS, HT, NL, CR... )
[snip]
> > 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.
>
> Agreed. This is why I don't install csh unless I absolutely have to.
Well, csh is an improvement (user-experience-wise) on sh.... I
should only think you'd ever want to install csh if your alternative
was sh. I don't install csh either -- I install tcsh; while zsh is
really cool and all, I still don't like the sh command-line feel.
[snip]
> It sounds like you want that control over others, too. Why else call
> such a practice evil, in an attempt to chastise someone into obedience?
It sounds like you want to control my choices, by dismissing out of hand
those things I consider evil.
[snip]
> > > 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.
>
> So is $a one token, or two?
Three.
[snip]
> > But quoting is annoying, and most folks get to a point pretty soon
> > that they find is best described as "quoting hell".
>
> Yep. This was brought on by treating variables with spaces as an array.
> The only shell I have seen to get this concept right is zsh. Having seen
> the right way, I find the wrong way to be very aggravating.
If you consider that the right way, yes.
args="$args -file $filename"
...
args="$args -option $option"
...
echo "program $subcommand $args"
program $subcommand $args
...this breaks, and hard, in zsh; this is not the expected behavior. It
violates the principle of least suprise. You look at the output of the
echo, and it looks fine; you copy-and-paste the output of the echo,
and it runs just fine*. But it fails to run under zsh.
I'm not really interested in discussing if this sort of option is
a suitable use, or if "real arrays" ought to be used instead; if I
need a 'real array' to get around a problem, I'm already out of the
domain of what a shell should do.
* Assuming no spaces, or args="-file '$filename' -options $option"...
[snip]
> > 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.
>
> Your system, your rules.
>
> Someone else's system, their rules.
That's what I said.
> Their rules are not evil. No matter what your personal opinions are.
Their rules imposed upon me most certainly are, no matter what your
personal opinions are.
--
_ |\_
\|
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
