[24203] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 6395 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Apr 13 14:05:55 2004

Date: Tue, 13 Apr 2004 11:05:12 -0700 (PDT)
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, 13 Apr 2004     Volume: 10 Number: 6395

Today's topics:
    Re: cgi-bin gui testing <glex_nospam@qwest.invalid>
        Changing from C thought to Perl <Tigerhillsider@netscape.net>
    Re: Changing from C thought to Perl <perl@my-header.org>
    Re: Changing from C thought to Perl <wherrera@lynxview.com>
    Re: Changing from C thought to Perl <vetro@online.no>
    Re: Changing from C thought to Perl <Tigerhillsider@netscape.net>
    Re: Changing from C thought to Perl <Tigerhillsider@netscape.net>
    Re: Changing from C thought to Perl <vetro@online.no>
        die-ing within functions <auto87829@hushmail.com>
    Re: die-ing within functions <for-spammers-only@web.de>
    Re: die-ing within functions <perl@my-header.org>
    Re: die-ing within functions <spamtrap@dot-app.org>
    Re: die-ing within functions (Anno Siegel)
    Re: die-ing within functions <xxala_qumsiehxx@xxyahooxx.com>
    Re: download my bbs... <tore@aursand.no>
    Re: Finding URL in Textfield, then editing it (Mike)
        format data in array to 2 decimal places. <olusola.o.olaode@intel.com>
    Re: format data in array to 2 decimal places. <richard@zync.co.uk>
    Re: format data in array to 2 decimal places. <richard@zync.co.uk>
    Re: format data in array to 2 decimal places. <vetro@online.no>
    Re: how to do a reverse ip lookup of a DNS server ? (joe shaboo)
    Re: Many filename arguments: EOF in "while(@slurp=<>){. <tadmc@augustmail.com>
    Re: Multiple replaces (Motti)
    Re: Multiple replaces (Anno Siegel)
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Tue, 13 Apr 2004 12:01:54 -0500
From: "J. Gleixner" <glex_nospam@qwest.invalid>
Subject: Re: cgi-bin gui testing
Message-Id: <92Vec.17$9t1.32006@news.uswest.net>

Charlie wrote:
> Hi Folks, 
> I need some tips about this issue I have now: 
>     I am testing an application now, which is written in perl, and
> connecting to the Backend MySQL. [...]

You're wanting to test its Web interface, so it doesn't matter what it's 
written in, or the backend or anything else.

>   The 80% of the UI testing works are: clieck the tab button to enter
> a new web page, filled in the areas that are needed, and click the
> submit button. My first idea is to us the winRunner for the automated
> testing work, but on my second thought, since the application is
> written in PERL, maybe I can use some existing PERL modules to do the
> testing work, such as LWP, HTTP::Request, HTTP::Response,
> HTML::Parser, etc to implement the test applications.
> 
> All I want to know are: 
> 1. which one you think is a better way to do this kind of testing
> work?

If you're well versed on winRunner and it does what you need, use it. It 
doesn't matter what language is used to create the Web interface, you're 
testing it via HTTP.

> 2. If I was going to use the PERL, are the modules I mentioned above
> the very latest ONEs, or there are some more powerful ones that I may
> look for.

WWW::Mechanize

which relies on those modules to access the Web interface and Test::More 
which lets you easily check if something is on the page or not.

See Randal's columns:
http://www.stonehenge.com/merlyn/LinuxMag/col53.html
http://www.stonehenge.com/merlyn/LinuxMag/col54.html

> 3. The test cases need to be running on solaris, linux and window. 

Be sure to test using different browsers.

See ya


------------------------------

Date: Tue, 13 Apr 2004 13:45:52 GMT
From: Tigerhillside <Tigerhillsider@netscape.net>
Subject: Changing from C thought to Perl
Message-Id: <scrn701n7amaig8ism9l81588cblhvjrrc@4ax.com>

