Re: [Boston.pm] Guess what is wrong with this logic
Dear Uri,
from perlop:
A (file)glob evaluates its (embedded) argument only when it
is starting a new list. All values must be read before it
will start over. [...]
i call that documented :)
I am forced to agree. :-)
KS If I want to grok ~someone/some/stuff, glob() is my only
KS choice, because readdir() doesn't work for ~someone.
use getpw* and look it up diectly. not hard at all. i recall some
related examples in the perl cookbook trying to find your home dir.
It turns out that (getpwnam($login_name))[7] is the home
directory.
Thanks for everyone's feedback and suggestions.
peace, || Operation Shoe Fly: Send your shoes to Afghan children:
--{kr.pA} || http://tinyurl.com/6jnpf
--
We must believe in luck. For how else can we explain the success of those
we don't like? -- Jean Cocteau, author and painter (1889-1963)
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Guess what is wrong with this logic
20: warn blah blah\n if (glob(~$arg) !~ m{^ (/\w+)+ /$arg $}x);
globIn list context, returns a (possibly empty) list of filename
expansions on the value of EXPR such as the standard Unix shell
/bin/csh would do. In scalar context, glob iterates through
such filename expansions, returning undef when the list is
exhausted.
Funny, I never noticed that behaviour before. AFAIK it's the only perl
function that behaves that way. Definitely a gotcha!
Actually the operator behaves as an iterator in scalar
context, both for globbing and for file reads. So, it is
consistent in that sense.
But the bug (IMHO) here is that the iterator does not get
reset even though the argument to glob() changes between
invocations. It continues to operate on the old glob()
argument.
This bug is not confined to ~ globbing.
|| % ls -1
|| apple
|| apply
|| bogus
|| %
|| % perl -le 'sub pr {my $x= $_*; print $x: , scalar glob($x);} \
|| pr for @ARGV' a b
|| a*: apple
|| b*: apply
|| %
|| % perl -v | grep built
|| This is perl, v5.6.0 built for sun4-solaris
|| %
peace, || Operation Shoe Fly: Send your shoes to Afghan children:
--{kr.pA} || http://tinyurl.com/6jnpf
--
We must believe in luck. For how else can we explain the success of those
we don't like? -- Jean Cocteau, author and painter (1889-1963)
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Guess what is wrong with this logic
Anyway, you should probably be using getpwnam() rather than glob() to check for valid usernames. Ronald ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Guess what is wrong with this logic
Anyway, you should probably be using getpwnam() rather than glob() to check
for valid usernames.
Thanks, Ronald. I'll do that.
(But the glob bug is still a bug, IMHO.)
peace, || Operation Shoe Fly: Send your shoes to Afghan children:
--{kr.pA} || http://tinyurl.com/6jnpf
--
We must believe in luck. For how else can we explain the success of those
we don't like? -- Jean Cocteau, author and painter (1889-1963)
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Guess what is wrong with this logic
KS == Kripa Sundar [EMAIL PROTECTED] writes: KS (But the glob bug is still a bug, IMHO.) though i didn't figure out your 'bug', i disagree with your calling it a bug. it is documented behavior and makes sense from an iterator point of view. the glob function needs to track its own state more then the expression passed to it so it can iterate over all the expanded files. this means it won't see new data unless it first hits the end of the current iteration. so the lesson is to call it in a list context when you want to force it to always look at new data the next time. but then again, i never use globs. readdir always works fine and i like the power of real perl regexes over the pseudo-regexes in globs. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Guess what is wrong with this logic
KS == Kripa Sundar [EMAIL PROTECTED] writes: though i didn't figure out your 'bug', i disagree with your calling it a bug. it is documented behavior ... KS No, it is not documented. The fact that it is an iterator is KS documented, but not the fact that the iterator will ignore KS argument changes until it runs out of iteration values. from perlop: A (file)glob evaluates its (embedded) argument only when it is starting a new list. All values must be read before it will start over. In list context, this isn't important because you automatically get them all anyway. However, in i call that documented :) KS This is the classic programming technique called a workaround. :-) nope, it is causing the iterator to be reset each time you call glob. KS If I want to grok ~someone/some/stuff, glob() is my only KS choice, because readdir() doesn't work for ~someone. use getpw* and look it up diectly. not hard at all. i recall some related examples in the perl cookbook trying to find your home dir. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Guess what is wrong with this logic
Well, I doubt this is what you're looking for, but it does assume that a
person's home directory is named the same as their username.
-Eric
Kripa Sundar wrote:
Hello all,
I wanted to find out if an input word is a valid login name
on my system or not.
So, I wrote this:
16: sub warn_if_bogus {
17: # Check if $arg is a valid login name.
18: my $arg = shift;
19: chomp $arg;
20: warn blah blah\n if (glob(~$arg) !~ m{^ (/\w+)+ /$arg $}x);
21: } # warn_if_bogus
Guess what is wrong with this logic.
Scroll down to see a hint.
Hint:
Here is the output of warn_if_bogus($_) for qw(ksp mary cje jackie);:
= Use of uninitialized value in pattern match (m//) at ./lab/r2.pl line 20.
= mary is bogus
= Use of uninitialized value in pattern match (m//) at ./lab/r2.pl line 20.
= jackie is bogus
All four are valid login names on my system, as seen below:
|| % echo ~ksp ~mary ~cje ~jackie
|| /d1/ksp /d1/mary /d1/cje /d1/jackie
|| %
peace, || Operation Shoe Fly: Send your shoes to Afghan children:
--{kr.pA} || http://tinyurl.com/6jnpf
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Guess what is wrong with this logic
On Thu, Sep 09, 2004 at 04:03:33PM -0400, Kripa Sundar wrote:
20: warn blah blah\n if (glob(~$arg) !~ m{^ (/\w+)+ /$arg $}x);
globIn list context, returns a (possibly empty) list of filename
expansions on the value of EXPR such as the standard Unix shell
/bin/csh would do. In scalar context, glob iterates through
such filename expansions, returning undef when the list is
exhausted.
Funny, I never noticed that behaviour before. AFAIK it's the only perl
function that behaves that way. Definitely a gotcha!
-Gyepi
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
