merlyn@iwarp.intel.com (Randal Schwartz) (11/27/89)
In article <3273@convex.UUCP>, tchrist@convex (Tom Christiansen) writes: | Please don't take this wrong, but why DON'T you have perl? [...] | Larry Wall, is the same man who brought you rn, metaconfig, and patch. And don't forget warp! :-) | He privately supports perl better than any industrial software house | that I've ever seen. Hear hear! | Perl is light years ahead of awk, sed, and sh as far as tools go. I | very strongly believe that it will be around for many years to come, | and that it will be extremely widely used throughout the world. I hope so too, although I'm a bit biased, since I will be making (minimal :-) royalties off the forthcoming book on Perl from Nutshell Handbooks (written by "Larry Wall, as told to Randal L. Schwartz" :-). | You | can see how much source has come across the net just lately that's been | written in perl. Hmm... anything to do with me answering every request in comp.unix.questions with a Perl one-liner? :-) | I have not written any awk or sed scripts since I got | perl, and certainly none of those horrendous sh scripts full of | multiple calls to sed and awk and tr and sort and cut and paste and | expand and grep and all their brethren. I've saved myself quite a | bit of development time by writing fewer C programs as well. Exactly! | Furthermore, perl programs are portable without modification or | recompilation to a wealth of architectures. I only have around 5 | architectures now to send common programs too, but in my last job there | were no fewer than a dozen. It's really nice to just close your eyes | and rdist your program and know it will run. As a sysadmin (in one of my *many* incarnations) working with four very different architectures, I fully agree. Many of the tasks that I am doing easily now would have been horrible otherwise. | Do yourself a favor: get perl. And buy the book! :-) Just another Perl hacker, with a flair for grandstanding, -- /== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\ | on contract to Intel's iWarp project, Hillsboro, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn | \== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (11/28/89)
Here's why I didn't install Perl when it first appeared on Usenet: The volume of patches. I like software that is stable, and Perl didn't seem to be. It's too painful to keep updating a program. It's nicer to have all the bugs fixed before you install the program. That stage never seemd to arrive for Perl. Now with the recent Perl posting, I again see patches appearing almost simultaneously. Comments are welcome. Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
rodney@sun.ipl.rpi.edu (Rodney Peck II) (11/28/89)
>>>>> On 28 Nov 89 04:26:01 GMT, dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) said:
Rahul> Here's why I didn't install Perl when it first appeared on
Rahul> Usenet: The volume of patches. I like software that is stable,
Rahul> and Perl didn't seem to be. It's too painful to keep updating
Rahul> a program. It's nicer to have all the bugs fixed before you
Rahul> install the program. That stage never seemd to arrive for
Rahul> Perl.
I'm using a very old version of it with no problems.
$Header: perly.c,v 2.0 88/06/05 00:09:56 root Exp $
Patch level: 0
Just having and older version doesn't stop you from using perl.
--
Rodneyjim@eda.com (Jim Budler) (11/28/89)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: } Here's why I didn't install Perl when it first appeared on Usenet: The } volume of patches. I like software that is stable, and Perl didn't } seem to be. It's too painful to keep updating a program. It's nicer } to have all the bugs fixed before you install the program. That stage } never seemd to arrive for Perl. That stage has never arrived with netnews either 8^) } Now with the recent Perl posting, I again see patches appearing almost } simultaneously. I can't actually disagree with you, however, perl won me over with ONE simple example: % find <path> <pattern> -exec < most any command> \; versus % find <path> <pattern> -print | perl -ne 'equiv_command;' The performance improvement was HUGE! I installed perl at a relatively stable point (2.04) and then monitored the performance of patches against my installed scripts. My next installation was 3.0p4, because I saw no gain before that, and 3.0a thru 3.0p2 didn't work with my installed scripts. At 3.0p4 my installed scripts only required a variable name change, due to a new builtin. I am not a front running perl hacker by any means. I found enough value in version 2 to install it, and felt that when 3.0 reached a certain point it was worth going with the current version. } Comments are welcome. } Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> } UUCP: oliveb!cirrusl!dhesi Just my network cleanup, cron based 'find' commands alone made my initial investment payoff in real (not CPU) time. Our file server didn't always get done with a midnight start 'core' hunt before people came in in the morning. With perl it does, easily. I wish I had more time to explore perl. I'm looking forward to the book. 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
mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn) (11/29/89)
In article <1989Nov28.064349.1421@eda.com> jim@eda.com (Jim Budler) writes: >dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > >} Here's why I didn't install Perl when it first appeared on Usenet: The >} volume of patches. I like software that is stable, and Perl didn't >} seem to be. It's too painful to keep updating a program. It's nicer >} to have all the bugs fixed before you install the program. That stage >} never seemd to arrive for Perl. This point will never arrive with virtually any of Larry Wall's software for the simple reason that he tends to enhance products over their lifetime, fixing bugs, adding new features and attempting to make them run on everything under the sun. Software is not like cement. You don't pour it once and then never do anything with it again. Software is pliable. It has problems, or needs new features, or should be faster, or ..., or ... >I can't actually disagree with you, however, perl won me over with >ONE simple example: > % find <path> <pattern> -exec < most any command> \; >versus > % find <path> <pattern> -print | perl -ne 'equiv_command;' >The performance improvement was HUGE! The same improvement can be had with: find <path> <pattern> -print | xargs <any command> I would venture to say that the xargs version may actually be faster than the perl version. I'm not trying to bash perl, but check for tools that already exist and use them where appropriate. Perl is a great program for doing data manipulation and report processing and stuff, but it is not intended to be a panacea for all lifes little problems. It's not necessarily the most efficient thing out there for pasting command line arguments together and feeding them to an arbitrary command, for example. -- Mark H. Colburn mark@Minnetech.MN.ORG Open Systems Architects, Inc.
tneff@bfmny0.UU.NET (Tom Neff) (11/29/89)
In article <1989Nov28.064349.1421@eda.com> jim@eda.com (Jim Budler) writes: >I can't actually disagree with you, however, perl won me over with >ONE simple example: > > % find <path> <pattern> -exec < most any command> \; >versus > % find <path> <pattern> -print | perl -ne 'equiv_command;' > >The performance improvement was HUGE! My goodness. It's a darn good thing the above quoted poster never read the man page for xargs(1). He might have been won over by UNIX! :-) -- Canada -- a few acres of snow. ^v^v^ Tom Neff -- Voltaire v^v^v tneff@bfmny0.UU.NET
tneff@bfmny0.UU.NET (Tom Neff) (11/29/89)
In article <13352@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >My goodness. It's a good thing Tom never read the SysVR3.2 man page >for xargs(1). > >Because he wouldn't have found it. He wouldn't have found the executable >either. ------------------ + uname -a bfmny0 bfmny0 3.2 2.1 i386 + ls -lF /usr/bin/xargs -r-xr-xr-x 1 bin bin 7362 Jun 26 1988 /usr/bin/xargs* + what /usr/bin/xargs /usr/bin/xargs: xargs:xargs.c 2.3 xindex 1.1 /usr/bin/xargs.sl 1.1 3.2 06/24/88 30252 AT&T-SF ------------------ XARGS(1) (Base System) XARGS(1) NAME xargs - construct argument list(s) and execute command SYNOPSIS xargs [flags] [ command [initial-arguments] ] DESCRIPTION The xargs command combines the fixed initial-arguments with arguments read from standard input to execute the specified command one or more times. The number of arguments read for each command invocation and the manner in which they are combined are determined by the flags specified. . . . ------------------ Snort. -- War is like love; it always \%\%\% Tom Neff finds a way. -- Bertold Brecht %\%\%\ tneff@bfmny0.UU.NET
bill@twwells.com (T. William Wells) (11/29/89)
In article <1989Nov28.064349.1421@eda.com> jim@eda.com (Jim Budler) writes: : I can't actually disagree with you, however, perl won me over with : ONE simple example: : : % find <path> <pattern> -exec < most any command> \; : versus : % find <path> <pattern> -print | perl -ne 'equiv_command;' : : The performance improvement was HUGE! You can also use: % find <path> <pattern> -print | xargs equiv_command for many tasks. I'm amazed at how many users are unaware of xargs. It is amazingly useful and significantly more efficient than using -exec. For example, when I became aware of the EASY MONEY scam and wanted to nuke all its postings from my system, I set up a dummy site "newarts" for batching. I now periodically execute the script: cut -d' ' -f1 /home/news/spool/out.going/newarts/togo \ | xargs egrep EASY /dev/null \ | mail -s "scam" bill and trash the illegal articles when I find them. (Actually, I use a slightly more complex script, in order to find other "interesting" articles which I might miss because I don't subscribe to the appropriate group.) --- Bill { uunet | novavax | ankh | sunvice } !twwells!bill bill@twwells.com
jim@eda.com (Jim Budler) (11/30/89)
mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn) writes: } In article <1989Nov28.064349.1421@eda.com> jim@eda.com (Jim Budler) writes: } >I can't actually disagree with you, however, perl won me over with } >ONE simple example: } > % find <path> <pattern> -exec < most any command> \; } >versus } > % find <path> <pattern> -print | perl -ne 'equiv_command;' } >The performance improvement was HUGE! } The same improvement can be had with: } find <path> <pattern> -print | xargs <any command> } I would venture to say that the xargs version may actually be faster than } the perl version. 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. } I'm not trying to bash perl, but check for tools that already exist and use } them where appropriate. Perl is a great program for doing data } manipulation and report processing and stuff, but it is not intended to be } a panacea for all lifes little problems. It's not necessarily the most } efficient thing out there for pasting command line arguments together and } feeding them to an arbitrary command, for example. You missed the actual point of why I said <equiv_command> in the original post. You cannot feed to arbitrary commands, you feed to perl commands. In this example instead of rm, the perl command is unlink. Perl will not fork any process to do the 'rm', it will unlink the file itself. This is why it is faster than the traditional find command, and your xargs version. 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. } -- } 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
jgreely@giza.cis.ohio-state.edu (J Greely) (11/30/89)
In article <411@jhereg.Minnetech.MN.ORG> mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn) writes: > find <path> <pattern> -print | xargs <any command> >I would venture to say that the xargs version may actually be faster than >the perl version. Well, a quick test on a smallish (~200K) directory tree says that xargs doesn't always win. find . -type f -print | xargs rm -f vs. find . -type f -print | perl -ne 'chop;unlink;' Perl came out about 25% faster in this particular case. I believe the biggest problem with xargs is sub-optimal buffering. Now, if everyone would stop mentioning xargs as the "obvious" solution, we'll all be happier. One, it's not always the most efficient. Two, it's not universally supplied (not on *my* BSD 4.3 tape). Three, the whatis line for xargs doesn't jump out at a novice user. It *might* be clear enough for some, but it might not. xargs - construct argument list(s) and execute command -- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
merlyn@iwarp.intel.com (Randal Schwartz) (11/30/89)
In article <14961@bfmny0.UU.NET>, tneff@bfmny0 (Tom Neff) writes: | In article <1989Nov28.064349.1421@eda.com> jim@eda.com (Jim Budler) writes: | >I can't actually disagree with you, however, perl won me over with | >ONE simple example: | > | > % find <path> <pattern> -exec < most any command> \; | >versus | > % find <path> <pattern> -print | perl -ne 'equiv_command;' | > | >The performance improvement was HUGE! | | My goodness. | | It's a darn good thing the above quoted poster never read the man page | for xargs(1). | | He might have been won over by UNIX! :-) Come on. Suppose the operation was 'unlink;' or 'chmod 0644, $_;'. The perl commandline has two total processes, where even with xargs, you start *out* with three processes, and possibly more depending on the number of args. And of course, either of those are superior to the -exec solution, which is what the original poster had noticed. Of all people to speak, I should probably have it be known that I am *not* a "wild-eyed fanatic" for Perl! I have just noticed that it's a heckuva lot better to have an interpretive language designed for multiarchitecture system management than to resort to bizarre combinations of "standard" UNIX data-redux tools *if* you can get Perl up and running everywhere you need it, and can spend the time to learn to "think Perl", much like you learned to "think pipes and filters" when you started playing with UNIX. As others have noted, I still write 5-line awk scripts and shell scripts and C programs, but Perl does "fill a well-needed gap" :-) very nicely. (I don't subscribe to alt.religion.computers -- maybe this belongs there? :-) Just another Perl hacker, -- /== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\ | on contract to Intel's iWarp project, Hillsboro, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn | \== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/
allbery@NCoast.ORG (Brandon S. Allbery) (11/30/89)
As quoted from <1126@cirrusl.UUCP> by dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi): +--------------- | Now with the recent Perl posting, I again see patches appearing almost | simultaneously. +--------------- And a very large part of those patches is fixes to make Perl work right on some strange machine running Egadsnix somewhere or other. Larry is trying to make Perl run on almost everything, and the patches refine its portability. Not that there aren't any actual bug fixes, but they're fairly few and far between compared to the portability patches. ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)* expnet.all: Experiments in *net management and organization. Mail me for info.
allbery@NCoast.ORG (Brandon S. Allbery) (11/30/89)
As quoted from <14964@bfmny0.UU.NET> by tneff@bfmny0.UU.NET (Tom Neff): +--------------- | In article <13352@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: | >Because he wouldn't have found it. He wouldn't have found the executable | >either. | | + ls -lF /usr/bin/xargs | -r-xr-xr-x 1 bin bin 7362 Jun 26 1988 /usr/bin/xargs* +--------------- Gentle reminder: many versions of Berzerklix don't have xargs. ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)* expnet.all: Experiments in *net management and organization. Mail me for info.
emv@math.lsa.umich.edu (Edward Vielmetti) (11/30/89)
Gentle reminder: many versions of Berzerklix don't have xargs. ++Brandon followed by the obvious, does anyone have a version of xargs in perl? Still reading the man page a lot, --Ed
jim@eda.com (Jim Budler) (11/30/89)
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 <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@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
jim@eda.com (Jim Budler) (12/01/89)
merlyn@iwarp.intel.com (Randal Schwartz) writes: } In article <14961@bfmny0.UU.NET>, tneff@bfmny0 (Tom Neff) writes: Sorry, I never saw this response. It came, and has expired. } | In article <1989Nov28.064349.1421@eda.com> jim@eda.com (Jim Budler) writes: } | >I can't actually disagree with you, however, perl won me over with } | >ONE simple example: } | > } | > % find <path> <pattern> -exec < most any command> \; } | >versus } | > % find <path> <pattern> -print | perl -ne 'equiv_command;' } | > } | >The performance improvement was HUGE! } | } | My goodness. } | } | It's a darn good thing the above quoted poster never read the man page } | for xargs(1). I have, and have responded to other posts and mail about xargs with: 1. It's not universally available here, perl is. 2. It isn't as good on deep trees Since the example given elsewhere in the original posting was of a cleanup of a fileserver based on "find / ..." it was by definition a deep tree... } | } | He might have been won over by UNIX! :-) I was won over by UNIX long ago. } Come on. Suppose the operation was 'unlink;' or 'chmod 0644, $_;'. } The perl commandline has two total processes, where even with xargs, } you start *out* with three processes, and possibly more depending on } the number of args. And of course, either of those are superior to } the -exec solution, which is what the original poster had noticed. Exactly. } Of all people to speak, I should probably have it be known that I am } *not* a "wild-eyed fanatic" for Perl! I also am not a perl fanatic. I've merely found it more efficient in several system and network administrative tasks among different versions of UNIX. Note: xargs is not a feature of UNIX. Period. It is a PROGRAM available on several versions of Unix derived from certain late model ATT versions of UNIX, and ported to some, but certainly not all, non-ATT versions of UNIX. 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
tneff@bfmny0.UU.NET (Tom Neff) (12/02/89)
In article <1989Dec1.083526.23734@eda.com> jim@eda.com (Jim Budler) writes: >Note: > >xargs is not a feature of UNIX. Period. > >It is a PROGRAM available on several versions of Unix derived from >certain late model ATT versions of UNIX, and ported to some, but >certainly not all, non-ATT versions of UNIX. Good description of perl too, come to think of it! :-) Now which tool's simpler... -- The real problem with SDI is %/ Tom Neff that it doesn't kill anybody. /% tneff@bfmny0.UU.NET
jim@eda.com (Jim Budler) (12/02/89)
tneff@bfmny0.UU.NET (Tom Neff) writes: } In article <1989Dec1.083526.23734@eda.com> jim@eda.com (Jim Budler) writes: } >Note: } > } >xargs is not a feature of UNIX. Period. } > } >It is a PROGRAM available on several versions of Unix derived from } >certain late model ATT versions of UNIX, and ported to some, but } >certainly not all, non-ATT versions of UNIX. } Good description of perl too, come to think of it! :-) NOT if you realize the word "PROGRAM" in the description means "binary object code executeble useable under license...", whereas in the description of perl the word "PROGRAM" would mean "portable source code to create an executable useable as you see fit". ALSO you would have to truncate the description after "available on several versions of Unix" if you were being honest. } Now which tool's simpler... Which tool's more efficient? I'm getting a little tired of this. Perl is available in portable source, therefor, as far as I'm concerned it's available throughout my unix platform base. The logistics, are just that, logistics. It is, by my definition, available wherever I need it. xargs (before <4731@netcom.UUCP>) is not. Even given the PD xargs in <4731@netcom.UUCP>, it is LESS efficient in the example I gave in the original posting ( "find / ... -print | perl ..." on a fileserver). } -- } The real problem with SDI is %/ Tom Neff } that it doesn't kill anybody. /% tneff@bfmny0.UU.NET ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a problem? 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
chuckb@lotex.UUCP (Chuck Bentley) (12/04/89)
In article <5294@omepd.UUCP> merlyn@iwarp.intel.com (Randal Schwartz) writes: >In article <14961@bfmny0.UU.NET>, tneff@bfmny0 (Tom Neff) writes: >| In article <1989Nov28.064349.1421@eda.com> jim@eda.com (Jim Budler) writes: >| >I can't actually disagree with you, however, perl won me over with >| >ONE simple example: . . >combinations of "standard" UNIX data-redux tools *if* you can get Perl >up and running everywhere you need it, and can spend the time to learn That's a big *if*. I'm running XENIX 2.2.3 on a 286 and find the flood of scripts and tips on Perl interesting, but frustrating. I realize that I may be old technology, but I have noticed that I'm not alone. I guess if you can't keep up with the Hardware Race, you're just out of luck with the software coming across the net these days. Chuck...
rodney@degas.ipl.rpi.edu (Rodney Peck II) (12/04/89)
>>>>> On 3 Dec 89 23:49:28 GMT, chuckb@lotex.UUCP (Chuck Bentley) said: Chuck> In article <5294@omepd.UUCP> merlyn@iwarp.intel.com (Randal Schwartz) writes: >In article <14961@bfmny0.UU.NET>, tneff@bfmny0 (Tom Neff) writes: >| In article <1989Nov28.064349.1421@eda.com> jim@eda.com (Jim Budler) writes: >| >I can't actually disagree with you, however, perl won me over with >| >ONE simple example: Chuck> . Chuck> . >combinations of "standard" UNIX data-redux tools *if* you can get Perl >up and running everywhere you need it, and can spend the time to learn Chuck> That's a big *if*. [...] I guess if you can't keep up with the Chuck> Hardware Race, you're just out of luck with the software coming Chuck> across the net these days. Yeah...sigh...I can't run perl on my TRS-80 model I either. -- Rodney
michael@stb.uucp (Michael Gersten) (12/06/89)
In article <RODNEY.89Dec4003036@degas.ipl.rpi.edu> rodney@degas.ipl.rpi.edu (Rodney Peck II) writes: >Yeah...sigh...I can't run perl on my TRS-80 model I either. >-- >Rodney Ever hear of overlays? As long as you've got the disk space to compile it, it can't be that hard. I think that one of the later versions of LC for Ldos supported overlays, and if you're willing to use the entire 5 meg drive that used to be sold for that machine in those days, you've got room to compile it. Now, getting the shell scripts to run on that machine is a bit of a problem :-) Michael p.s. :-) :-) :_) :-) :_) :_( (_: (_: (-: (_; (-: (-: (((---((( <BOOM>
roe@sobmips.UUCP (r.peterson) (12/09/89)
Okay - enough already.
Someone has created a useful utility.
The originator has seen fit to distribute his utility. Thanks - this is
what keeps usenet source code a good thing. Kudos and applause, with
*no* sarcasm intended.
It is NOT his responsibility to see that his utility runs on your
machine. If he sees fit to do so, GREAT! If you are going to bitch
about perl not running on machineX/osY/gibbleZ, just don't bother.
Further to this, I think he's doing a great job providing
portability now, and anyone who wishes to complain that it
doesn't run on a Trash80/1 should be (pick a suitable
method of bodily mutilation).
Shall we question the authors' right to promote his own creation?
Are you nuts?
Other people have also found this utility useful, and create further
utilities based thereon.
They also have seen fit to distribute their utilities.
All of the above comments apply, especially the kudos and applause.
If you are upset about perl not running on your machine - FIX IT! When
you're done, post the fixes (or better - mail them to the author, who
seems to be willing to incorporate changes). Then, receive your own
kudos.
I've not yet learned perl - but I intend to do so. I'm from the school
that says "If it takes more than 20 lines of shell, write it in c";
however, casual perusal of some of the perl utilities that have arrived
combined with the ridiculous ease with which they can be modified,
convinced me that perl is worth using.
And, EVEN IF ITS' NOT - I applaud anyone willing to put that amount of
effort into a piece of software and then (not only) give it away, but
_support_it_.
'Nuff said.
--
One makes strong assumptions delving Roe Peterson
into the beginning of the universe... {uunet,mcgill-vision}!sobeco!roe
- Stephen Hawking, Cambridge