I am trying to understand Perl and having a hard time. I was a
pretty good C programmer, but Perl seems to make much more sense
for the kinds of things I am doing now. But I am having problems
making it "intuitive". From my perspective Perl seems full of
"side effects", I do something and some pre-defined variable
changes. I was "taught" that side effects and (essentially)
global variables are a "bad thing". ISTM that I have to keep some
internal (to me) table of these variables in mind when I code.
Has anyone else moved from C to Perl who has some advice. (I know
the best advice is to write and read and I am doing that.)  Maybe
it will just take time and all these things will become second
nature. 




------------------------------

Date: Tue, 13 Apr 2004 16:10:41 +0200
From: Matija Papec <perl@my-header.org>
Subject: Re: Changing from C thought to Perl
Message-Id: <rnsn70hrpo29cbv2r64lgav797ca2p4rqc@4ax.com>

X-Ftn-To: Tigerhillside 

Tigerhillside <Tigerhillsider@netscape.net> wrote:
>I am trying to understand Perl and having a hard time. I was a
>pretty good C programmer, but Perl seems to make much more sense
>for the kinds of things I am doing now. But I am having problems
>making it "intuitive". From my perspective Perl seems full of
>"side effects", I do something and some pre-defined variable
>changes. I was "taught" that side effects and (essentially)
>global variables are a "bad thing". ISTM that I have to keep some
>internal (to me) table of these variables in mind when I code.
>Has anyone else moved from C to Perl who has some advice. (I know
>the best advice is to write and read and I am doing that.)  Maybe
>it will just take time and all these things will become second
>nature. 

Most of the time it's more convenient to use explicit syntax,
for my $el (@arr) {
  # work with $el
}
while (my $line = <FH>) {
  # work with $line
}

instead of,
====================
for (@arr) {
  # work with $_
}
while (<FH>) {
  # work with $_
}



-- 
Matija


------------------------------

Date: Tue, 13 Apr 2004 08:22:08 -0600
From: Bill <wherrera@lynxview.com>
Subject: Re: Changing from C thought to Perl
Message-Id: <wt6dnbxk1KISaubdRVn-gQ@adelphia.com>

Tigerhillside wrote:
> I am trying to understand Perl and having a hard time. I was a
> pretty good C programmer, but Perl seems to make much more sense
> for the kinds of things I am doing now. But I am having problems
> making it "intuitive". From my perspective Perl seems full of
> "side effects", I do something and some pre-defined variable
> changes. I was "taught" that side effects and (essentially)
> global variables are a "bad thing". 

If you want to do so, you can almost always use a named variable in Perl 
where it also accepts a default one. I.e.

for my $i (@array) {
   $i =~ s/a/the/;
}
instead of

for (@array) { s/a/the/ }


ISTM that I have to keep some
> internal (to me) table of these variables in mind when I code.
> Has anyone else moved from C to Perl who has some advice. (I know
> the best advice is to write and read and I am doing that.)  Maybe
> it will just take time and all these things will become second
> nature. 
> 
> 

Former and current c and c++ coders can write perl as if it were c with 
regexes and a lot of convenient builtin functions, though it makes for 
more verbose code. (I tend that way, so I know :)). After a while, 
though, you begin to appeciate Perl's way as easier to read and more 
concise in many casdes: you can say foo($a) if $b; instead of if($b) { 
foo($a); }, for example.

I wonder if there shouldn't be a 'no use implied vars' for enforcing the 
avoidance of $_ sometimes.

YMMV



------------------------------

Date: Tue, 13 Apr 2004 17:41:49 +0200
From: Vetle Roeim <vetro@online.no>
Subject: Re: Changing from C thought to Perl
Message-Id: <m365c3hole.fsf@quimby.dirtyhack.org>

* Tigerhillsider@netscape.net
> I am trying to understand Perl and having a hard time. I was a
> pretty good C programmer, but Perl seems to make much more sense
> for the kinds of things I am doing now. But I am having problems
> making it "intuitive".

  Well... C and Perl are vastly different programming languages, so
  it's no wonder you're having problems. :)

  I wrote a little C a few weeks back when examining how to implement
  extensions in C, and it took me a while to remember how to do
  anything in C.


> From my perspective Perl seems full of "side effects", I do
> something and some pre-defined variable changes.

  In many cases you can use explicit variable names instead of using
  the special variables... But they my help in making code more
  elegant when you get used to them.


[...]



-- 
#!/usr/bin/vr


------------------------------

Date: Tue, 13 Apr 2004 16:29:09 GMT
From: Tigerhillside <Tigerhillsider@netscape.net>
Subject: Re: Changing from C thought to Perl
Message-Id: <525o70t12rc3vgp8ic1kfu00ecciitauqh@4ax.com>

In comp.lang.perl.misc, Bill <wherrera@lynxview.com>, I read and
responded

>Tigerhillside wrote:
>> I am trying to understand Perl and having a hard time. I was a
>> pretty good C programmer, but Perl seems to make much more sense
>> for the kinds of things I am doing now. But I am having problems
>> making it "intuitive". From my perspective Perl seems full of
>> "side effects", I do something and some pre-defined variable
>> changes. I was "taught" that side effects and (essentially)
>> global variables are a "bad thing". 
>
>If you want to do so, you can almost always use a named variable in Perl 
>where it also accepts a default one. I.e.
>
>for my $i (@array) {
>   $i =~ s/a/the/;
>}
>instead of
>
>for (@array) { s/a/the/ }
>

This is the kind of stuff I have been (trying, at lest) doing. I
was not the kind of C programmer who tried to minimize the number
of keys pressed, I liked open "transparent"* code. So if I don't
take a big processing hit I would like to do Perl that way as
well.

* Funny how a word jumps into pubic discourse and finds so many
uses. Government/code/etc. should be transparent.


>ISTM that I have to keep some
>> internal (to me) table of these variables in mind when I code.
>> Has anyone else moved from C to Perl who has some advice. (I know
>> the best advice is to write and read and I am doing that.)  Maybe
>> it will just take time and all these things will become second
>> nature. 
>> 
>> 
>
>Former and current c and c++ coders can write perl as if it were c with 
>regexes and a lot of convenient builtin functions, though it makes for 
>more verbose code. (I tend that way, so I know :)). After a while, 
>though, you begin to appeciate Perl's way as easier to read and more 
>concise in many casdes: you can say foo($a) if $b; instead of if($b) { 
>foo($a); }, for example.
>
>I wonder if there shouldn't be a 'no use implied vars' for enforcing the 
>avoidance of $_ sometimes.
>
>YMMV

Thanks. And to Matija as well.




------------------------------

Date: Tue, 13 Apr 2004 16:31:33 GMT
From: Tigerhillside <Tigerhillsider@netscape.net>
Subject: Re: Changing from C thought to Perl
Message-Id: <6c5o70pimtjev5drf5n913kh5494q8arbr@4ax.com>

In comp.lang.perl.misc, Vetle Roeim <vetro@online.no>, I read and
responded

>* Tigerhillsider@netscape.net
>> I am trying to understand Perl and having a hard time. I was a
>> pretty good C programmer, but Perl seems to make much more sense
>> for the kinds of things I am doing now. But I am having problems
>> making it "intuitive".
>
>  Well... C and Perl are vastly different programming languages, so
>  it's no wonder you're having problems. :)
>
>  I wrote a little C a few weeks back when examining how to implement
>  extensions in C, and it took me a while to remember how to do
>  anything in C.

I can hold 1.5 languages at a time unless I use them ever week.
Unfortunately that sometimes that means I have 3/4 of two
languages.
>
>> From my perspective Perl seems full of "side effects", I do
>> something and some pre-defined variable changes.
>
>  In many cases you can use explicit variable names instead of using
>  the special variables... But they my help in making code more
>  elegant when you get used to them.

I will allow elegance to come with time (and taste). Is it a
meaningful performance hit?

