Bill Hacker wbh at
Thu Feb 14 03:21:25 PST 2008

Rahul Siddharthan wrote:
Bill Hacker wrote:
That said, I remain surprised that others haven't already said, and
sooner, rather than later, words to the effect:
'Yes, historical reasons quite aside, these common and frequently needed
tools can too often be more arcane than they need to be'.
It always surprises me how much of the Unix Hater's Handbook remains
. .or gets worse as time passes..


For example, how do you use "find" to find all files in a directory
that end in ".el" and don't have a corresponding ".elc" file?  
 find . -name '*.el' -print  \
    |sed 's/^/FOO=/' \
    |sed 's/$/; if [ ! -f ${FOO}c ]; then echo $FOO; fi/'  \
    | sh

When I want to do something like that to a large directory, I generate
a full directory listing and then write a python program to parse it.
That seems easier to wrap my mind around.  (The author of the above
find command used emacs-lisp instead, then figured out the correct
find incantation because it bothered him.  "It only took me 12 tries
to get it right.  It only spawns two processes per file in the
directory tree we're iterating over.  It's the Unix Way!")
No doubt Simon or someone will now point out a trivial one-line
invocation of find that will do the job and will be obvious to anyone
who understands the find manpages.
The original concept of many, many small tools that did one thing well 
was not wrong for the resources of the day.

It isn't 'wrong' yet.

But it does seem to have taken on too much 'sacredness'.

Millions of folks use some of these legacy tools chained together - 
visibly or under the covers - so *often* that a few might better be 
identified and replaced, or at least 'paralleled', with bespoke 
monoliths that were safer by way of being less reliant on version/OS 
externals, and that might require fewer calls and context switches.

But all this belongs in a different forum than DragonFly kernel, so, 
time to at least make *that* change...



More information about the Kernel mailing list