Stewart Stremler wrote: > 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.
Should, yes. However, the original designers of the UFS filesystem used null terminated strings. Go bug them, not me. > > > > 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. Exactly. All interfaces give some tokens meaning, and not others. Try 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. > Why is this a good thing? You are the one trying to add in additional characters _with no good technical reason_. 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. 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. % touch ca^Hot % ls cot % echo * cot % rm cot rm: cannot remove `cot': No such file or directory % ls -b ca\010ot However, newlines and backspaces are not nearly as common in filenames as spaces are. > Your argument seems to be that limitations are bad Then you did not pay attention. Message-ID: <[EMAIL PROTECTED]> Artificial limitations are eviler. There is no reason, outside personal preference, to exclude spaces, hence it is an artificial limitation. > -- so null and slash ought to be allowed. 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. > 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. 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. > [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. Please note that is not what I said. No reason that a filename has to be one word. What is your name, again? I believe there at least three tokens in it. We are used to dealing with multiple tokens in a name. No reason to exclude filenames from such a useful convention. > [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. Space in filenames are just too useful, besides being completely legal, to disallow out of hand. > > 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. Agreed. This is why I don't install csh unless I absolutely have to. > 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. 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? > > I don't see a problem with / instead of - for options. > > COMMAND/OPT/FFILENAME/SUB/BLAH/BLAH > > Nice and easy to read, no? According to one anecdote I have heard, it does not take to long to learn to read that. > > 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? --snip of quoting example-- > Quoting does help, if you quote the right piece. Of course. > 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. Still, I write shell scripts to be sh compatible, if at all possible. % a=(1 two three "four (4)" five\ -\ 5) % for i in $a; do echo $i; done 1 two three four (4) five - 5 > Finding the right places to quote is typically a trial-and-error > process until you find the trick that works. Yep. Look at the difference between "$*" and "$@" sometime. > 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. Their rules are not evil. No matter what your personal opinions are. (provided we stick with filenaming conventions - I am not going to go into the contents, use, or intention of the files, the filenames, or the operator) -john -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
