What is '_'

[Jason Mather]

Several places in File/Find.pm there are tests like:

if (-d _) {

What is '_'? Is it the same as '$_'?

-- Jason

 

[Richard Gration]

Several places in File/Find.pm there are tests like:
if (-d _) {
What is '_'? Is it the same as '$_'?

Nope.

When you get perl to stat a file (ie you ask perl for information about
the file, eg is it a directory, how long is the file, what is its mod
time, etc) perl uses a system function called stat, which returns a lot of
information about the file. The results of the stat are cached. The '_'
causes perl to consult the stored stat results instead of statting the
file again.

Rich

 

[Malcolm Dew-Jones]

Jason Mather ([email protected]) wrote:

: Several places in File/Find.pm there are tests like:

: if (-d _) {

: What is '_'? Is it the same as '$_'?

: -- Jason

No, it is not the same.

Perldoc -f -x (-x is the function name eh?)

at the end, all the gory details, and examples.

 

[Randal L. Schwartz]

Richard> When you get perl to stat a file (ie you ask perl for
Richard> information about the file, eg is it a directory, how long is
Richard> the file, what is its mod time, etc) perl uses a system
Richard> function called stat, which returns a lot of information
Richard> about the file. The results of the stat are cached. The '_'
Richard> causes perl to consult the stored stat results instead of
Richard> statting the file again.

Yup. One of the few features of Perl I can claim to have invented.
Two others that come to mind are the literal-slice notation and the
use of arrow for dereferencing code refs. And the JAPH.

print "Just another Perl hacker,"

 

[parv]

Perldoc -f -x (-x is the function name eh?)

at the end, all the gory details, and examples.

The gory details are not too gory for me. I want to know the
"scope" & lifetime of cached results. If i have...

sub routine
{
my $file = shift;

if ( -e $file )
{
# do something
return;
}

if ( -d $file )
{
# do something else
return;
}

if ( function() )
{
# do something else
return;
}
}

sub function { return -f _; }


....can i replace the third "$file" w/ "_"? Will function()
consistently give the result about $file in routine() (barring any
other file tests happening in the interim)?


- parv

 

[John W. Krahn]

Richard> When you get perl to stat a file (ie you ask perl for
Richard> information about the file, eg is it a directory, how long is
Richard> the file, what is its mod time, etc) perl uses a system
Richard> function called stat, which returns a lot of information
Richard> about the file. The results of the stat are cached. The '_'
Richard> causes perl to consult the stored stat results instead of
Richard> statting the file again.

Yup. One of the few features of Perl I can claim to have invented.
Two others that come to mind are the literal-slice notation and the
use of arrow for dereferencing code refs. And the JAPH.

Yes, but what have you done lately?


John

 

[Sara]

Richard> When you get perl to stat a file (ie you ask perl for
Richard> information about the file, eg is it a directory, how long is
Richard> the file, what is its mod time, etc) perl uses a system
Richard> function called stat, which returns a lot of information
Richard> about the file. The results of the stat are cached. The '_'
Richard> causes perl to consult the stored stat results instead of
Richard> statting the file again.

Yup. One of the few features of Perl I can claim to have invented.
Two others that come to mind are the literal-slice notation and the
use of arrow for dereferencing code refs. And the JAPH.

print "Just another Perl hacker,"

Curious, just consulted Camel v3, don't see this documented, or at
least if its there, it's not obvious. Is it a secret only revealed to
newsgroup readers? Nice to know though thanks!

G

 

[Uri Guttman]

p> The gory details are not too gory for me. I want to know the
p> "scope" & lifetime of cached results. If i have...

it is a simple rule. _ caches the MOST RECENT full stat made by the stat
or -X call. there is nothing else to know.


p> sub routine
p> {
p> my $file = shift;

p> if ( -e $file )
p> {
p> # do something
p> return;
p> }

p> if ( -d $file )

you can use _ there.

p> {
p> # do something else
p> return;
p> }

p> if ( function() )
p> {
p> # do something else
p> return;
p> }
p> }

p> sub function { return -f _; }

if nothing has done a stat or -X since the previous one on $file, then
you are ok. but i wouldn't trust your code to not do that. _ is
basically an operator but it acts like a global variable with no
scoping. i would never use it outside the immediate area which had the
original stat call.

p> ...can i replace the third "$file" w/ "_"? Will function()
p> consistently give the result about $file in routine() (barring any
p> other file tests happening in the interim)?

the key is what you said, barring any other file tests. assuming that is
true when making sub calls is just not good coding IMO.

uri

 

[Bart Lateur]

Curious, just consulted Camel v3, don't see this documented, or at
least if its there, it's not obvious. Is it a secret only revealed to
newsgroup readers?

I think it's in perlfunc, under "stat".

If stat is passed the special filehandle consisting of an
underline, no stat is done, but the current contents of the stat
structure from the last stat or filetest are returned.

It's a good place to find out about it, when you're checking out stat(),
but the reverse, looking up what "_" means, isn't obvious -- as shown
here.

 

[Randal L. Schwartz]

John> Yes, but what have you done lately?

I know that was in jest, but I've been trying to keep my ear on the
ground on both the perl5 and perl6 tracks, and poke my nose in
occasionally to voice an opinion or two.

In general, they don't need me. That's nice. I can focus on
cranking out 2.5 columns a month and managing my micro-herd of Perl
trainers and consultants.

print "Just another Perl hacker,"

 

[Sara]

I think it's in perlfunc, under "stat".

If stat is passed the special filehandle consisting of an
underline, no stat is done, but the current contents of the stat
structure from the last stat or filetest are returned.

It's a good place to find out about it, when you're checking out stat(),
but the reverse, looking up what "_" means, isn't obvious -- as shown
here.

Thanks Bart. Yes I checked '_' in Camel and it had some documentation
on _ as an ASCII char, but not WRT any stat function.

Randall you've done it again!

G

 

[James Willmore]

On Wed, 10 Dec 2003 12:41:36 GMT

John> Yes, but what have you done lately?
In general, they don't need me. That's nice. I can focus on
cranking out 2.5 columns a month and managing my micro-herd of Perl
trainers and consultants.

2.5? Do publishers pay for half a column ;-)

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Anything is good and useful if it's made of chocolate.

 

[ko]

(e-mail address removed) (Sara) wrote in message

Curious, just consulted Camel v3, don't see this documented, or at
least if its there, it's not obvious. Is it a secret only revealed to
newsgroup readers? Nice to know though thanks!

G

Chapter 3, the 'Named Unary and File Test Operators' section.

HTH -keith

 

[parv]

p> sub routine
p> {
p> my $file = shift;

p> if ( -e $file )
p> {
p> # do something
p> return;
p> }

p> if ( -d $file )

you can use _ there.

Splendid. I suspected that i could, but was not really sure until
now.

p> if ( function() )
p> {
p> # do something else
p> return;
p> }
p> }

p> sub function { return -f _; }

if nothing has done a stat or -X since the previous one on $file, then
you are ok. but i wouldn't trust your code to not do that. _ is
basically an operator but it acts like a global variable with no
scoping. i would never use it outside the immediate area which had
the original stat call.

On one hand, i would have used _ as described in function() now that
i am sure about its scope/lifetime/update (and that its an operator
that behaves like a variable). On the other, one cannot never be
too sure when file tests are happening often. In short, i agree w/
you Uri.


- parv

 

[Anno Siegel]

Randall you've done it again!

^
Oh my...

Anno