"Michael D. Schleif" wrote: > > Craig Dickson wrote: ... > > 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
why not? just do it in sane manner: the power button should cause shutdown. > 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. during discussion it became clear that it's not really a discussion about spaces in filenames. it's a discussion about how the shell handles special characters in literal strings and variables. the filenames as well as all other values are affected. and you cannot forbid usage of spaces (and other special characters) in all the shell variables/strings. while your example used filenames you will encounter same problems in other situations, e.g. observe the difference: panther:~...pokusy/space>cat namelist Jack Secondname Other Name Jack Again panther:~...pokusy/space>grep ^Jack namelist | xargs -l1 -i{} ./listArgs {} listArgs called with following arguments: 0: <./listArgs> 1: <Jack Secondname> listArgs called with following arguments: 0: <./listArgs> 1: <Jack Again> panther:~...pokusy/space>grep ^Jack namelist | xargs -l1 ./listArgs listArgs called with following arguments: 0: <./listArgs> 1: <Jack> 2: <Secondname> listArgs called with following arguments: 0: <./listArgs> 1: <Jack> 2: <Again> so if you'd want the name to be processed as one argument (e.g. searching for a name) you'd have to use {}, just like you would have to do the same when those strings happen to be filenames. so talking about how filenames should not contain spaces makes no sense, if you want no spaces then there should be no space anywhere... ... > 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. after having so much experience one should get accustomed to treat any strings as arbitrary text, see example above. and yes, I worked as sysadmin for few years... I see no reason to harass users about which particular characters they should use, instead I learned how the shell works... it's really not that hard to use the {} as above or -print0 & -0 (if gnu utilities are available) etc. and again: it's not about filenames only, it's about any strings (literal or variables) that you use in shell. ... > 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? that's the same what all shells and all the file managers on unix systems do. and shells, of course, do a lot more complicated processing before actually letting go (interpolate variables, possibly execute other programs (if `` are used) etc.). and again - it does not matter if it's a filename or not, all the strings are processed the same way, shell doesn't even know it's a filename... ... > > 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 but there are also several short & simple ways. > 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 . . . I doubt that it's more efficient. btw if you're interested in efficiency (as in getting response faster) you'd better use locate for this purpose (it's not the same as find but it's fairly good replacement for find / -name xxx) erik