Re: How to handle whitespace in filenames ???
"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
Reply to: