Re: How to handle whitespace in filenames ???
"Michael D. Schleif" wrote:
>
> Erik Steffl wrote:
> >
> > "Michael D. Schleif" wrote:
> > >
> > > More and more, *nix developers are following the dark path of using
> > > whitespace in directory and filenames -- something which I've always
> > > detested, from an sa standpoint ;<
> >
> > well, it's a valid character, why shouldn't it be there? IMO the
> > situation where users are limited by arbitrarily limited tools is best
> > left for win world.
>
> Actually, there are many ``valid'' characters ;>
of course. all except \0 and / are valid filename characters...
> Nevertheless, there will always be reasons to exclude certain characters
> from special purposes, such as directory and filenames -- and, I'm not
> limiting this to ASCII, nor referring exclusively to utf8 ;>
>
> How would you like to handle 0x08, 0x0a or 0x0d ??? Remember, we are
> talking about text handling here, not binaries . . .
that depends on what you mean by handling. in general, just like
space. some of them are harder to type, usually \nnn works (or one of \x
sequences), or use command line completion etc... it gets more
complicated when the characters used are not visible...
I don't see why text handling and binary handling should be any
different (dark side again: it's windows that has different open mode
for text and binary, in unix it's all the same). some tools do not work
that well with files that contain other characters then printable ascii,
but again, those should be fixed...
> > > For example, on my upgraded potato box I may want to do something this
> > > simple:
> > >
> > > grep pump `find /etc/ -type f`
> >
> > grep rock "`find . -type f`"
>
> Please, test your example prior to posting and you will save yourself
> considerable embarrassment ;>
? I did test it and it works:
panther:~/work/pokusy>grep rock "`find . -type f`"
./otlPokus/example2.1.C: " 'rock and roll',"
./main::var/main.pl:# my($var) = 'rock and roll';
./main::var/main.pl:$rrr = 'rock and roll';
./forStar/rrrA.log:rock and roll!
./forStar/rrrB.log:rock and roll!
./forStar/VerioParser.d/VerioParser_d2001etxc.log.20010920.173501:rock
on!
./rrr 1:rock
using tcsh. doesn't work in ksh or bash.
> > or use print0 option with xargs -0 (already suggested in another
> > post).
>
> This is overkill, since -exec is simpler and supported across even
> ancient find versions . . .
print0&0 works with various weird characters (AFAIK, not going to test
it), you are right about portability though... then again, maybe -exec
does work ok with various weird characters as well, I am not sure. at
least you know that it's possible...
> > > Normally, this is a quick and effective search and I am satisfied and
> > > can get on with other business.
> >
> > well, it's quick and dirty because it only works with filenames that
> > are fairly limited.
>
> All tools are limited -- without exception! Whitespace makes all
> directories and filenames more difficult to parse -- both reading by
> human eye and manipulating with ``limited'' tools. Simply because a
> color is available in a palette doesn't mean the painter must use it --
> anymore than I want to start naming my files ..., ...., ....., &c.
the point is that you can. you don't have to. and since you can, the
tools should support it, if they don't they should be ported to the dark
side a left there. not gonna happen but I can at least dream...
>
> > > However, now we have abominations, like these:
> > >
> > > /etc/X11/afterstep/hookdir/Debian/Apps/Net/Netscape/Communicator(static
> > > 4.77) Browser
> > > /etc/X11/afterstep/hookdir/Debian/WindowManagers/Window Maker
> > > /etc/kde2/colors/40 Colors
> > >
> > > Even this, obviously, is *not* an answer:
> > >
> > > grep pump `find /etc/ -type f |\
> > > sed 's! !\\ !g; s!^!"!; s!$!"!'`
> > >
> > > How do others handle this?
> > >
> > > What do you think?
> >
> > generally, filename should be allowed to be basically any text. I see
> > no reason to limit it (well, the general consesnsus among most of the
> > unix(-like) implementations is that you cannot include '\0' and '/').
>
> Fortunately, you are astute enough to recognize some limitations to the
> paradigm. There are several others ;>
no there are not. you can impose those on yourself if you want certain
level of convenience (e.g. just doing grep rrr * instead of wondering
about how to quote it) but in general users can create filenames with
any other characters...
> > And I see no reason to put limits on this because of inadequate tools...
> > it's the tools that need to be fixed, not filenames.
>
> Actually, as users of complex systems, that is enough reason for me.
> Why should we impose untenable complexity on users if the tools that
> they need to use are inadequate to the task? Perhaps, you ought to
> ``correct'' the tools, then impose arbitrary complexity ???
well, yes. the tools should be fixed. they will not be, if for no
other reason that there's huge number of legacy systems that are not
going to be updated (significantly) for years to come...
> In the meantime, I have to use the system. Convenience and efficiency
> are important features to me. Yes, I have found a solution in -exec --
> it is simple and efficient; but, I need test it for the general case.
> Thank you, for your consideration . . .
erik
Reply to: