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 ;>

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 . . .

> > 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 ;>

>   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 . . .

> > 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.

> > 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 ;>

> 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 ???

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 . . .

-- 

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 . . .

Reply via email to