Endian wars - really 386 questi

[William E. Davidsen Jr]

In article <7877 at boring.cwi.nl> dik at cwi.nl (Dik T. Winter) writes:
| In article <24318 at amdcad.AMD.COM> rpw3 at amdcad.UUCP (Rob Warnock) writes:
|  > ... With "xargs", that 10k limit
|  > becomes a non-issue. Instead of, for example:
|  > 
|  > 	$ some_cmd -options `find <selection> -print`
|  > try:
|  > 	$ find <selection> -print | xargs some_cmd -options
|  > 
| But of course the two are equivalent only if "some_cmd -options" uses only
| one input file at a time.  Try:
| 	cc -o aap `find <selection> -print`
| And if they are equivalent you could already do:
| 	find <selection> -exec some_cmd -options {} \;
| (although you have a lot more processes).

  Do you understand how xargs works? xargs starts the process with all
of the arguments which will fit one one command line (unless limited to
fewer by options). There is no requirement that only one file at a time
be used.

  In the case where not all the arguemnts will fit on one line, such as
I assume you show above, neither xargs, `embedded commands` or $(ksh
style commands) will do. Then you grit your teeth and write some ugly
thing like:

	find {selection} -print | echo |
	while read proglist
	do
	  cc -c -o $proglist
	  ar r mylib.a *.o
	  rm *.o
	done &&
	cc -o aap mylib.a

  I would be the first to agree that this is ugly, and since I typed it
by hand without checking it may have some typo. The idea is there,
however, that there is no real magic solution to the line length
problem.

  I'd love to have someone say "no, you dummy, here's how to get 90k
command lines..."
-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me