sja@ih1ap.UUCP (Steve Alesch) (09/11/86)
In article <1273@ihlpl.UUCP>, psfales@ihlpl.UUCP (Peter Fales) writes: > > > > THIS PROGRAM FINDS LARGE FILES IN A GIVEN (BSD) FILE SYSTEM > > =========================================================== > > ... > I don't know about BSD, but I use the following command on my 3b2 > (System V) for clearing out big files on the disk: > > find / -size +nnn -print > > Where nnn is the cutoff point in blocks (512 byte blocks). To better > simulate the fsls command describe above, one could type > > 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 Sorry, but this is one of my pet peeves. -- Steve Alesch AT&T (312)510-7881, ...!ihnp4!ih1ap!sja
phaedrus@eneevax.UUCP (Praveen Kumar) (09/13/86)
>>From: sja@ih1ap.UUCP (Steve Alesch) >> > THIS PROGRAM FINDS LARGE FILES IN A GIVEN (BSD) FILE SYSTEM >> > =========================================================== >> > >... >> I don't know about BSD, but I use the following command on my 3b2 >> (System V) for clearing out big files on the disk: >> >> find / -size +nnn -print >> >> Where nnn is the cutoff point in blocks (512 byte blocks). To better >> simulate the fsls command describe above, one could type >> >> 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 > >Sorry, but this is one of my pet peeves. >-- > >Steve Alesch AT&T >(312)510-7881, ...!ihnp4!ih1ap!sja > > Well, xargs doesn't exist in the BSD universe. I looked for it on our Pyramid and our Vax 785 running 4.3 - it wasn't on either. However, our Masscomp (which is a dual universe machine) does have it. pk -- "Everybody wants a piece of pie, today," he said. "You gotta watch the ones who always keep their hands clean." phaedrus@eneevax.umd.edu or {seismo,allegra}!umcp-cs!eneevax!phaedrus
mwm@eris.berkeley.edu (Mike Meyer) (09/14/86)
In article <573@ih1ap.UUCP> sja@ih1ap.UUCP (Steve Alesch) 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 > >Sorry, but this is one of my pet peeves. 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` Which shell facility is, of course, why I thought xargs-like things died after v6... <mike
jrw@hropus.UUCP (Jim Webb) (09/15/86)
> In article <573@ih1ap.UUCP> sja@ih1ap.UUCP (Steve Alesch) 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 > > > >Sorry, but this is one of my pet peeves. > > 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` > > Which shell facility is, of course, why I thought xargs-like things > died after v6... > AAAARRRRGGGGHHHH!!!! What happens, if, pray tell, the find finds more that 5120 chars worth of file names???? The shell prints an error about the arg list too long! _This_ is why xargs came about... -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw
jimb@amdcad.UUCP (Jim Budler) (09/16/86)
In article <168@eneevax.UUCP> phaedrus@eneevax.UUCP (Praveen Kumar) writes: >>>From: sja@ih1ap.UUCP (Steve Alesch) >>> > THIS PROGRAM FINDS LARGE FILES IN A GIVEN (BSD) FILE SYSTEM >>> > =========================================================== >>> > >>... >>> I don't know about BSD, but I use the following command on my 3b2 >>> (System V) for clearing out big files on the disk: >>> >>> find / -size +nnn -print >>> >>> Where nnn is the cutoff point in blocks (512 byte blocks). To better >>> simulate the fsls command describe above, one could type >>> >>> 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 >> >>Sorry, but this is one of my pet peeves. >>-- >> >>Steve Alesch AT&T >>(312)510-7881, ...!ihnp4!ih1ap!sja >> >> > >Well, xargs doesn't exist in the BSD universe. I looked for it on >our Pyramid and our Vax 785 running 4.3 - it wasn't on either. However, >our Masscomp (which is a dual universe machine) does have it. > >pk phaedrus@eneevax.umd.edu or {seismo,allegra}!umcp-cs!eneevax!phaedrus For your information, the header from the public domain reimplementation of xargs: +--------------- | From decwrl!decvax!genrad!panda!sources-request Thu Feb 20 17:45:44 PST 1986 | | Mod.sources: Volume 3, Issue 106 | Submitted by: seismo!amdahl!gam (Gordon A. Moffett) | | Here is a reimplementation of the System V utility xargs. I haven't | heard any complaints about it, though [1] There is room for improvement | regarding the command buffer size (tho' it is better than the System V | area in that particular regard) [2] It does not have all the features | of the System V version (as the man page points out). | | Gordon A. Moffett | {ihnp4,seismo,hplabs}!amdahl!gam | +--------------- -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200 I got tired of my old signature.
jason@hpcnoe.UUCP (Jason Zions) (09/16/86)
> >> > >> 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... -- This is not an official statement of Hewlett-Packard Corp., and does not necessarily reflect the views of HP. It is provided completely without warranty of any kind. Lawyers take 3d10 damage and roll a saving throw vs. ego attack. Jason Zions Hewlett-Packard Colorado Networks Division 3404 E. Harmony Road Mail Stop 102 Ft. Collins, CO 80525 {ihnp4,seismo,hplabs,gatech}!hpfcdc!hpcnoe!jason or jason@hpcnoe.fc.hp.com
sja@ih1ap.UUCP (Steve Alesch) (09/16/86)
In article <1271@jade.BERKELEY.EDU>, mwm@eris.berkeley.edu (Mike Meyer) writes: > In article <573@ih1ap.UUCP> sja@ih1ap.UUCP (Steve Alesch) 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 > > > >Sorry, but this is one of my pet peeves. > > 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` > > Which shell facility is, of course, why I thought xargs-like things > died after v6... > > <mike Command substitution is fine except when the output of the command substitution exceeds the shell environment limit. This is xargs(1) reason for living. Have other UNIX(TM) flavors solved this problem in some other fashion? I find it hard to believe that they have limitless environment sizes? -- Steve Alesch AT&T (312)510-7881, ...!ihnp4!ih1ap!sja
jpn@teddy.UUCP (John P. Nelson) (09/17/86)
>Well, xargs doesn't exist in the BSD universe. I looked for it on >our Pyramid and our Vax 785 running 4.3 - it wasn't on either. However, >our Masscomp (which is a dual universe machine) does have it. A public domain version was posted to mod.sources. Contact mirror!rs if you need more information. .
jerryp@tektools.UUCP (Jerry Peek) (09/17/86)
In article <1271@jade.BERKELEY.EDU> mwm@eris.UUCP (Mike Meyer) writes: > 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` > > Which shell facility is, of course, why I thought xargs-like things > died after v6... [I never used v6...] The problem here comes when "find" prints so many arguments, and/or such long pathnames, that "ls" can't handle all of them at once. "xargs" handles this: find / +nnn -print | xargs ls -l nicely by collecting a certain amount of text, running "ls -l" for that text, then collecting some more text, doing another "ls -l", etc. until "find" shuts up. (It's also possible to specify how much text "xargs" should collect from "find" in each gulp.) --Jerry Peek, Tektronix, Inc. US Mail: MS 74-900, P.O. Box 500, Beaverton, OR 97077 uucp: {allegra,decvax,hplabs,ihnp4,ucbvax}!tektronix!tektools!jerryp CS,ARPAnet: jerryp%tektools@tektronix.csnet Phone: +1 503 627-1603
dmt@ptsfa.UUCP (Dave Turner) (09/19/86)
In article <1559@tektools.UUCP> jerryp@tektools.UUCP (Jerry Peek) writes: > find / +nnn -print | xargs ls -l I hate to nitpick but if you use the xargs version you'd better use ls -ld so you don't list every directory twice: find / +nnn -print | xargs ls -ld -- Dave Turner 415/542-1299 {ihnp4,lll-crg,qantel,pyramid}!ptsfa!dmt
gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/21/86)
In article <1271@jade.BERKELEY.EDU> mwm@eris.UUCP (Mike Meyer) writes:
-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`
-
-Which shell facility is, of course, why I thought xargs-like things
-died after v6...
The reason "xargs" lives is that there is a limit to the total number
of bytes allowed in the arguments to a command.wedgingt@udenva.UUCP (Will Edgington/Ejeo) (09/24/86)
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 )
chris@umcp-cs.UUCP (Chris Torek) (10/07/86)
In article <3951@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) writes: >The reason "xargs" lives is that there is a limit to the total number >of bytes allowed in the arguments to a command. So fix *that*. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu