🚀 go-pugleaf

I have cross-posted this to net.unix, as that's really where this belongs now.

In article <1620002@hpcnoe.UUCP> jason@hpcnoe.UUCP (Jason Zions) writes:
>> >> find / -size +nnn -exec ls -l {} \;
>> >
>> >You can bury the machine this way!!!!  It's incredibly more efficient
>> >using xargs(1) instead.
>> >
>> >	find / -size +nnn -print | xargs ls -l
>> 
>> And for those of you who don't have xargs (I thought such creatures
>> died after v6!), you can do:
>> 
>> 	ls -l `find / +nnn -print`
>
>What happend if the find produces more characters than can fit in a command
>line? Things don't work so well, the shell moans about "command line too long"
>or "too many arguments" or some such mumble. That's why xargs still exists in
>System V (well, at least HP-UX, HP's implementation of System V); it uses the
>smallest number of command invocations to get them all done.
>
>It's amazing how much faster shell scripts run using xargs (as opposed to
>-exec cmd {} \; in a find command); my disk drive doesn't walk across the room
>from all the fork/execs...

  If I remember right, the original discussion was trying to find the huge
(10 megabyte plus) file that just swallowed your disk.  I doubt there's more
than one; the first solution above will therefore be *faster* than using xargs
or command substitution (`command`), and it will print it out RIGHT WHEN IT'S
FOUND.  After the one ls that needed to be forked prints it, you can interrupt
the find and remove the offending file.  Command substitution won't even start
the ls until after the find has EXITED; xargs will only start the ls after
it's filled a command line or find has exited.  When you're looking for one
file, it had better not fill a command line, or you're in trouble (though I
had a student consultant start an infinite 'mkdir dir; cd dir' loop on a 2.9
BSD system once ...  the unlink call tries to trace it all the way back to
the root of the file system and fails; you have to clear the top inode ...) ...
  Now, if you're trying to find and remove the thousands of files someone
created that left your inode table empty ....  But that's never happened on
any of the systems here, despite the "know-it-all-but-let's-experiment"
student consultants we have (I know; I started as one :-).
-- 
------------------------------------------------------------------------
|"Input!"|"Number 5 is Alive!!"|"Beautiful software"|"Not disassemble!!"
------------------------------------------------------------------------
Will Edgington|Computing and Information Resources, University of Denver
(303) 871-2081|BusAd 469, 2020 S. Race, Denver CO 80208 (work)|"Input!!"
(303) 759-9071|5001 E. Iliff, Denver CO 80222 (home)|"Where's Input?!!?"
{{hplabs,seismo}!hao,ucbvax!nbires,boulder,cires,cisden}!udenva!wedgingt
COMING SOON: wedgingt@eos.cair.du.edu, wedgingt@eos.BITNET ( == udenva )