>[...]



------------------------------

Date: Tue, 13 Apr 2004 19:23:47 +0200
From: Vetle Roeim <vetro@online.no>
Subject: Re: Changing from C thought to Perl
Message-Id: <m38ygz3i70.fsf@quimby.dirtyhack.org>

* Tigerhillsider@netscape.net
> In comp.lang.perl.misc, Vetle Roeim <vetro@online.no>, I read and
> responded
>
>>* Tigerhillsider@netscape.net
[...]
>>> From my perspective Perl seems full of "side effects", I do
>>> something and some pre-defined variable changes.
>>
>>  In many cases you can use explicit variable names instead of using
>>  the special variables... But they my help in making code more
>>  elegant when you get used to them.
>
> I will allow elegance to come with time (and taste). 

  Of course. TMTOWTDI. :)


> Is it a meaningful performance hit?

  Errr... Well... I'm not sure, but I'd *guess* that using some of the
  special variables may improve performance, as you don't have to go
  around declaring new variables (whatever the performance hit for
  that is).


-- 
#!/usr/bin/vr


------------------------------

Date: Wed, 14 Apr 2004 00:21:00 +1000
From: "Stevens" <auto87829@hushmail.com>
Subject: die-ing within functions
Message-Id: <407bf74c$0$4547$afc38c87@news.optusnet.com.au>

Hi,

I'm looking for some advice on programming style ... is is considered bad
practice to die within your own functions as opposed to using a bare return
statement?  What about displaying error messages within perl functions, is
this frowned (as it tends to be in unix systems programming) upon?

Cheers,

Stevens




------------------------------

Date: Tue, 13 Apr 2004 16:42:49 +0200
From: Toni Erdmann <for-spammers-only@web.de>
Subject: Re: die-ing within functions
Message-Id: <407BFC69.8090607@web.de>

Stevens wrote:
> Hi,
> 
> I'm looking for some advice on programming style ... is is considered bad
> practice to die within your own functions as opposed to using a bare return
> statement?  What about displaying error messages within perl functions, is
> this frowned (as it tends to be in unix systems programming) upon?

You should perfer using 'return undef;' if possible to indicate an
error. If, however you find a severe error during operation within
a function, it's better to use 'die' instead of 'exit'.

sub function
{
     ...
     die "Error";
}

can be handled by the calling code:

eval { function() };
if ( $@ ) {
     warn "function() caused an exception: $@";
}

which can't be done using 'exit' in 'function()'

If there's no 'eval{}' around the call, then it simply 'die's.

I always try to avoid 'print' in subroutines and try to
'return undef;' instead.

Toni


------------------------------

Date: Tue, 13 Apr 2004 16:40:38 +0200
From: Matija Papec <perl@my-header.org>
Subject: Re: die-ing within functions
Message-Id: <3run70h750iutnq83bo69muutnthjiavfn@4ax.com>

X-Ftn-To: Stevens 

"Stevens" <auto87829@hushmail.com> wrote:
>I'm looking for some advice on programming style ... is is considered bad
>practice to die within your own functions as opposed to using a bare return
>statement?  What about displaying error messages within perl functions, is

IMO, dying is fine as you can always catch these with eval {  };



-- 
Matija


------------------------------

Date: Tue, 13 Apr 2004 11:03:27 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: die-ing within functions
Message-Id: <VpidnW-oCc-qnOHdRVn-ug@adelphia.com>

Stevens wrote:

> I'm looking for some advice on programming style ... is is considered bad
> practice to die within your own functions as opposed to using a bare
> return statement?

So long as it's documented as doing so, I don't see why it would be all that
bad. Even if the default of die()ing isn't appropriate for some cases, it's
not a fatal flaw; it can always be trapped by an eval().

> What about displaying error messages within perl functions, is 
> this frowned (as it tends to be in unix systems programming) upon?

I'd use warnings::warnif(), so that the user of the function could disable
the warnings as he sees fit, with "no warnings 'MyPackage';". (This is one
way the 'warnings' pragmatic module is much, much, much better than the
simplistic '-w' switch...)

Another option is to place the warning message in a scalar, and then call
'warnings::warnif($error_message);'. This would allow users of your
function to disable the standard behavior, and display the warning in a way
that's more appropriate for their app, for example by popping up a GUI
dialog.

sherm--

-- 
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org


------------------------------

Date: 13 Apr 2004 17:27:50 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: die-ing within functions
Message-Id: <c5h7um$c15$1@mamenchi.zrz.TU-Berlin.DE>

Stevens <auto87829@hushmail.com> wrote in comp.lang.perl.misc:
> Hi,
> 
> I'm looking for some advice on programming style ... is is considered bad
> practice to die within your own functions as opposed to using a bare return
> statement?  What about displaying error messages within perl functions, is
> this frowned (as it tends to be in unix systems programming) upon?

Unconditionally dying in library routines is bad style anywhere.  The only
place for it is bug catching (that is, dying under conditions that cannot
happen when the program is correct).

Now one could argue that Perl has eval(), and hence dying is never truly
unconditional, but that solution should be reserved for cases where a
function *does* die inappropriately.  If the user has to undo things a
routine has done, the routine is doing (and assuming) too much, that goes
for dying as for other services.

The pragmatic "warnings" module offers a solution in that it allows the
user to control the behavior (ignore, warn, die).  However, I hesitate
to recommend it unconditionally.  The control it gives is somewhat
flakey, and a warning can consume considerable time even if it is
turned off.  Both problems have to do with the fact that "warnings"
uses "Carp" to do the error attribution.

However, the spirit of "warnings" is the way it should be.  It's the
end users who ought to control behavior under error conditions (with
reasonable defaults, so they don't *have* to).  Only they know what the
consequences are if something goes wrong.

Anno


------------------------------

Date: Tue, 13 Apr 2004 17:34:18 GMT
From: "Ala Qumsieh" <xxala_qumsiehxx@xxyahooxx.com>
Subject: Re: die-ing within functions
Message-Id: <uwVec.22196$0E.17909@newssvr27.news.prodigy.com>

"Stevens" <auto87829@hushmail.com> wrote in message
news:407bf74c$0$4547$afc38c87@news.optusnet.com.au...
> Hi,
>
> I'm looking for some advice on programming style ... is is considered bad
> practice to die within your own functions as opposed to using a bare
return

IMHO, there is nothing wrong with die()ing [sic] within a function if it
doesn't make sense for the program to continue running afterwards.

> statement?  What about displaying error messages within perl functions, is
> this frowned (as it tends to be in unix systems programming) upon?

It really depends on your style. I don't think perlstyle says anything about
that. I certainly don't mind spitting out error/warning messages from within
functions since I generally think of functions as OO methods. So each
function is supposed to do one thing only, and if it fails, then it is its
responsibility to report that.

--Ala




------------------------------

Date: Tue, 13 Apr 2004 15:46:07 +0200
From: Tore Aursand <tore@aursand.no>
Subject: Re: download my bbs...
Message-Id: <pan.2004.04.13.12.48.16.336129@aursand.no>

On Tue, 13 Apr 2004 12:43:34 +0100, Alan J. Flavell wrote:
>>> Includes a really cool admin script and a cool header and footer.

>> Could you please include this additional information about your script?
>>
>>   * It's insecure.
>>   * It's a good example on how _not_ to program.
>> [...]

> Don't you think that the use of the word "cool", even once, would have
> been enough to warn any serious users off?

Yes.  But I wasn't talking about serious users;  Even not-so-serious
users, who think "cool" is cool, should avoid scripts from this guy.  He
makes Matt's scripts look cool.


-- 
Tore Aursand <tore@aursand.no>
"What we see depends mainly on what we look for." -- Sir John Lubbock


------------------------------

Date: 13 Apr 2004 10:40:15 -0700
From: csdude@hotmail.com (Mike)
Subject: Re: Finding URL in Textfield, then editing it
Message-Id: <46cdc619.0404130940.3dce933c@posting.google.com>

> Yes.  Did you consult CPAN before you posted here?  Me thinks you didn't,
> and it's a shame that you'd had to wait this long:
> 
>   URI::Find
> 
> :-)

Ach, I'm a very bad person!

I actually did try CPAN before posting, but not knowing what to search
for I didn't find anything helpful. Oddly enough, I searched Google,
too, and didn't see a reference to this module.

Oh, well, maybe the next guy doing this will find this thread!

Thanks again for your help,

Mike


------------------------------

Date: Tue, 13 Apr 2004 13:16:12 -0400
From: "fenisol3" <olusola.o.olaode@intel.com>
Subject: format data in array to 2 decimal places.
Message-Id: <c5h78s$9hq$1@news01.intel.com>

Hi,

How do I format the data in an array to 2 decimal places?
Thanks to all those who answer this question.

-fenisol3




------------------------------

Date: Tue, 13 Apr 2004 18:32:54 +0100
From: "Richard Gration" <richard@zync.co.uk>
Subject: Re: format data in array to 2 decimal places.
Message-Id: <c5h887$am0$1@news.freedom2surf.net>

In article <c5h78s$9hq$1@news01.intel.com>, "fenisol3"
<olusola.o.olaode@intel.com> wrote:


> Hi,
> How do I format the data in an array to 2 decimal places? Thanks to all
> those who answer this question.  -fenisol3
> 

$_ = sprintf ".2f",$_ for (@ary);

There might be a shorter way to do it ...

R


------------------------------

Date: Tue, 13 Apr 2004 18:33:37 +0100
From: "Richard Gration" <richard@zync.co.uk>
Subject: Re: format data in array to 2 decimal places.
Message-Id: <c5h89i$am0$2@news.freedom2surf.net>

In article <c5h887$am0$1@news.freedom2surf.net>, "Richard Gration"
<richard@zync.co.uk> wrote:


> In article <c5h78s$9hq$1@news01.intel.com>, "fenisol3"
> <olusola.o.olaode@intel.com> wrote:
> 
>> Hi,
>> How do I format the data in an array to 2 decimal places? Thanks to all
>> those who answer this question.  -fenisol3
> $_ = sprintf ".2f",$_ for (@ary);
> There might be a shorter way to do it ...  R

Damn. "%.2f" of course.


------------------------------

Date: Tue, 13 Apr 2004 19:38:15 +0200
From: Vetle Roeim <vetro@online.no>
Subject: Re: format data in array to 2 decimal places.
Message-Id: <m31xmr3hiw.fsf@quimby.dirtyhack.org>

* Richard Gration
> In article <c5h78s$9hq$1@news01.intel.com>, "fenisol3"
> <olusola.o.olaode@intel.com> wrote:
>
>> Hi,
>> How do I format the data in an array to 2 decimal places? Thanks to all
>> those who answer this question.  -fenisol3
>> 
>
> $_ = sprintf ".2f",$_ for (@ary);

  That should be "%.2f", right? :)


[...]

-- 
#!/usr/bin/vr


------------------------------

Date: 13 Apr 2004 06:09:20 -0700
From: jshaboo@hotmail.com (joe shaboo)
Subject: Re: how to do a reverse ip lookup of a DNS server ?
Message-Id: <f6d34657.0404130509.3503c297@posting.google.com>

"PHP2" <gp@nospm.hr> wrote in message news:<c5efqg$78l$1@ls219.htnet.hr>...
> how to do a reverse ip lookup of a DNS server ?
> I mean when I check server IP that I see all domains connected to this IP on
> the server..
> 
> http://www.whois.sc/ has same function..

if you are asking to do a reverse look up on an ip address, this can
be done with
dig -x 216.239.32.10

This will give you the reverse lookup. If you want to see all A
records in a zone, then you will need to be able to transfer from that
zone. DNS is restrictive for security purposes, so that the public can
not do this by default.

joe


------------------------------

Date: Tue, 13 Apr 2004 09:09:22 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Many filename arguments: EOF in "while(@slurp=<>){..}"?
Message-Id: <slrnc7nt4i.8am.tadmc@magna.augustmail.com>

Fred Ma <fma@doe.carleton.ca> wrote:
> Tad McClellan wrote:
>> Fred Ma <fma@doe.carleton.ca> wrote:
>> 
>> > This was in order to understand
>> > how perl recognizes different files so that it can rename the
>> > originals, the case of "-i.bak".
>> 
>> >    #!/bin/perl -w
>> >    my @slurp;
>> >    while (@slurp=<>) {
>> 
>> Why a while() rather than the more usual foreach() ?
> 
> Haven't gotten to foreach yet.  I just wanted to understand at the
> fundamental level the simple examples I encountered in the perldoc.  


But putting "@slurp=<>" in the while condition makes a simple
example into a complicated example.

The complications can get in the way of figuring out what is
going on...


> I
> already have 4 xterms open to various pieces of perldoc, so I'm taking
> a bite at a time.


Have you read the "I/O Operators" section in perlop.pod yet?

In particular, the part that starts with "The null filehandle <> is special".


>> The 1st iteration will read all of the lines from all of the
>> files named in @ARGV (at which point @ARGV will be empty).
>> 
>> The 2nd iteration will read lines from STDIN since @ARGV is empty.
> 
> Does this mean that the file handle in the 1st case are bound to the
> actual files themselves (one after another), 


Yes.


> while in the 2nd case,
> the lines of those files are somehow made to come from stdin?


No. It is not "the lines of those files" on STDIN, it is whatever
is actually _on_ STDIN.


> Does the elements of @argv actually get consumed?  


Nope. The elements of @ARGV actually get consumed though.

Case matters.


> I'm trying to find
> this in the perldoc....


From the above-mentioned docs section:

   It really does shift the @ARGV array



>> > Why is the
>> > cursor waiting under the "D" until I press ^D?
                                        ^^^^^^^^^^
                                        ^^^^^^^^^^

>> > but why isn't "DOG" printed again and again, forever?
>> 
>> Because @slurp is coming up empty.
> 
> Actually, based on your description, I would picture it more like
> @slurp=<> hasn't even come back; it's still waiting for input.


You said you pressed ctrl-D, which marks the end of file for STDIN,
so STDIN _is_ coming up empty.

Try typing in a few lines before hitting ctrl-D.


>> > And why this
>> > hanging only for @slurp?
>> 
>> Your use of while() here has even me confused.
>> 
>>     @slurp=<>
>> 
>> is in scalar context (all booleans are scalar context).
>> The <> expression is in list context, so it should give "all the lines"
>> behavior.
> 
> I extrapolated based on what I saw in perldoc perlintro:
> 
>    |   You can read from an open filehandle using the <> operator. In
>    |   scalar context it reads a single line from the filehandle, and
>    |   in list context it reads the whole file in, assigning each line
>    |   to an element of the list: 
>    |
>    |       my $line  = <INFILE>;
>    |       my @lines = <INFILE>;  
>    |
>    |   Reading in the whole file at one time is called slurping. It
>    |   can be useful but it may be a memory hog.
> 
> From this, it seems that context is determined by the target of the
> assignment.  From your comment on scalar context, this doesn't seem to
> be the right conclusion.


There are 2 operators in

    @slurp=<>

you must determine the context for each operator (as it will be evaluated).

The <> operator is in list context, determined by the target 
of the assignment.

The "list assignment" operator is in scalar context though, so
the code above returns the number of lines that were read in (zero/false
in the case of an empty file).


-- 
    Tad McClellan                          SGML consulting
    tadmc@augustmail.com                   Perl programming
    Fort Worth, Texas


------------------------------

Date: 13 Apr 2004 06:40:44 -0700
From: kzin@myrealbox.com (Motti)
Subject: Re: Multiple replaces
Message-Id: <173891e8.0404130540.a2c1cab@posting.google.com>

anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) wrote in message news:<c5gcvu$mb4$1@mamenchi.zrz.TU-Berlin.DE>...
> Motti <kzin@myrealbox.com> wrote in comp.lang.perl.misc:
> > I need to do multiple replaces in some files. For example say I need
> > to change every 'die' to 'croak' and every 'warn' to 'carp' in all .pl
> > files.
> 
> I must ask here, what kind of program maintenance is this?  You're
> changing every occurrence of "die" to "croak", in strings, comments,
> data and pod regardless.  This may introduce some hard-to-catch errors.
> Even in the code, to which the replacement *should* be restricted,
> sometimes "die" may be right and "croak" wrong.  Some die()s catch
> program errors, these shouldn't be attributed to the user, as croak()
> does.
> 
> I shudder at the thought of going over a single source with a coarse
> tool like that, not to mention carpet bombing "all .pl files" with it.
> 
> In code maintenance, you *must* inspect every change manually.  Exceptions
> are extremely rare.

