Path: utzoo!attcan!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: grep replacement
Message-ID: <8080@brl-smoke.ARPA>
Date: 12 Jun 88 23:02:35 GMT
References: <144@insyte.UUCP> <3350@phri.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 29

In article <3350@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>Unless I'm misunderstanding jad, he's talking about fixed length records.

She was.

The important point is that UNIX text (line-oriented) tools typically
break miserably when lines containing more than 256 or 512 (sometimes
more) characters are encountered.  In many cases this is not a
necessary feature but was due to quick-and-dirty implementation.
It IS more work to read in an arbitrarily long line, but once you
write your getline() function you could add it to the local library
and then it would be easy to do in the future.

I seem to recall that Lindemann fixed this problem in "sort" for SVR2.

>Also, I agree with whoever said that taking context diffs out of
>diff is a bad idea.

Removing the ability to get context diffs when they are wanted WOULD
be a bad idea.  Removing this feature from "diff" itself is not a
bad idea; I hate for "diff" to do extra work every time I run it when
I virtually never use the context feature.  Consider
	diff a b | diffc a b
where "diffc" reads the "diff" information in parallel with the two
files "a" and "b" to produce the context-diff output.  By separating
the two functions, it is not only likely to speed up non-context use
of "diff" but also it is more likely to get the answer right, and it
is easier to work on improving "diffc".  (Existing context diff output
is sometimes pretty horrible, for example larger than the inputs.)