Craig Dickson wrote: > > Michael D. Schleif wrote: > > > Craig Dickson wrote: > > > > > Michael D. Schleif wrote: > > > > > > > How would you like to handle 0x08, 0x0a or 0x0d ??? Remember, we are > > > > talking about text handling here, not binaries . . . > > > > > > We can sensibly limit ourselves to printable characters for filenames; > > > it's silly to suggest that if you let people use spaces, next they'll > > > want control characters. > > > > How so? My reply is in response to this: ``well, it's a valid > > character, why shouldn't it be there?'' > > Because you're not thinking in terms of what users realistically will > want to do. Why would anyone WANT to put a backspace into a filename? A > space is a printable character that serves a purpose in written text, to > separate words from one another, so a filename like "Letter to Joe.doc" > is meaningful, and is easier to read than LetterToJoe.doc. A backspace, > or other control character, makes no sense, and it wouldn't bother me in > the least if the filesystem simply didn't accept them. But spaces are > meaningful to people, and should be allowed and properly supported by > the shell and other standard tools.
Yes, I can understand reasons to want to use whitespace in directory and filenames. I can also understand reasons for users wanting to power OFF their computers instead of shutting down the os first. In my opinion, humble or not, neither of these desires ought to be encouraged. Is this clear enough? Notice, I am *NOT* saying that there are no valid reasons for using whitespace in this manner; rather, I am saying, based on _decades_ of using and maintaining computing devices, such use is counter-productive. This negative side, imo, outweighs any emotional value -- period. Funny, you not only twist my words; but, you still will not take literally your own words, ``well, it's a valid character, why shouldn't it be there?'' Did you mean something other than what your wrote? How can I know that, unless you amend your written words? > Of course, if you want to admit that MacOS and Win32 can do something > better than Unix can -- which is the obvious implication of a lot of > what you've said on this subject --, be my guest. Actually, if you read my words and do not try to interpret them in any non-literal fashion, you know that I am saying quite the opposite! > > Simply because something can be done does not warrant doing it . . . > > True, but in this case there's no sensible reason not to other than > backwards-compatibility. As you know, I have provided *SEVERAL* sensible reasons. Perhaps, you ought to work as a system administrator in charge of dozens, no, hundreds of computers, servers, networks, &c. Then, after a year of that, come on back and talk to me about ``practical desires'' of typical computer users. As you know, too, my original post stated, ``something which I've always detested, from an sa standpoint ;<'' If you bother to read the words that I post, you will find that each and every one of them conveys meaning . . . > I'm not really arguing in favor of changing all > the thousands of Unix tools in the world to handle filenames with > spaces. For that matter, most of them handle such filenames fine under > limited circumstances, and it isn't that hard to write a shell script > that will do so. My specific point was that the standard Unix shells, by > default, expand variables in a way that causes a number of problems, > filenames with spaces being only one example. > > > > There is a good reason to support spaces if you want your OS to appeal > > > to ex-Windows or ex-Mac users, who are used to creating filenames like > > > "Letter to Joe.doc" or "Smith Family Budget.xls". > > > > I'll leave that debate for others -- nevertheless, this is one > > remarkable reason that windoze file handling is so weak ;> > > Windows is defective in many ways, but the use of spaces in filenames > has nothing to do with any of them. That has to be the lamest straw man > argument I've ever come across; it amounts to nothing more than poking > fun at something that's unpopular with the crowd you're playing to, > without regard for truth or fairness. Actually, when you look at the code for windoze exploder, you will see what I mean. The code is slow and inefficient, because -- partially, to a degree, somewhat, not wholly -- of all the crazy notions they try to implement, such as included whitespace and backslashes (\) -- what is the escape character in windoze? Of course, if you don't bother to look, then you do not know wherefrom you speak . . . > > Besides, my point, as stated previously, is this, "Perhaps, you ought to > > ``correct'' the tools, then impose arbitrary complexity ???" > > > > Please, do not put the cart before the horse . . . > > You either haven't been reading very carefully, or aren't sufficiently > informed to have a sensible opinion, to judge by what you've said so > far. This "arbitrary complexity" thing is total nonsense. Is it really? Perhaps, someday you will bother to support that hypothesis ??? > To be specific, I've suggested that things would be better today if one > aspect of the Bourne shell had been designed better, namely how it > treats the expansion of variables whose values contain embedded spaces. > Right now, after the assignment A="foo bar", the expansion of $A is > interpreted by the shell and all Unix tools as two separate strings, foo > and bar, rather than the single string "foo bar", as it was originally > given (with quotes). This default behavior breaks filenames with spaces > (you have to remember to specify "$A", in quotes, to preserve the string > properly), and allows for a number of other problems as well, such as > the well-known security problems that can arise when setuid or cgi > scripts expand variables whose values were originally read from user > input. Again, have you ever heard of $IFS? There are reasons that these things are put together the way that they are. Yes, prior to my post, I knew several overly long, programmatic ways to approach my particular problem. Over many years, somehow I've gotten away from using find with -exec, forgetting this simple little advantage. Nevertheless, my repertoire includes many optimizations and odd efficiencies that make my day-to-day tasks easier than they were in previous years. Little things, like never using find with -name, because that code is so much slower and more inefficient than: find / | grep something . . . > It would have been better for the default expansion of a quoted string > to include the quotes, precisely to preserve strings with embedded > spaces. There could have been some trivial syntax to cause such strings > to be broken up, such as when you use a variable to store a list of > space-delimited strings. It wouldn't have been a major change, and it > would have been better. In your opinion -- not in mine nor millions of others. If I am to guess, I'd say that you come from a shell-less environment, like windoze. As a long-time shell programer, I much prefer to be able to program from the cli. Even on windoze, I spend more time at the cli than the gui -- and I am very productive. If you prefer the gui, go there, stay there and do not worry yourself about what goes on under the hood that makes that gui possible; but, do not delude yourself that the gui is efficient nor optimal, in terms of getting things done with minimal overhead. That cannot ever be true! > There are also minor implications for other tools here; for example, > 'ls' and 'find' should be able to quote filenames with embedded spaces > in their output, to allow them to be parsed correctly. But this is still > a minor shift, and had it been made early enough in Unix's history, it > would have been a small thing, and overall an improvement. I don't think > it can happen now, at least not in the context of the sh-derived shells > and the traditional Unix tools; you'd break too many things. If someone > wants to design a new shell from the ground up, and get this right, it > would be nice. Actually, there is this thing called open source. The tools that you mention happen to have their source code open to all -- even you. Adding those features that you mention above is *NOT* likely to break any canonical use of these tools. So, I ask myself, that being the case, why hasn't some wizard, as you purport to be, used that great wisdom, hacked the code and become the hero of all *nix-dom? Give it a shot -- how difficult can it be? If I wanted that functionality, that's where I'd go; rather than belly-aching about its absence here . . . > > > Unfortuantely, since spaces in filenames have never been a priority for > > > Unix users, most Unix tools behave counter-intuitively (from the > > > perspective of someone new to the system) when confronted with such > > > things. > > > > In general, your examples are very weak. Are you familiar with $IFS and > > its ilk? > > Sure. But there's absolutely no need to alter the basic token-parsing in > the shell; it already understands strings with spaces as long as they're > quoted. All that's necessary is that the expansion of variables > containing such strings retain the quotes. It shouldn't be necessary to > alter IFS just to get reasonable behavior out of the shell. As easy as that sounds, I anxiously await the publication of your new versions to the most used cli tools in the world !?!? At any rate, I grow bored with this diatribe. You have your opinion and I mine. Notice, that in a free country, I have a right to my opinion -- I can only hope that the words that I publish, describing said opinion, are read in their entirety and that nobody tries to make them mean something other than the words that I string together in, ostensibly, meaningful sentences and paragraphs. Do have a happy holiday and a hearty rest of you life . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . .
