Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!ames!elroy!cit-vax!catfish!fritz
From: fritz@catfish.caltech.edu (Fritz Nordby)
Newsgroups: comp.arch
Subject: Limits
Message-ID: <9365@cit-vax.Caltech.Edu>
Date: 1 Feb 89 15:47:24 GMT
References: <6133@columbia.edu> <5124@aldebaran.UUCP> <7@microsoft.UUCP> <213@nbires.nbi.com> <38@microsoft.UUCP>
Sender: news@cit-vax.Caltech.Edu
Reply-To: fritz@catfish.UUCP (Fritz Nordby)
Distribution: na
Organization: California Institute of Technology
Lines: 23

In article <38@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes:
>(Quick: who's run into Unix's 10K command-line limit?)

Me.  Often.  And probably other folks who've worked with large numbers of
source files.  Consider:

	$ pr `find . -type f -print|egrep '^([Mm]akefile|.*\.[ch])$'` | lpr

Another example: have you looked at looked at the way the "rcbook.t"
program (from the alt.gourmand recipes software) works?  It has to work
around this restriction.

BTW, the "10K command-line limit" is not exactly that; it's really a
"10 block command-line limit".  Yes, that's right, it used to be a 5K
limit in the days of 512 byte disk blocks, and on systems with 4K disk
blocks I rather suspect that it's a 40K limit.

Moral: A restriction is a restriction, and no matter how lax or trivial the
restriction may seem today, eventually somebody will run up hard against it.
(Anybody else remember when 64k was a lot of memory?  And now we're running
out of space with 32 bits?)

		Fritz Nordby.	fritz@vlsi.caltech.edu	cit-vax!cit-vlsi!fritz