On Monday, Dec 22nd 2003 at 10:58 -0500, quoth Jake McHenry:Going back even further -- and showing my age I guess -- the limit under Edition 7 (and probably Edition 6) was 10k. Not a lot, but given the machines of the time it was _very_ difficult to blow that limit. When BSD came along, the limit was doubled(!) to 20k and while it wasn't easy to blow _that_ limit it was possible on the larger VAXs with the a collection of huge disks -- I think we had a couple of Gig on our main VAX server when I was at DEC. Anyway, BSD introduced xargs which was useful for those large machines. The macro on all these machines was MAXARGS (I'm fairly sure, though not certain).
=>This works without any problems so far, just ran a query with 2354 =>args.. So I'm not sure where the 1024 arg limit idea came from.
I just thought I'd throw my $.02 in here on a small history lesson. Back as recently as SCO SVR3.2 days, there was a symbol in /usr/include somewhere (maybe it was called MAX_CMD or MAX_CMDBUF or something like that). It was the actual byte count of the total that the command line was allowed to be combined with the length of your total environment. This was a big deal because if you defined a dozen or so environment variables, you'd still end up with a substantial environmnet just from the contribution of running X. The number was (if I recall correctly) 5K. So really not a lot of room to play with. Back then we *all* knew how to use things like find and xargs to best advantage. Then when Solaris went with SVR4 and other SVR4 releases happened, all those kernel parameterizations that were static went dynamic. Under Solaris, I beieve you are allowed to have cmd lines that go up to a gig (not that you'd ever want to). I don't know what the limits are under Linux but I do know that we're not constricted to anything unreasonable these days.
Unlike Solaris, Linux still has a relatively small limit for the maximum argument size: it's 32 pages (MAX_ARG_PAGES in <linux/binfmt.h>) which gives a MAXARGS equivalent of 128k with a 4k page size, it says. You'd think it would be hard to blow that under normal circumstances but "find * /name '*.[ch]'" in the 2.6 kernel source tree is almost 400k.
jch
-- Shrike-list mailing list Shrike-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/shrike-list
