On Thu, Jul 14, 2005 at 09:12:45AM -0700, Paul Eggert wrote: > James Youngman <[EMAIL PROTECTED]> writes: > > > If there is a consensus to add this, I'd have a preference for a usage > > pattern which is consistent with look(1). > > I like the idea of implementing "look" in coreutils, and doing it > "right". "look" was in Unix Version 7, and it is a handy utility.
Agree. > The flags for look(1) (as specified on > <http://www.freebsd.org/cgi/man.cgi>) are subtly different from those > of "sort". One other problem worth noting: my Debian GNU/Linux 3.1 > r0a look(1) has a flag "-b" whose meaning is not clear to me (and it's > not in FreeBSD). I've just read the Debian code. The program mmap()s the entire file as MAP_SHARED either way. If -b is not specified, every line of the file is examined for a potential match. On the other hand, if -b was specified a binary search is performed. Hence there is a time difference for sorted files (x3 for /usr/share/dict/words on my system when the data is cached), but for unsorted files, "look" will still work while "look -b" probably won't. > I'd prefer that coreutils "look" have long options that are consistent > with "sort", even if its short options are different for historical > reasons. A small number (--check, --unique, --reverse, --merge) probably wouldn't make sence, but I see the sense of the idea. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils