[10481] in Perl-Users-Digest
Perl-Users Digest, Issue: 4074 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 26 15:05:33 1998
Date: Mon, 26 Oct 98 12:01:34 -0800
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 26 Oct 1998 Volume: 8 Number: 4074
Today's topics:
Re: Not to start a language war but.. (Cameron Laird)
Re: Not to start a language war but.. <Klaus.Schilling@home.ivm.de>
Re: Not to start a language war but.. <Klaus.Schilling@home.ivm.de>
Re: Not to start a language war but.. (Dennis Lee Bieber)
Re: Not to start a language war but.. (Nicholas Carey)
Re: Not to start a language war but.. <mhc@Eng.Sun.COM>
Re: Not to start a language war but.. <jorendorff@ixl.com>
Re: Not to start a language war but.. <sugalskd@netserve.ous.edu>
Re: Not to start a language war but.. <JamesL@Lugoj.Com>
Re: Not to start a language war but.. <JamesL@Lugoj.Com>
Perl Interpreter <JoshB@flash.net>
Re: Perl Interpreter <dtauzel@uswest.com>
Re: pipes to an external program Marc @ box . com
Re: problem with file test -e stevenjm@olywa.net
Problems using Net::Ping <mguelfi@acm.org>
Recovering from aborted script <kmattson@qualcomm.com>
Re: Sort Methods Compared <jdporter@min.net>
Re: split() works not as expected (Daniel Beckham)
Re: System command (why a LIST??) <murrayb@vansel.alcatel.com>
Re: System command (why a LIST??) <Alex.Davies@tiuk.ti.com>
Re: System command (why a LIST??) <barnett@houston.Geco-Prakla.slb.com>
Re: System command (why a LIST??) (David Formosa)
Re: The point of curly braces <jorendorff@ixl.com>
Re: What isn't Perl good for? (Walter Tice USG)
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 26 Oct 1998 11:02:06 -0600
From: claird@Starbase.NeoSoft.COM (Cameron Laird)
Subject: Re: Not to start a language war but..
Message-Id: <7129ue$nae$1@Starbase.NeoSoft.COM>
In article <13876.32186.336772.838048@amarok.cnri.reston.va.us>,
Andrew M. Kuchling <akuchlin@cnri.reston.va.us> wrote:
.
.
.
> While reading it, I occasionally had to go back and re-parse a
>sentence like "More often would go...", assuming on the second parse
>that the first word was a noun. (This is completely unconnected to the
>rest of this thread, but it's far more interesting. Anyone else ever
>read a biography, or known anyone who has?)
Sigmund Freud did once. He wrote a letter to Fliess
about the experience:
Whoever undertakes to write a biography
binds himself to lying, to concealment,
to flummery, and even to hiding his own
lack of understanding, since biographi-
cal material is not to be had, and if it
were it could not be used. Truth is not
accessible; mankind does not deserve it.
Freud was an early contributor to c.l.p.m, I think;
he certainly has the rhetoric down. Is that what
happened to Perlites? They saw consenting adults
practicing object orientation, and still haven't
recovered?
Oh, I should mention that I don't really know Freud,
unless of course I'm repressing memories of the time
travel and so on.
>
> The More book was definitely more enjoyable for me than
>Ackroyd's biography of William Blake was, but Ackroyd's _Dickens_ is
>by far the best biography I've ever read, and among the best books
>that I've ever read, period.
>
> ObPython: Oh, I don't know. sys.stdout.readline, or something.
.
.
.
I thought you'd cite the natural-language processors
written in Perl, and how they feel about "More often
would go.
Thanks for the tip on Ackroyd, by the way. Definitely
books worth knowing.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
claird@NeoSoft.com +1 281 996 8546 FAX
------------------------------
Date: 26 Oct 1998 14:56:34 +0100
From: Klaus Schilling <Klaus.Schilling@home.ivm.de>
Subject: Re: Not to start a language war but..
Message-Id: <87u30r8m0d.fsf@ivm.de>
spam@browser.org (Rob Partington) writes:
> On 26 Oct 1998 08:18:20 +0100,
> Cees de Groot <cg@bofh.cdg.acriter.nl> wrote:
>
> > --- We're hiring Java developers => www.acriter.com
>
> Not hiring python developers? :-p
Java developers are capitalists, whereas python developers are anarchists.
Klaus Schilling
------------------------------
Date: 26 Oct 1998 15:10:49 +0100
From: Klaus Schilling <Klaus.Schilling@home.ivm.de>
Subject: Re: Not to start a language war but..
Message-Id: <87r9vv8lcm.fsf@ivm.de>
Dan Sugalski <sugalskd@netserve.ous.edu> writes:
>
> Crappy programmers can produce crappy code regardless of the language
> used. In no case did *any* of those languages help someone without a clue.
> Thinking that language choice will make any difference on the quality of
> the resulting code is so wrong it borders on delusional.
>
> An idiot with a Stradivarius will produce music that sounds just as bad as
> an idiot with a $100 used school violin. And a master violinist will
> produce better music on that cheap violin than the idiot will ever hope to
> on anything.
>
But a good trumpet player might still be a bad violinist and vice versa.
A good concert might still need both of them. Maestro!
`Va pensiero sulle ale dorate, va ti posa sui clivi, sui colli'
Klaus Schilling
------------------------------
Date: Mon, 26 Oct 1998 17:23:18 GMT
From: wlfraed@ix.netcom.com (Dennis Lee Bieber)
Subject: Re: Not to start a language war but..
Message-Id: <3637a9d1.4003310@nntp.ix.netcom.com>
On Sun, 25 Oct 1998 23:25:04 -0500, rjk@coos.dartmouth.edu (Ronald J
Kimball) declaimed the following in comp.lang.python:
>
> Yes, the typing information is there in both cases. But it seems
> obvious to me that someone could find the former more readable than the
> latter. In particular, the former uses intuitive initals - s for
> string, a for array, h for hash table - whereas the latter uses
> nonintuitive symbols - why do $, @, and % necessarily map to string,
> list, and table?
>
Playing devil's advocate, the $ looks like an S (string), the @
looks like an a (array)... The %... ? (two columns separated by a bar?)
And the $ at list was common in BASIC at one time, though used
at the end of the variable name.
Dropping out the prosecutors role: I have had the last two
variants of the Camel book and have been unable to even make sense of
"Hello World". A weekend with the Python docs and I managed to write an
SMTP email sending program for my Amiga.
--
> ============================================================== <
> wlfraed@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> ============================================================== <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <
------------------------------
Date: Mon, 26 Oct 1998 18:13:37 GMT
From: ncarey@harlequin.com (Nicholas Carey)
Subject: Re: Not to start a language war but..
Message-Id: <3634bb60.128336548@newshost.harlequin.com>
On Mon, 26 Oct 1998 14:53:19 -0000, "Paul Makepeace"
<Paul.Makepeace@POBox.com> wrote:
>
> Andrew Snare wrote in message ...
> >I'm also surprised
> >that perl didn't go with the convenience of leaving the braces out
> >altogether when it's only a single statement (like C), but that's a
> >personal thing. :)
>
> That 'feature' of C is probably one of its most evil. It's far too easy to
> abuse or have it bite back when you (or worse) some else isn't paying
> attention.
Ummm...I think the [lack of] difference between '=' and '==' is
probably worse (esp. when used in the conditional test of 'if'
statements probably beats that. :-)
N.
--
------------------------------
Date: 26 Oct 1998 10:17:25 -0800
From: Mike Coffin <mhc@Eng.Sun.COM>
Subject: Re: Not to start a language war but..
Message-Id: <8p63e8b9oi2.fsf@Eng.Sun.COM>
Dan Sugalski <sugalskd@netserve.ous.edu> writes:
> Thinking that language choice will make any difference on the quality of
> the resulting code is so wrong it borders on delusional.
I wish this argument would die the death it deserves. Language choice
*does* make a difference in code quality. Some languages are a *lot*
harder to write good code in than others. When you make something
hard to do, fewer people will do it well.
It is true that bad programmers can produce bad code in any language.
But so what? It's also true that a really clumsy person can get
themselves killed rock climbing without a rope or bird watching in a
park. Does that mean that unroped rock climbing and birdwatching are
equally dangerous activities?
-mike
------------------------------
Date: Mon, 26 Oct 1998 12:42:52 -0800
From: Jason Orendorff <jorendorff@ixl.com>
Subject: Re: Not to start a language war but..
Message-Id: <3634DECC.E995B8AB@ixl.com>
> And yes, it is a factual error, not merely an opinion.
It's not the advantages of contextual clues that I'm worried about--
it's the squiggles all over the page. :-)
In most cases where Perl requires you to express it, context isn't all
that useful. OTOH, in most cases, expressing variable names explicitly
in the declaration of a function is kinda useful. *shrug*
It's not a big deal. Both languages work. Python came along a bit
later, and so its syntax is "smoother" but less "flexible", if you
will. Whether that makes it easier to understand is in the eye of
the beholder.
--
jason
------------------------------
Date: 26 Oct 1998 18:50:21 GMT
From: Dan Sugalski <sugalskd@netserve.ous.edu>
Subject: Re: Not to start a language war but..
Message-Id: <712g9d$19s$1@news.NERO.NET>
In comp.lang.perl.misc Cees de Groot <cg@bofh.cdg.acriter.nl> wrote:
: [And this will be my last contribution, but now that everyone's calling
: me a crappy programmer... ;-)]
: Dan Sugalski <sugalskd@netserve.ous.edu> said:
:>Crappy programmers can produce crappy code regardless of the language
:>used. In no case did *any* of those languages help someone without a clue.
:>Thinking that language choice will make any difference on the quality of
:>the resulting code is so wrong it borders on delusional.
:>
: So now I'm indirectly called a crappy programmer twice just because I don't
: like Perl :-).
No, you're not. You said in an earlier posting that you'd been writing
perl code for four years but were still producing write-only code. That
means either:
A) You were spending so little time with the language that you never made
it past the 'language newbie' stage (and there's no crime in
this--multivariable calculus and FORTRAN hod similar positions in my
brain)
or
B) You're not very good.
I was assuming the first, but I suppose you can put yourself in whatever
category you like.
I'm not suggesting you're a crappy programmer just because you don't like
perl. I'm not even suggesting that you're a crappy programmer because you
chose another tool for a particular job even if that tool's not the
optimal choice from a technical standpoint. Personal prejudice is a valid
factor to consider when choosing a language. (I, for one, will go to
nearly any length to avoid writing, or even maintaining, code written in
COBOL, so that language is a bad choce for me even if it's technically
superior for the task at hand)
If you're any good, you should be able to produce good code in a langauge,
despite any personal prejudices, *once you're competent in the language*.
And if you're any good, you should be able to get competent in the
language given an appropriate amount of time. If you took that time, then
I guess you do qualify as a crappy programmer. If you didn't, for whatever
reason,t hen you don't. (At least not by this example)
Dan
------------------------------
Date: Mon, 26 Oct 1998 11:37:13 -0800
From: James Logajan <JamesL@Lugoj.Com>
Subject: Re: Not to start a language war but..
Message-Id: <3634CF69.7F001D43@Lugoj.Com>
Tom Christiansen wrote:
> In comp.lang.perl.misc, James Logajan <JamesL@Lugoj.Com> writes:
> :Therefore
> :one should scrutinize his arguments most carefully before accepting
> :them.
>
> You mean you don't scrutinize everyone's arguments before accepting them?
Shucks yeah, don't you?
> Think of Perl's variable naming as a variant on Hungarian notation.
> Instead of saying s_string, a_list, h_table, we just say $string,
> @list, and %table. In both cases, the typing information is right
> there in front of you. Extra context helps in reading.
Even if Python had been a statically typed language, it probably has
far too many structured and built-in types to take advantage of the
use of special characters. The concept may be valid, but the
execution in Perl is obviously not entirely successful for many
people. Also, Perl only seems to apply this syntax to the top level
references only. As soon as you start dereferencing something like a
record structure, one can't tell by the dereference syntax the
type of the object being dereferenced. So for any non-trivial
data structure, it would appear that Perl provides no more information
to the programmer than does Python. In fact since neither language
provides variable declarations, one has to rely on comments, mnemonic
variable name, or the original assignment to determine the type of
the object.
> Think about the stronger accordance of case, number, and gender often
> found in other Western languages beyond Enligsh. Once you become
> accustomed to them, those inflections actually make it easier to
> understand what is said or written, not harder.
Well, I never quite got the hang of verb-forms or how to guess
the gender of nouns when I studied German. But there does appear
to be a large element of redundancy in many Western languages
that may exist because the spoken form is subject to noise and
other degradation. I don't think there is much to be gained by
adding such constructs to languages that are almost 100% written.
(P.S. Ever studied Loglan or Esperanto?)
[Reasonable remarks on the value of context elided for brevity.]
Yes, context is important, but you are missing an important aspect: the
scale on which context is taken. The context scale of Perl is too small,
which is why many people consider the language cluttered. Consider the
following two imaginary language examples:
Example 1:
$b = 42
$a = $b + 5
$a = $a * 9
Example 2:
integer a, b
b = 42
a = b + 5
a = a * 9
Perl tries to provide context information at the token level; hence we
are told no less than 3 times in 2 lines that "a" is a string (but we
do numeric operations on it!). That is over-kill (and misleading in the
end anyway!) The declarative version tells us once that "a" is really
an integer. But we have to include a larger context to see that.
Python does away with the declaration of course, and uses the assignment
to provide the information on the data type of "a" in the context of
the 3 lines.
But Python (and ultimately Perl) and all dynamically typed languages
can allow the context to grow so large that it is impossible for a
programmer to know what the types of the variables are in a given
smaller context.
So in the end, I think Perl's focuses it's context on too narrow
a scope while one may validly claim that Python's context scope
can be too large. I think the frustration I and many others have
with Perl is that extra context ends up being useless clutter when
data structures of any complexity are involved or when it is clear
from the larger context what the type of the variables is.
Do you understand now why some of us really dislike this aspect of
Perl, or am I writing on at length to no avail?
> Now, I can think of little that disgusts me more than insinuations that
> I've been bought off, and that therefore I am not to be trusted for
> fear that I'm trying trick you out of your hard-earned shekels just so
> to feather my own nest. If I were in this to get rich, I'd be acting
> extremely differently, don't you think?
When it comes to arguments that are somewhat subjective, I think that
knowing the motivations of the proponents is a proper exercise of due
diligence.
> Did it ever occur to you that a perfectly valid explanation
> is that my background puts me in a *better* position than most, not a
> worse one?
There is no question in my mind that your background (what I know of
it) makes you an expert in Perl. I am unclear on how well you know and
use Python; sorry.
------------------------------
Date: Mon, 26 Oct 1998 11:55:24 -0800
From: James Logajan <JamesL@Lugoj.Com>
Subject: Re: Not to start a language war but..
Message-Id: <3634D3AC.53EF597B@Lugoj.Com>
Daniel Grisinger wrote:
> This is a dangerous and unfair argument to make. Dangerous because
> it smacks so much of pettiness and thus reduces your credibility.
> Unfair because you, Tom, I, and all other programmers have a vested
> financial interest in _some_ language. We all have some language
> that we get paid to use.
I don't know about you, but I know more than one computer language.
And while I know Fortran, I'd rather not get paid to use it....
It is also a fact that bias exists and is motivated by many things.
> Now you have a vested financial interest in python, as you have
> skills that will provide greater financial benefit if python is
> adopted by a larger portion of the commercial world. Therefore
> one should scrutinize your arguments most carefully before
> accepting them.
Temporal ordering is important: we chose Python before we
would likely see any "financial" benefit. Indeed, had financial
benefit been out criteria, Perl, Java or Tcl should have been
our choice since there weren't (and still aren't) a whole
lot of opportunities for Python programmers.
------------------------------
Date: Mon, 26 Oct 1998 11:10:11 -0600
From: "Josh Barfield" <JoshB@flash.net>
Subject: Perl Interpreter
Message-Id: <712ae4$fnr$1@excalibur.flash.net>
I need a Perl Interpreter. I've tried http://www.perl.com, but I don't
really understand their's
------------------------------
Date: Mon, 26 Oct 1998 12:49:30 -0600
From: David Tauzell <dtauzel@uswest.com>
To: Josh Barfield <JoshB@flash.net>
Subject: Re: Perl Interpreter
Message-Id: <3634C43A.7AA808C9@uswest.com>
What platform are you on (i.e. NT, MacOS, Solaris, AIX ....)
Dave.
------------------------------
Date: 26 Oct 1998 17:11:05 GMT
From: Marc @ box . com
Subject: Re: pipes to an external program
Message-Id: <3636ad0f.795661@news.euronet.be>
On Sun, 25 Oct 1998 21:33:43 -0600, tadmc@flash.net (Tad McClellan)
wrote:
> How about reading the solution to your Frequently Asked Question
> in the aptly named Perl Frequently Asked Questions?
>
>
>Perl FAQ, part 8,
>
> "How can I open a pipe both to and from a command?"
Thanks for the tip. I've looked and it's working.
Marc
------------------------------
Date: Mon, 26 Oct 1998 19:38:21 GMT
From: stevenjm@olywa.net
Subject: Re: problem with file test -e
Message-Id: <712j3d$13p$1@nnrp1.dejanews.com>
In article <711veg$s63$1@testinfo.uoguelph.ca>,
breville@uoguelph.ca (Barry G Reville) wrote:
> I have a program that uses the -e file test several times to
> check if a file exists before opening the file to write to.
> Unfortunately it doesn't seem to work consistently - sometimes it gives
> the exact opposite answer I expect and overwrites the files.
>
> Here's an example:
>
> if (!-e $tempfile){
> $temp = -e $tempfile;
> print "-e = '$temp' ::";
> $temp = (!-e $tempfile);
> print "!-e = '$temp' \n";
> open(VALUEFILE,">$tempfile") or die "Couldn't open $tempfile\n";
> }
>
> Now , even though $tempfile exists it reports "-e = ''" and
> "!-e = '1'" with the result that it overwrites the file.
> In other parts of my program I use it again but it sometimes
> works and sometimes not - what am I missing?
Well, you've confused me with the above! It either has a few interpolation
problems or I'm even stupider than normal today. :-)
Wouldn't it be simpler to lose all the print stuff above and:
#####################
!-e $tempfile and do{ # first time through one would think
open(VALUEFILE,">$tempfile") or die "Couldn't create $tempfile, $!\n";
close VALUEFILE; ^^^^^^ ^^
}; # end of do{ block };
## we now have a tempfile, or we wouldn't get here
open(VALUEFILE, ">>$tempfile") or die "Couldn't open/append to $tempfile,
$!\n"; print VALUEFILE $stuff; ^^^^^^^^^^^ ^^ close VALUEFILE;
##################
?????
Certainly it's more readable to me. Note the die statements. Nice to have
in your error log when things go south on you.
HTH,
Steve
Blackwater-Pacific
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Mon, 26 Oct 1998 16:15:40 -0300
From: Marcelo Guelfi <mguelfi@acm.org>
Subject: Problems using Net::Ping
Message-Id: <3634CA5A.4CD90BDD@acm.org>
I'm trying to use the Net::Ping module in a program and I found that
fails in the ping method. I ran the program in 3 different machines with
4 perl versions:
1) rs6000/AIX 4.2.1 version 5.005_01 built for aix
2) intel 486/redhat 5.1 version 5.004_04 built for i386-linux
3) intel 486/windows 95 binary build 502 provided by ActiveState
4) intel 486/windows 95 binary distribution version 5.004_02
The program only works in the rs6000. Could anyone give me some help?
Thanks in advance,
Marcelo.
Marcelo Guelfi
email: mguelfi@acm.org
ps. This the source of the program
#!/usr/local/bin/perl
use Net::Ping;
($host)=@ARGV;
$p = Net::Ping->new() or die "Can't create the object\n";
if ($p->ping($host) ){
print "$host is alive\n";
} else {
print "$host is dead\n";
}
$p->close();
------------------------------
Date: Mon, 26 Oct 1998 11:43:38 -0800
From: Kevin Mattson <kmattson@qualcomm.com>
Subject: Recovering from aborted script
Message-Id: <3634D0EA.47AD@qualcomm.com>
How can I detect when a user has hit CNTRL-C or CNTRL-Break while a Perl
script is running? I'd like to do some additional clean-up before the
script exits.
I'm using ActiveState's ActivePerl for Win32 (Build 502). Previously, I
was using Build 316, which worked ok since it threw a "__DIE__" signal
when the user hit CNTRL-C.
Any ideas???
Thanks,
Kevin Mattson
------------------------------
Date: Mon, 26 Oct 1998 13:37:22 -0500
From: John Porter <jdporter@min.net>
Subject: Re: Sort Methods Compared
Message-Id: <3634C162.4DB39B94@min.net>
Bob N. wrote:
>
> Some postings here on routines for sorting IP addresses got me thinking,
> so I did a little (very) testing some of the suggestions
>[...]
> it's best to minimize the stuff in the sort portion because that will be
> repeated many times per list element. The Schwartzian transform does this
> by converting the list to something sortable using a map statement which
> will execute the code once per element.
> However, if the thing done during the sort is written to minimize the work
> done there,then the orcish maneuver can be the fastest.
> In particular, don't use subroutine calls in the sort.
This is of course a very interesting thing to study.
However, your numbers suffer from one fatal flaw: stopwatch
times are almost useless.
You need to familiarize yourself with the usage of the Benchmark
module.
--
John "Throbblefoot" Porter
Please Don't "Courtesy CC" me.
I read this newsgroup fanatically. You know that!
("Emailed only" is fine, though.)
"The people at the Grey Hotel
Are either aged or unwell." -- EG
------------------------------
Date: Mon, 26 Oct 1998 13:47:40 -0500
From: danbeck@eudoramail.com (Daniel Beckham)
Subject: Re: split() works not as expected
Message-Id: <MPG.109e8dd3a8fc80029896a4@news.supernews.com>
[This followup was posted to comp.lang.perl.misc and a copy was sent to
the cited author.]
I think you might have missed a fundamental concept in perl. Arrays...
@array is the entire array, $array[0] is the first element, $array[1] is
the second. So the last octet, which is the first element, would be
stored in $array[3].
I would suggest that you run, not walk, to your nearest bookseller and
pick up a copy of "Learning Perl" published by O'Reilly
<http://www.ora.com/>. I used it to learn perl some time ago and I can't
say enough about that wonderful learning tool.
You can use the info in the first paragraph and ignore the second, but
you are making a huge mistake...
Regards,
Daniel Beckham
In article <70n2a8$id7$1@nnrp1.dejanews.com>, raimund_kessler@my-
dejanews.com says...
> What I want to do is to increment an ip address. I tried to split the address
> in the 4 parts then increment the last one and finally join the parts
> together. To split I used the line @pip = split(/\./,$ip[0]); After that the
> value of @pip was 4. Whats wrong? Can anybody help me?
>
> Thanks in advance
> Raiund Kessler
>
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
>
------------------------------
Date: 26 Oct 1998 09:51:48 -0800
From: Brad Murray <murrayb@vansel.alcatel.com>
Subject: Re: System command (why a LIST??)
Message-Id: <uu30r43ez.fsf@vansel.alcatel.com>
man perlsec for info on why system is used with a list.
--
Brad Murray "Your users are clueless, out of control,
Software Analyst and without leadership."
Alcatel Canada --- John Alan Swanson on the merits of SCM
------------------------------
Date: Mon, 26 Oct 1998 18:45:24 +0000
From: Alex Davies <Alex.Davies@tiuk.ti.com>
Subject: Re: System command (why a LIST??)
Message-Id: <3634C344.FC498497@tiuk.ti.com>
Andrew Perrin wrote:
> [posted & sent via e-mail]
>
> I take it as another in the 'there's more than one way to do it' philosophy.
> The list implementation can be cleaner & more convenient in some
> circumstances; for example, something along the lines of:
>
> $path = '/usr/local/bin/';
> $cmd = 'perl';
> $arg[0] = '-v';
> $arg[1] = '-w';
> system("$path$cmd",@arg);
>
> ...but I can't think of a situation in which it's *necessary*. Just keeps you
> from having to (1) do lots of concatenation; or (2) do some/a lot of
> backslashing to get the point across...
>
Be careful! I've seen places where people code up a dummy command string
(maybe for a debug print statement) and then give this to system:
my $cmd = "$some_prog " . join(" ", @some_args);
system("$cmd")
&& warn "something went wrong - $?";
The problem here is that the $cmd string will be split into 'words'
(ie. on whitespace) and so any of the @some_args array containing
whitespace will be split up - this probably isn't what you intended.
You could always put quotes in the $cmd...
$cmd = "$some_prog " . join(" ", map {"'$_'"} @some_args);
...but then you run the risk of one of @some_args containing quotes...
and you're firing off an extra /bin/sh process, which unless the
elements of @some_args are going to contain shell metacharacters
isn't needed.
So there are times when it's best to use a non-single-string list to system:
system($some_prog, @some_args)
&& warn "something went wrong - $?";
alex.
_________________________________________________________________________
Alex Davies, MOS Design, Email: Alex.Davies@tiuk.ti.com
Texas Instruments Limited,
800 Pavillion Drive, Tel (work): 01604 663450
Brackmills Industrial Estate, (home): 01604 764961
Northampton, NN4 7YL.
U.K.
> ap
>
> Jete Software Inc. wrote:
>
> > I notice in the Camel book (pg 230) that the system takes a LIST argument.
> > Almost everytime that I have seen it in people's code they have coded it
> > as a single scalar string system("cp /etc/hosts /etc/hosts.BAK").
> > Now I understand that they can get away with this because it is simply
> > a one-element list. But is there any advantage to writing it like this:
> > (@args) = ("cp", "/etc/hosts", /etc/hosts.BAK");
> > system(@args) == 0 or die "system @args failed: $?"
> >
> > Thanks!!
> >
> > -- Norman
>
> --
> -------------------------------------------------------------
> Andrew J. Perrin - NT/Unix/Access Consulting - (650)938-4740
> aperrin@mcmahon.qal.berkeley.edu (Remove the Junk Mail King)
> http://www.geocities.com/SiliconValley/Grid/7544/
> -------------------------------------------------------------
------------------------------
Date: Mon, 26 Oct 1998 12:13:15 -0600
From: Dave Barnett <barnett@houston.Geco-Prakla.slb.com>
Subject: Re: System command (why a LIST??)
Message-Id: <3634BBBB.A5DDB453@houston.Geco-Prakla.slb.com>
Jete Software Inc. wrote:
>
> I notice in the Camel book (pg 230) that the system takes a LIST argument.
> Almost everytime that I have seen it in people's code they have coded it
> as a single scalar string system("cp /etc/hosts /etc/hosts.BAK").
> Now I understand that they can get away with this because it is simply
> a one-element list. But is there any advantage to writing it like this:
> (@args) = ("cp", "/etc/hosts", /etc/hosts.BAK");
> system(@args) == 0 or die "system @args failed: $?"
>
> Thanks!!
>
> -- Norman
Sure. The advantage of a list context over scalar is that in list
context, perl will attempt to execute the command directly, without
spawning an external shell. There are a few conditions under which perl
will always fork a child, one of which is for globs (check DejaNews for
the others).
HTH.
Cheers,
Dave
--
Dave Barnett Software Support Engineer (281) 596-1434
Shin: a device for finding furniture in the dark.
------------------------------
Date: 26 Oct 1998 19:44:24 GMT
From: dformosa@zeta.org.au (David Formosa)
Subject: Re: System command (why a LIST??)
Message-Id: <slrn739k8o.h27.dformosa@godzilla.zeta.org.au>
In article <36349DD9.3F1809AF@mcmahon.qal.berkeley.edu>, Andrew Perrin wrote:
[...]
>...but I can't think of a situation in which it's *necessary*. Just keeps you
>from having to (1) do lots of concatenation; or (2) do some/a lot of
>backslashing to get the point across...
The list form of system dosn't call the shell.
------------------------------
Date: Mon, 26 Oct 1998 13:40:10 -0800
From: Jason Orendorff <jorendorff@ixl.com>
Subject: Re: The point of curly braces
Message-Id: <3634EC3A.D508CCDA@ixl.com>
> Yes, one doesn't have to use indents:
> sort {$a <=> $b} @list;
> if (cond) {something;}
> else {something_else;}
> /foo/ && do {bar; next;};
Hmm:
list.sort(cmp)
if cond: something()
else: something_else()
if x=='foo': bar(); continue
> And on the other hand, a fair number of my statements are much
> longer than a line. I would hate to have an end of line count
> as a end of statement.
Python continues lines if you have a (, [, or { that's still open
at the end of the line. If that's not enough you can use \ to
continue lines, just like C.
You wouldn't hate Python. It's practically impossible. :-)
--
jason
wc file # Count the number of lines
------------------------------
Date: 26 Oct 1998 19:00:38 GMT
From: tice@hunch.zk3.dec.com (Walter Tice USG)
Subject: Re: What isn't Perl good for?
Message-Id: <712gsm$75s@zk2nws.zko.dec.com>
In article <36325997.7071805@news.junctionnet.com> jlewchuk@junctionnet.com writes:
>On Tue, 20 Oct 1998 03:11:02 GMT, Elaine -HappyFunBall- Ashton
<snip>
>Those of
>you who have been around computers for 20 years may understand this reference:
>if it's a batch job, use PERL, if it's a program, use C/C++. In other words,
>if you were limited to using shell commands only, could you do it? If so, use
>PERL.
This is better reasoning then most of the objections to perl. but what perl
can do that scripts can't is be used as 'prototypers', as well as HLGL (high
level glue language). In addition anybody that has to do even large scale
work w/ strings, will find laughable the notion that C/C++/Java can match perl
in terms of programmer effieciency - they are painfully inept by comparison.
>Also, from my POV, PERL is treated as a programming language, which it's not.
>If you try to treat it like one, you will fail miserably in producing good
>code. Either it'll be illegible, unmaintainable, buggy, incomprehensible, or
>all of the above. You'll try to turn a program into a batch job, thereby
>producing a botch job instead.
maybe if you are writing a one-off, or like to write incomprehensible code
that's true, but i just finished a 1.5K line DB converter, and it's none of those
things - I'd post it, but my employer wouldn't be amused - nor would the group.
About 1/4 of it is comments, or white space for legibility.
>The only reason to move from C/C++ to PERL is that you can do many high-level
>useful things easily. PERL is not better than C/C++, it's just easier on the
>brain and fingers for high-level tasks.
look, i'm not perl uber alles - for instance, i wouldn't write geometry code
for a large CAD/CAM app, I'd use Fortran or C. I wouldn't write a DB Index
Miner where perf is critical in perl either, that's a C++/C job, but for most
other things I've worked on - hell yes!
>Michael J. Lewchuk
>jlewchuk@junctionnet.com
W
--
JAIPH (just another intermediate perl hacker)
"Do you want to go back to where I found you?
Friendless! Brainless! and unemployed, in Greenland?" - Princess Bride
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 4074
**************************************
