Re: splitting util-linux (was: kill)

[Evan Hunt <ethanol@armory.com>]

>  Yes, the definition of "look" is pretty exact. Who do you think that
>  the tool should be work with any other type of files or with
>  a different ordering ? Now, it seems like right tool for right job.

It works well for looking up words in a dictionary file.  It doesn't work
very well for looking up lines in a flat-file database.

Consider a flat file like the following, each line containing a name,
a serial number, and some additional information.  Each time a new
transaction comes in, the serial number is incremented and a record
is added to the end of the file:

John:White:1:...
Mary:Brown:2:...
Fred:Green:3:...

...and so on.  Now, if that file grows very large, it would be useful to
be able to rapidly search it based on the serial number, e.g., something
like this:

$ search -n -t: -k3 97273 <filename>

Right now, the closest you can get to this with a standard unix or linux
tool is to use "look", but that only works if the serial number is the
first field of the file... and even then it doesn't work very well, because
the file has to be lexically sorted, so the serial numbers would all have
to be padded to the same length with leading zeroes.  It's faster than
using awk or grep, but it's a hassle.

I must have written a dozen shell scripts over the years that would have
been faster and easier to write if a tool like this had existed, and I
can't be the only one...

So I've finally gotten around to writing such a tool, and I'm calling
it "search" or "bs" (for "binary search") or something along those lines.
But I figured, well, it's almost identical to "look" when called without
arguments, so why not just supplant the existing "look"?  If it's invoked
as "look <word>", then it looks up the word in /usr/share/dict/words; if
it's invoked as "search -args <word> <filename>" then it's a general-
purpose binary search tool.

I'm still playing with it, but I plan to have it ready to contribute in
another few days.

Evan Hunt