Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles; site uokvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!inuxc!pur-ee!uiucdcs!uokvax!jab
From: jab@uokvax.UUCP
Newsgroups: net.unix
Subject: Re: Re: tar .vs. cpio - (nf) - Re: excee - (nf)
Message-ID: <6100040@uokvax.UUCP>
Date: Wed, 22-Aug-84 23:18:00 EDT
Article-I.D.: uokvax.6100040
Posted: Wed Aug 22 23:18:00 1984
Date-Received: Sat, 25-Aug-84 06:13:24 EDT
References: <372@ihuxu.UUCP>
Lines: 22
Nf-ID: #R:ihuxu:-37200:uokvax:6100040:000:824
Nf-From: uokvax!jab    Aug 22 22:18:00 1984

#R:ihuxu:-37200:uokvax:6100040:000:824
uokvax!jab    Aug 22 22:18:00 1984

/***** uokvax:net.unix / ihuxu!jhall / 12:56 pm  Aug 14, 1984 */

If Berkeley UNIX has the xargs command, I believe you could use the
following technique to avoid exceeding the MAXARGS parameter (usually
10 blocks default):
--John R. Hall, ...ihnp4!ihuxu!jhall "And may your days be celebrations"
/* ---------- */

Umm, I had the understanding that MAXARGS/NCARGS was the number of bytes passed
as arguments from one program to the program it was exec'ing. The code
in the exec(2) system call allocates only so much space for the arguments
when it begins to fabricate the running program, and it's quite unwilling
to let you pass MORE than those numbers.

xargs(1) is only a program --- it still runs the command in question using
the exec(2) system call, and is still stuck with those constraints.

	Jeff Bowles
	LIsle, IL