Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!eda.com!jim From: jim@eda.com (Jim Budler) Newsgroups: alt.sources.d Subject: Re: promoting Perl (was Re: uutraffic report (in perl)) Message-ID: <1989Nov30.073304.15731@eda.com> Date: 30 Nov 89 07:33:04 GMT References: <4025@mhres.mh.nl> <1194@radius.UUCP> <3273@convex.UUCP> <5261@omepd.UUCP> <1126@cirrusl.UUCP> <1989Nov28.064349.1421@eda.com> <411@jhereg.Minnetech.MN.ORG> <1989Nov29.170244.10350@eda.com> Organization: EDA Systems,Inc. Santa Clara, CA Lines: 102 jim@eda.com (Jim Budler) writes: Egad following myself up!!!! } mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn) writes: Proposed xargs instead of perl as a command line expander in response to an earlier example of mine. { much deleted...] He said: } } I would venture to say that the xargs version may actually be faster than } } the perl version. To which I responded: } I doubt it, since it forks a process for each expansion, just like } % find -exec \; } Let me give a specific example: } % find / -name core -exec rm {} \; } will fork rm for each match. This is what makes it slow. } % find / -name core -print | xargs rm } will also fork rm for each match. Now I went and ran a "find -name *.o -print | xargs rm" and watched it work from another window. I was wrong, it doesn't fork rm for each match, it fills a buffer with matches, and forks one rm on each buffer full. So "find ... -print | xargs ..." will be faster than "find ... -exec ...", but I still doubt it will be faster than perl on moderately deep trees because it still forks, perl does not. [...] Then I went on to say: } Additional points: } 1. xargs is not universal, although I have a tape with a PD version } somewhere. } 2. on deep trees, the command expanded by xargs can exceed the command } line length buffer in either xargs or the shell it forks (not sure which) } and so it fails to produce the desired result. Point one above remains valid. However, point two I find on re-examining my memory and a current implementation of xargs ( sun OS 4, optional ), is based on my previous attempt to use this exact mechanism on a deep tree on a workstation which had a command line limit of ~256 characters!! And I believe the xargs supplied had a default buffer size that was larger than this. I believe this can be chalked up to *vendor deficiency* not an xargs deficiency. How do I recall, or even know this workstation had such a small command line limit (despite, as I became very much aware, the /usr/include headers specifying "normal" Berkeley derived lengths)? Because we had much trial and tribulation over the normal set noglob eval `tset -s` failing if the resultant setenv TERMCAP ... was longer than that. GREAT vendor! Their tar couldn't read a nine track tape from a vax either, you had to "dd if=/dev/rmt0 conv=swab ... | tar xf -" to read them. Oh well, that's another story entirely. My conclusions: Mark IS correct, "find ... | xargs " is an immense improvement over "find ... -exec \;". But "find ... | perl " is a greater improvement IF there IS an . (And I have not YET found a missing ) And I don't have xargs everywhere, but I have distributed perl as I need it. This demonstrates, I feel, the beauty of the net, by the way. I had given up on xargs because of a previous bad experience with it. Mark's comments lead me to try it again (after I posted, partially unfortunate) and I will now consider it again. Some other people reading this exchange may try it for the first time. They certainly will not have found it through any of the documentation *I've* ever seen. } } -- } } Mark H. Colburn mark@Minnetech.MN.ORG } } Open Systems Architects, Inc. jim -- Jim Budler jim@eda.com ...!{decwrl,uunet}!eda!jim compuserve: 72415,1200 applelink: D4619 voice: +1 408 986-9585 fax: +1 408 748-1032 Brought to you by Super Global Mega Corp .com