[8758] in Perl-Users-Digest
Perl-Users Digest, Issue: 2376 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Apr 21 22:07:36 1998
Date: Tue, 21 Apr 98 19:01:39 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 21 Apr 1998 Volume: 8 Number: 2376
Today's topics:
Question on exec and system <yong@shell.com>
Re: Question on exec and system (Abigail)
Re: Regular Expression to match a valid IP address <brobbins@tis.com>
Replacement without counting return ???? (Michael Haertfelder)
Re: Replacement without counting return ???? (Craig Berry)
Re: Replacement without counting return ???? <lr@hpl.hp.com>
Re: Sendmail Attach <jkry3025@comenius.ms.mff.cuni.cz>
Re: spoiled noobie <tchrist@mox.perl.com>
Re: suggested research methods? <jdporter@min.net>
Re: Symbolic ref and angle opeator <tchrist@mox.perl.com>
Re: Time : Year2000 & 2038 code question (John Moreno)
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 21 Apr 1998 11:42:10 -0500
From: Yong Huang <yong@shell.com>
Subject: Question on exec and system
Message-Id: <353CCC61.EACCAD3F@shell.com>
Programming Perl says if the args to the function exec contain
metacharacters, it launches sh -c, otherwise it does not fork, as the
function system does. My question is, is it true that if my arguments
are straight commands with no metacharacters, using exec is faster than
system (suppose they're both at the end of my script and I don't worry
if the execution doesn't come back)? I.e.,.exec "ls /tmp" is more
efficient than system "ls /tmp"? Also, exec "$myvar" is the same
efficient as system "$myvar" if $mytmp is defined as "ls /tmp" somewhere
earlier?
Thanks for advice and correction of my understanding if I'm wrong.
Yong Huang
Email:yong@shell.com
------------------------------
Date: 21 Apr 1998 18:47:09 GMT
From: abigail@fnx.com (Abigail)
Subject: Re: Question on exec and system
Message-Id: <6hipjd$agg$1@client2.news.psi.net>
Yong Huang (yong@shell.com) wrote on MDCXCIV September MCMXCIII in
<URL: news:353CCC61.EACCAD3F@shell.com>:
++ Programming Perl says if the args to the function exec contain
++ metacharacters, it launches sh -c, otherwise it does not fork, as the
++ function system does. My question is, is it true that if my arguments
++ are straight commands with no metacharacters, using exec is faster than
++ system (suppose they're both at the end of my script and I don't worry
++ if the execution doesn't come back)? I.e.,.exec "ls /tmp" is more
++ efficient than system "ls /tmp"? Also, exec "$myvar" is the same
++ efficient as system "$myvar" if $mytmp is defined as "ls /tmp" somewhere
++ earlier?
Before you wonder which one is more efficient, in 99.9% of the cases
system is used, you cannot replace it with exec.
Abigail
--
perl -pwle '$_ .= reverse'
------------------------------
Date: Mon, 20 Apr 1998 16:31:46 -0400
From: Bert Robbins <brobbins@tis.com>
To: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Regular Expression to match a valid IP address
Message-Id: <353BB0B1.6BDC@tis.com>
Tom Christiansen wrote:
>
> In comp.lang.perl.misc,
> Tony Curtis <Tony.Curtis+usenet@vcpc.univie.ac.at> writes:
> :An IP address expressed in dotted-quad form consists of 4
> :sequences of decimal digits, separated by `.'
>
> Not all valid IP addrs are dotted quads!
>
What is the basis for this assertion? I know that some interfaces
to IP addresses allow an entry of "10.1" which the interface
expands to "10.0.0.1".
Thanks
Bert
------------------------------
Date: 21 Apr 1998 18:44:00 +0200
From: haert@wharp.rhein-main.de (Michael Haertfelder)
Subject: Replacement without counting return ????
Message-Id: <6sImuiQkZZB@wharp.rhein-main.de>
Suppose we have:
$var = "blubb";
print "Replaced: ".$var =~ tr/b/k/."\n";
print $var."\n";
the result will be:
Replaced: 3
klukk
Is it possible to get
Replaced: klukk
as a oneliner ?
Thanx in advance
Michael
------------- Michael Haertfelder Frankfurt/Main, Germany ----------------
------------- http://odb.rhein-main.de/people/haertfelder/ ----------------
------------------------------
Date: 21 Apr 1998 17:37:45 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Replacement without counting return ????
Message-Id: <6hilha$m14$1@marina.cinenet.net>
Michael Haertfelder (haert@wharp.rhein-main.de) wrote:
: Suppose we have:
:
: $var = "blubb";
: print "Replaced: ".$var =~ tr/b/k/."\n";
: print $var."\n";
:
: the result will be:
:
: Replaced: 3
: klukk
:
: Is it possible to get
:
: Replaced: klukk
:
: as a oneliner ?
print 'Replaced: '.($var =~ tr/b/k/, $var)."\n";
is one way.
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| Member of The HTML Writers Guild: http://www.hwg.org/
"Every man and every woman is a star."
------------------------------
Date: Tue, 21 Apr 1998 11:07:03 -0700
From: "Larry Rosler" <lr@hpl.hp.com>
Subject: Re: Replacement without counting return ????
Message-Id: <6hin80$9d3@hplntx.hpl.hp.com>
lr@hpl.hp.com
Michael Haertfelder wrote in message
<6sImuiQkZZB@wharp.rhein-main.de>...
>Suppose we have:
>
>$var = "blubb";
>print "Replaced: ".$var =~ tr/b/k/."\n";
>print $var."\n";
>
>the result will be:
>
>Replaced: 3
>klukk
>
>Is it possible to get
>
>Replaced: klukk
>
>as a oneliner ?
print "Replaced: " . ($var =~ tr/b/k/, $var) . "\n";
I have added spaces around the concatenation operators for clarity.
--
Larry Rosler
Hewlett-Packard Laboratories
------------------------------
Date: Tue, 21 Apr 1998 22:11:53 -0700
From: Jan Krynicky <jkry3025@comenius.ms.mff.cuni.cz>
To: InterRed <grupo@nevado.cui.edu.co>
Subject: Re: Sendmail Attach
Message-Id: <353D7C19.6212@comenius.ms.mff.cuni.cz>
InterRed wrote:
>
> How can I send email with attach!...
>
> thanks!
( I will suppose that you need to do this from a script. )
use Mail::Sender;
# http://www.chipnet.cz/depot/perl.htm
HTH, Jenda
------------------------------
Date: 21 Apr 1998 13:59:05 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: spoiled noobie
Message-Id: <6hi8n9$ner$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
kpreid@ibm.net (Kevin Reid) writes:
:$var =~ s/......
:
:That's about as elegant as it gets.
Why are you asnwering FAQs in-line, and wrongly? That's why we write
FAQs -- so people get the right answers. It's also why all FAQs should be
answered with a pointer to the same. Anything else is counterproductive.
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
Can you sum up plan 9 in layman's terms? It does everything
Unix does only less reliably --Ken Thompson
------------------------------
Date: Tue, 21 Apr 1998 17:07:59 GMT
From: John Porter <jdporter@min.net>
Subject: Re: suggested research methods?
Message-Id: <353CD3EF.2598@min.net>
lvirden@cas.org wrote:
>
> According to John Porter <jdporter@min.net>:
> :Bill 'Sneex' Jones wrote:
> :>
> :
> :> I try to 'read' CPAN as often as possible...(I printed out the 'long'
> :> version...)
> :
> :YOU PRINTED IT OUT?
>
> Of course, Bill wasn't specific as to _what_ he printed out. However,
> note that he didn't say "I printed out the stuff and then deleted the
> online version" - printing is not necessarily useless. Having online
> searchable text is useless to me when I have no keyboard/processor/monitor/modem
> handy or with the data on the disk... Sometimes, having paper
> to read is useful.
>
> Bill, do you mean that you printed out every pod on CPAN? Or the long
> version of the 'catalog' of CPAN modules that are available? I suspect
> the latter...
Yeah, I do too, and it's a waste unless one's intention is to memorize
the list of module names. Hey, maybe that's not so bad. Then when one
asks on clpm, "How can I interface Perl to the powerful PARI library?",
one can respond "Why, the Math::Pari module, of course!" without
looking.
But usually, when I see that question come up, I'm in a position where
I can search in the long list.
As I said, a waste.
John Porter
------------------------------
Date: 21 Apr 1998 14:25:21 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Symbolic ref and angle opeator
Message-Id: <6hia8h$ooi$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
Matt Knecht <hex@voicenet.com> writes:
:I'm having a problem trying to get a symbolic reference to work with
:the angle operator.
Lamentably, the circumfix operator sometimes called the diamond operator,
especially when used without a circumscribed operand, simply cannot be
used as you want to use it. This operator, like indirect filehandles
and other indirect objects, has a *VERY RESTRICTED SYNTAX*. When the
documentation says "scalar variable name", it means precisely that.
You are assuming it means "scalar expression". It does not mean that,
which is why it doesn't say that! A name is not always an expression.
You are
inferring that just because one can use an expression in some places,
that one can also use an expression everywhere. That's simply false.
You are, in effect, assuming that
open($f[$i], $path);
implies than one should also be able to say
$line = <$f[$i]>;
or by extension,
print $f[$i] $line;
But in fact, and much to the surprise of multitudes down through the
many ages of Perl, you can't. The standard Perl documentation explains
this unambiguously. Here's an excerpt from perlop:
If the string inside the angle brackets is a reference to a scalar
variable (e.g., <$foo>), then that variable contains the name of the
filehandle to input from, or a reference to the same. For example:
$fh = \*STDIN;
$line = <$fh>;
-> If the string inside angle brackets is not a filehandle or a
-> scalar variable containing a filehandle name or reference, then
it is interpreted as a filename pattern to be globbed, and either
a list of filenames or the next filename in the list is returned,
depending on context. One level of $ interpretation is done first,
but you can't say <$foo> because that's an indirect filehandle as
explained in the previous paragraph.
Here's a bit form perlfunc:
print Prints a string or a comma-separated list of strings.
Returns TRUE if successful. FILEHANDLE may be a scalar
variable name, in which case the variable contains the name
of or a reference to the filehandle, thus introducing one
level of indirection.
[...deletia...]
-> Note that if you're storing FILEHANDLES in an array or other
-> expression, you will have to use a block returning its value
instead:
print { $files[$i] } "stuff\n";
print { $OK ? STDOUT : STDERR } "stuff\n";
So, while $foo is a scalar variable name for these purposes, $foo[$i]
is not, nor is $foo->{FH}. You cannot use them interchangeably. I know
this sucks. I know it seems to make no sense. And I know it's just
something you're going to have to learn to cope with.
Here's what you have to do: either use the built-in function readline(),
or else use the IO::Handle method ->getline(). The funny thing about
readline() is it must take a glob -- not a string representing a handle,
not a glob reference, not a handle reference. Just a glob.
That means that these all silently fail:
$ echo testing | perl -e 'print readline(STDIN)'
$ echo testing | perl -e 'print readline("STDIN")'
$ echo testing | perl -e 'print readline(*IO{STDIN})'
$ echo testing | perl -e 'print readline(\*STDIN)'
And that this alone works:
$ echo testing | perl -e 'print readline(*STDIN)'
testing
You can store the glob into anything you'd like.
$ echo testing | perl -e '$p->{X} = *STDIN; print readline($p->{X})'
testing
If you use one of the IO modules, then you will be able to call IO methods
like getline() on either references blessed into the proper class,
or on strings or raw globs -- but not on unblessed glob references.
These all work:
$ echo testing | perl -MIO::Handle -e 'print STDIN->getline'
testing
$ echo testing | perl -MIO::Handle -e '$f = STDIN; print $f->getline'
testing
$ echo testing | perl -MIO::Handle -e '$f = *STDIN; print $f->getline'
testing
But this one fails more spectacularly:
$ echo testing | perl -MIO::Handle -e '$f = \*STDIN; print $f->getline'
Can't call method "getline" on unblessed reference at -e line 1.
This should point the way to a solution to your particular problem.
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
Just don't compare it with a real language, or you'll be unhappy... :-)
--Larry Wall in <1992May12.190238.5667@netlabs.com>
------------------------------
Date: Tue, 21 Apr 1998 18:22:14 GMT
From: phenix@interpath.com (John Moreno)
Subject: Re: Time : Year2000 & 2038 code question
Message-Id: <1d7u7mb.1rj7zdk10juxq1N@roxboro0-025.dyn.interpath.net>
Mark-Jason Dominus <mjd@op.net> wrote:
> Tony Moran <tmoran@iol.ie> wrote:
> > Hi, in reviewing perl code for compliancy, I came across this in
> > a function that calls localtime() and then does:
> >
> > $year += ($year < 70) ? 2000 : 1900;
>
> In article <1d7tzkz.171m2y71dk1s0xN@roxboro0-025.dyn.interpath.net>,
> John Moreno <phenix@interpath.com> wrote:
> >whoever was doing this was trying to be paranoid (always a good thing)
> >but didn't think things out...unfortunately if the right thing IS done, his
> >program will fail.
>
> No, it won't. If, in 2005, `localtime' yields 105, the way it's
> supposed to, then he correctly translates the 105 to 2005. Neither
> you nor the other guy who answered the question in this thread saw
> this.
Actually I did see it and misspoke (but how are you to realize that?).
It does fail in so much as it is useless - it looks to me like he was
trying to account for a failure in localtime after 2038 (quite a bit of
it now would choke on a 2040 time and return a year of 2 - but I expect
all of those to be fixed in the next 40 years). If it is fixed then it
never get's called. If it's NOT fixed then the date it gives will be
2002 in 2040.
> The only time this can fail is if for some reason `$year' initially
> holds a number that represents a year earlier than 1970. Then the
> code will interpret the year incorrectly as a next-century year rather
> than a this-century year. If $year always comes from localtime, that
> can't happen because it's 1998 now.
>
> >And possibly he wasn't paranoid enough - if the script could possibly be
> >ported to the mac, then it's possible to have a year less than 70 now
>
> Yes, but not as a localtime. Unless, as you note, the clock is
> mis-set. So the question becomes: Is it more important to operate
> correctly when the clock is mis-set, or in the presence of a broken
> localtime implementation?
>
> There's some tradeoff here. There are two conditions, leading to six
> possible universes:
>
> * You might have a good localtime, or you might have a broken one that
> returns 10 in year 2010.
No, I don't think this can happen (well it COULD, but I'm pretty sure
you'd have to do it deliberately).
-snip-
>
> Let's think of the programmer with a good reason for a minute. If
> some Studebaker fancier resets the system clock to say it's 1907
> again, the variant code breaks. In this case the programmer must say
> ``Sorry. My program wasn't designed to work in 1907. It's a
-snip-
> If this programmer had used the correct code, they might have to say
> in 2001: ``Sorry that my program thinks it's 1901, but NanoTech OU has
> a broken date library. I knew this, and I could have worked around
> it, but I didn't. Tough luck.''
>
> If I were this programmer, I would prefer to say the first thing.
>
> Of course, it's more likely that the programmer didn't know what they
> were doing, but I don't think you can conclude that from this code
> fragment.
Conclude it absolutely, positively, without a shadow of a doubt, no.
But as the most reasonable conclusion - yes. Since the only thing
broken about localtime is that on some systems it currently won't work
correctly after sometime in 2038, then I assume that THAT was the
problem he was trying to fix - and if that is the case his code doesn't
work, if it's not the case then he's trying to fix a problem that
doesn't exist and potentially introducing a factor which would make the
problem that does exist harder to track down (37/8 versus 137/8) if it
hasn't been fixed by then (which I am confident that it will be, either
that or that those systems won't be working then).
--
John Moreno
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
Message-Id: <null>
Administrivia:
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 2376
**************************************
