🚀 go-pugleaf

In article <87774@tut.cis.ohio-state.edu> Bob Manson <manson@cis.ohio-state.edu> writes:
>Hmmm...Lets see what dies on an 13K input line. (Sun SLC+ running
>SunOS 4.1.) Well, tr was happy to convert the spaces into newlines,
>and I don't see much reason to go further, as the output of that could
>be postprocessed as I wished. (Yes, most unix utilities puke badly on
>input lines > 2K.

On kithrup (an SCO SysVr3.2v2 system), tr, grep, and wc all dealt nicely
with a 120k line.  (/etc/termcap is useful for such things 8-).)  I was
actually quite impressed.

>>I give source.  In fact, one reason I like code which prints messages
>>like "change XYZ and recompile me please" is to discourage bozos from
>>doing any god damned binary-only distributions of *my* source.
>Hasn't stopped HP or AT&T from distributing code with similar limits.
>Won't stop anyone else either. 

Just a note here.  SCO's version of yacc has some semi-fixed limits.  If it
runs out of space for some of the tables, it complains, and says to rerun it
with a different option.  The actual message is something like:

	Out of <whatever> space.  Run with -Sm# option (current
	setting 5000).

(That's how I got perl working.)  Although that's not the best solution (for
example, it could be argued that yacc should realloc() up the space itself),
it *does* manage what I consider a decent compromise between static space
and run-time limitations.

Anyway, just my two cents...

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.