Well as I said this was an example, in real life I'm changing very
unique words in html files. I picked a bad example, sorry.

> > The list of changes to make is given to the script by an external file
> > (I'll use DATA to simplify things).
> > 
> > The naïve way I used in the beginning had to go over every file once
> > for each pair of words to change, this seemed a waste so I looked for
> > a way to make all the changes in one pass.
> > 
> > Here's what I wrote, any comments are welcome.
> > 
> > use strict;
> > use warnings;
> > 
> > # build regular expression table
> > my @regexps;
> > while (<DATA>)  {
> > 	my ($from, $to) = split;
> > 	next unless $from; # blank line
> > 	push @regexps, [ qr/\b$from\b/, $to];
> > }
> > 
> > @ARGV = glob '*.pl'; # took me a while to understand why $^I wasn't
> > working...
> > $^I = '.bak';
> > while (<>) {
> > 	foreach my $re (@regexps) {
> > 		s/$$re[0]/$$re[1]/g;
> 
> "$$re[0]" would more commonly be written "$re->[0]". "$$re[0]" is correct,
> but slightly ambiguous.

I'm used to using -> only when dealing with blessed objects. I suppose
it's a matter of taste. I don't see where ambiguity comes into it.

> 
> > 	}
>  print;
> > }
> 
> That should work, though there may be more efficient methods.  See
> "perldoc -q many" for some hints.

There doesn't seem to be anything there except for the qr// trick
which I came up with myself. I thought I might be missing something
more fundamental.

Thanks, Motti.


------------------------------

Date: 13 Apr 2004 15:52:25 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Multiple replaces
Message-Id: <c5h2bp$6ro$1@mamenchi.zrz.TU-Berlin.DE>

Motti <kzin@myrealbox.com> wrote in comp.lang.perl.misc:
> anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) wrote in message
> news:<c5gcvu$mb4$1@mamenchi.zrz.TU-Berlin.DE>...
> > Motti <kzin@myrealbox.com> wrote in comp.lang.perl.misc:

[...]

> > > 		s/$$re[0]/$$re[1]/g;
> > 
> > "$$re[0]" would more commonly be written "$re->[0]". "$$re[0]" is correct,
> > but slightly ambiguous.
> 
> I'm used to using -> only when dealing with blessed objects. I suppose
> it's a matter of taste. I don't see where ambiguity comes into it.

"$$re[ 0]" could either be "${ $re[ 0]}" (array @re contains a scalar ref),
or "${ $re}[ 0]" (arrayref $re contains a scalar).  Only the notoriously
hard-to-remember precedence rules make sure it's the latter.  That's
why arrow notation is preferred.

Anno


------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
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.  

NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice. 

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.

#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 V10 Issue 6395
***************************************


home help back first fref pref prev next nref lref last post