promoting Perl (was Re: uutraffic report (in perl))

[Jim Budler]

jim at eda.com (Jim Budler) writes:

Egad following myself up!!!!

} mark at 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 <path> <pattern> -exec <most any command> \;

} 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 <tree> -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 <command>" is an immense improvement
over "find ... -exec <command> \;".

But "find ... | perl <equiv_command>" is a greater improvement IF
there IS an <equiv_command>. (And I have not YET found a missing
<equiv_command>)

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 at Minnetech.MN.ORG 
} } Open Systems Architects, Inc.


jim
-- 
Jim Budler	jim at eda.com    ...!{decwrl,uunet}!eda!jim
compuserve: 72415,1200     applelink: D4619
voice: +1 408 986-9585     fax: +1 408 748-1032