[17894] in Perl-Users-Digest
Perl-Users Digest, Issue: 54 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jan 13 00:05:35 2001
Date: Fri, 12 Jan 2001 21:05:10 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <979362310-v10-i54@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Fri, 12 Jan 2001 Volume: 10 Number: 54
Today's topics:
Re: Ada feature borrowed for Perl?? <mischief@velma.motion.net>
Anchoring at pos <joegottman@worldnet.att.net>
Re: Anchoring at pos <rick.delaney@home.com>
BerkeleyDB vs. DB_File (cat does battle with self?) <nospam@ucdavis.edu>
Re: csv revisited <nospam@nospam.com>
Re: DBI and migrating a 'flat-file' script to use DBI <nospam@nospam.com>
File info on win32 (Rob)
Re: File info on win32 <rick.delaney@home.com>
Re: Help this newbie learn continued. <garryknight@bigfoot.com>
Re: Help this newbie learn continued. <uri@sysarch.com>
How do I connect to a remote cgi-bin program and send i <robert@chalmers.com.au>
Re: Jobs: Senior Software Engineer (Alan Barclay)
Re: Jobs: Senior Software Engineer <mischief@velma.motion.net>
Re: Jobs: Senior Software Engineer (Jon Bell)
Re: Jobs: Senior Software Engineer (Martien Verbruggen)
Re: Mac Databases and MacPerl <nospam@nospam.com>
Re: NO! [was: Re: can I chdir(DIRHANDLE)?] <mischief@velma.motion.net>
Perl Unicode GUI for Win32 Environment? <RichardASchulmanXYZ@att.net>
Problem with while loop regexp? <gknitz@NitzSpace.com>
References <johngros.NOSPAM@bigpond.net.au>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 13 Jan 2001 03:29:18 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Ada feature borrowed for Perl??
Message-Id: <t5viseae47aa8@corp.supernews.com>
Ilmari Karonen <iltzu@sci.invalid> wrote:
> In article <3a5f2d53.4e2e$30a@news.op.net>, Mark Jason Dominus wrote:
>>In article <978374927.4396@itz.pp.sci.fi>,
>>Ilmari Karonen <usenet11323@itz.pp.sci.fi> wrote:
>>>
>>>I understand the point of having "elsif", but in my experience it's a
>>>particularly rarely needed feature, unless you're fond of spaghetti
>>>code.
>>
>>Interesting. I wonder how you manage to avoid it?
> Probably by thinking differently. I suppose I tend to break up
> problems in ways which usually result in either nested if blocks, or
> short-circuit failure handling using die, return or next.
The nice thing about elsif is that it can be thought of as a
short-circuit compared to nested `if's or sequential `if's.
My first three below examples are untesed as presented, but
vaguely resemble working code in a larger program. Assume the
first three are within a while(<>) loop. The fourth one I
whipped together and tested just for this post. ;)
0.
if( $_ eq '#quit' ) {
exit(0);
} elsif( $_ =~ /#do\s*(.*)/ ) {
if( system( "$1" ) ) {
print "Error running $1.\n";
}
} elsif( $_ eq '#run' ) {
$result = eval $code;
} else {
$code .= $_;
}
# This is similar to a toy I wrote last night in response
# to a post about using Perl as a login shell. I could
# split the logic inside the '#do' section out into a
# subroutine to make the if/elsif/else statement shorter.
# lines: 11
# lines excluding lonely closing curlies: 9
1.
if( $_ eq '#quit' ) {
exit(0);
} else {
if( $_ eq '#run') {
$result = eval $code;
} else {
if( $_ =~ /#do\s*(.*)/ ) {
if( system( "$1" ) ) {
print "Error running $1.\n";
} else {
$code .= $_;
}
}
}
}
# I'm sure Ilmari wouldn't do this in this style anyway.
# It's just a trivial example meant for illustration and
# isn't the best to make the point. I felt it would be nice
# to use the same code for my examples, though, because I'm
# lazy. :) This could do more processing than the above
# version, which quits checking conditions as soon as it
# finds something, and which Perl is good at optimizing.
# besides, option 0 is easier to maintain if the choices
# increase for extra fnctionality.
# lines: 15
# lines excluding lonely closing curlies: 11
2.
if( $_ eq '#quit' ) {
exit(0);
}
if( $_ =~ /#do\s*(.*)/ ) {
if( system( "$1" ) ) {
print "Error running $1.\n";
}
}
if( $_ eq '#run' ) {
$result = eval $code;
}
if( $_ !~ /^#/ ) {
$code .= $_;
}
# This example is just sick and wrong. A good example of
# poor coding style. This is an example of what can go wrong
# when not noticing that a group of values are mutually
# exclusive. When those multiple values apply to the same
# scalar, though, it's pretty obvious. This one has a little
# different semantics in that it doesn't add anything to
# $code when $_ starts with `#' but isn't a predefined action.
# lines: 14
# lines excluding lonely closing curlies: 9
3.
%hash = (
'quit' => sub { exit(0); },
'run' => sub { $result = eval $code;},
'do' => sub ($$) {
my $command = shift;
my $args = shift;
if( system( "$command $args" ) ) {
print "Error running $command.\n";
}
}
);
$code = '';
while(<>) {
my @stuff = /#(\w*)\s*(.*)/;
my $routine = $stuff[0];
chomp( $stuff[1] );
my ($command, $args) = split(/\s+/, $stuff[1]);
if( exists( $hash{$routine} ) ) {
my $sub_ref = $hash{$routine};
$result = &$sub_ref($command, $args);
} else {
$code .= $_;
}
}
# Example 3a shows the actual lines needed to show the
# logic behind the `if' statement. Since this one is
# working code, it incudes things the preceding ones
# did not.
3a.
%hash = (
'quit' => \sub { exit(0); },
'run' => \sub { $result = eval $code;},
'do' => \sub ($$) {
my $command = shift;
my $args = shift;
if( system( "$command $args" ) ) {
print "Error running $command.\n";
}
}
);
if( exists( $hash{$routine} ) ) {
$result = &${$hash{$routine}}($command, $args);
} else {
$code .= $_;
}
# This is how many people might code such a beast.
# The `if' statement doesn't need to grow at all
# in future versions if all you are doing is adding
# functionality based on the same variable.
# lines: 16
# lines excluding lonely closing curlies: 13*
# * Subtract one more line for the hash close if you like,
# since it serves a similar purpose to a closing curly here.
> If you tend to break up problems into a parallel set of possibilities,
> I suppose you'd tend to use elsif more often. Neither approach is
> inherently better in all cases -- I just recently posted example code
> using elsif, which I'd first written using nested ifs and then cleaned
> up to use elsif since it looked better in that particular case.
Hashes of subs can be used to represent a parallel set of
possibilities too. I could still find an elsif handy had I made
that last example do alias handling like the toy shell program I
wrote last night. Since I have a hash ready and willing to
take more entries, though, my alias-handling code would probably
add a hash key if one didn't exist, call system with the value
if it did exist, or delete() the hash key if the #alias statement
was given a key without a value. This way, the hash starts to
act as a symbol table. Working with a single token comes down to
a matter of checking to see if something exists in a hash, then
executing the associated subroutine.
> The above is completely unrelated to the fact that I also tend to
> avoid elsif in cases where the code in the blocks might end up longer
> than half a dozen lines. In those cases nested ifs, with the extra
> indentation they cause, IMHO help readability. A single elsif line
> gets easily lost in the noise.
You can always use subroutines if the length of an `if' statements
get too long. One of my `Structured Programming' texts suggested that
flow control and processing be kept separate as much as possible.
Top-down design can be carried too far, though, IMHO. I say design
from the top down if you like, but implement from the bottom up.
I find that implementing the small pieces, like code for reading from
a file and writing to a file with a particular format before deciding
where to put the calls to the reading and writing code, keeps me from
duplicating effort and then refactoring to modularize my code. If I
write the code surrounding the logic first, I'm likely to write the
logic inline in each of those places, instead of calls to a subroutine.
If the subroutine already exists, then I'll remember to call it where
appropriate.
> (Below, I've snipped all examples where you've mentioned a dispatch
> table yourself, since I agree with you on all of those.)
>>A.
>> if (param('age') eq "") {
>> push @ERRORS, "You omitted your age!";
>> } elsif (param('age') =~ /\D/) {
>> push @ERRORS, "Your age should be a number!";
>> }
>>
>>I think this is the prototypical example. You cannot use a dispatch
>>table here.
> I might write that, but more likely I'd short-circuit:
> push(@ERRORS, "You omitted your age!"), last
> if param('age') eq "";
> push(@ERRORS, "Your age should be a number!"), last
> if param('age') =~ /\D/;
unless( param('age') =~ /^\d$/ ) {
push( @ERRORS, "Your age cannot be blank, and should be a number!" );
}
Okay, so that one has different semantics... but it does show
the kind of design decision I like to make. On a more serious
note, both of the previous posters seem to agree on what to
do in the situation, just not how the code should look. Mark
(or is it Jason -- or Mr. Dominus, for that matter? ;) prefers
that Perl decide when to skip the rest of the decision process,
while Ilmari prefers to reservce that right.
>>C.
[snip MJD's example C, since I'd have trouble commenting on it.]
> That's a funny one. I'd really have to see more context to say what
> I'd do. If I had those program paths to choose from, I would probably
> write something like you did. But somehow I tend to do my high level
> program design so that I rarely end up with such a three-way choice,
> and I can't entirely consciously describe how I do it.
I can't comment on that example any more than Ilmari, but I can say
I wish Ilmari could consciously describe how it could be avoided. I
am always interested in finding new and interesting perspectives on
design, even if I do not decide to follow suit.
>>D.
> [snip]
>> sub get_person {
>> if (my $pi = path_info()) {
>> $pi =~ tr{/}{}d;
>> return $pi eq '' ? undef : $pi;
>> } else
>> return param('person');
>> }
>> }
>>
>>This shortens the code, which is good, but it is no longer clear that
>>the possibly undefined return value is not an oversight. I think the
>>original code makes the intention clearer.
> I'd have written:
> return param('person') # might be undef
I think this is sufficient, as well as adding it to any interface
documentation if it is to be called publicly.
[snip examples E, F, and G, along with all comments about them]
I would use MJD's solution on G despite seeing good points made
by Ilmari.
>>H.
>>
>> if (defined $opt_A) {
>> $ua->agent($opt_A);
>> } elsif ($opt_m) {
>> $ua->agent('Mozilla/3.04 (X11; I; Linux 2.2.12 i586)');
>> } else {
>> $ua->agent("Site Copier ($ADDRESS)" . $ua->agent);
>> }
> $ua->agent( defined $opt_A ? $opt_A
> : $opt_m ? 'Mozilla/3.04 (X11; I; Linux 2.2.12 i586)'
> : "Site Copier ($ADDRESS)" . $ua->agent );
> But maybe that's just my fascination with ?: -- let's try without:
> my $agent = "Site Copier ($ADDRESS)" . $ua->agent;
> $agent = 'Mozilla/3.04 (X11; I; Linux 2.2.12 i586)' if $opt_m;
> $agent = $opt_A if defined $opt_A;
> $ua->agent($agent);
> Okay, it's not as nice -- but that's why I would normally use ?:.
I don't like the readabilty of ?: normally, but for something this
short it could make sense. In the case that more options may need to
be added, I'd use Mark's method.
>>I.
>>
>> if ($main::opt_C) {
>> # (get credentials from $opt_C)
>> } elsif (-t) {
>> # (get credentials from STDIN)
>> } else {
>> return (undef, undef)
>> }
> if ($main::opt_C) {
> # (get credentials from $opt_C)
> return($user, $pass);
> }
> if (-t) {
> # (get credentials from STDIN)
> return($user, $pass);
> }
> return(undef, undef);
> I might also use a nested if, but this looks like a perfect case for
> short-circuiting.
I tend to do what Ilmari's doing here, although sometimes I would
rather set variables and then return them at the end than to
return early from either an if/elsif or from multiple ifs. It's
nice for maintainers to see a single point of exit. Sometimes,
though, it's just not worth the hassle, especically if you return
something large.
>>J.
>>
>> if (/^-{12}/) {
>> # (emit the recently-seen section of the document)
>> undef $title;
>> ...
>> } elsif (! $title && /\S/) {
>> $title = $_;
>> }
> $title = $_, next LINE if !$title and /\S/;
> if (/^-{12}/) {
> # (emit the recently-seen section of the document)
> undef $title;
> }
Ilmari's uses two if statements, one of which can skip the other.
Mark's uses an if and an elsif. Either way accomplishes not only
the same external semantics, but are also pretty similar
internally. I would find Mark's easier to update for more cases.
Also, if Ilmaris's method is used and another test needs to be
made, and maybe a fourth, then using next can end up using more
comparisons to find the right match.
while() {
next if $condition_a;
next if $condition_b;
if( $condition_c ) {
# misc
}
}
while() {
if( $condition_a ) {
} elsif( $condition_b ) {
} elsif( $condition_c ) {
}
}
The first one above, because with an if/elsif/else perl can
sometimes create a jump table, on average uses more comparisons
than the second, even though unoptimized they do practically
the same thing.
When and how Perl chooses to make a jump table and how much it
helps I'm not sure. In a very simple test case I made, the
difference is what some might call negligible. I found that I
saved more switching from the match operator ( m// ) to the
`eq' operator than I did by switching from using `next' to
using `elsif'. I think that 130 to 135 executions a second of
a short loop doing simple comparisons could make a difference
somewhere, but I'm not too sure where. However, if I saw the
same sort of proportion in time difference in a very tight
loop in the real world, I might be inclined to care.
#!/usr/bin/perl
use Benchmark;
my @choice = ('a', 'b', 'c', 'd');
my $result = '';
timethese (-60, {
a => '&Elsif',
b => '&Next'
});
sub Elsif {
for(@choice) {
if( $_ eq 'a' ) {
$result = 'a';
} elsif( $_ eq 'b' ) {
$result = 'b';
} elsif( $_ eq 'c' ) {
$result = 'c';
} else {
$result = '';
}
}
}
sub Next {
for(@choice) {
$result = 'a', next if $_ eq 'a';
$result = 'b', next if $_ eq 'b';
$result = 'c', next if $_ eq 'c';
$result = '';
}
}
Benchmark: running a, b, each for at least 60 CPU seconds...
a: 60 wallclock secs @ 29784.75/s (n=1787085)
b: 60 wallclock secs @ 29650.09/s (n=1779302)
###-------------------------------------------------------------
#!/usr/bin/perl
use Benchmark;
my @choice = ('a', 'b', 'c', 'd');
my $result = '';
timethese (-60, {
a => '&Elsif',
b => '&Next'
});
sub Elsif {
for(@choice) {
if( /a/ ) {
$result = 'a';
} elsif( /b/ ) {
$result = 'b';
} elsif( /c/ ) {
$result = 'c';
} else {
$result = '';
}
}
}
sub Next {
for(@choice) {
$result = 'a', next if /a/;
$result = 'b', next if /b/;
$result = 'c', next if /c/;
$result = '';
}
}
Benchmark: running a, b, each for at least 60 CPU seconds...
a: 59 wallclock secs @ 26942.81/s (n=1616838)
b: 61 wallclock secs @ 26756.42/s (n=1611539)
###-------------------------------------------------------------
>>Looking these over, I don't draw any especially enlightening
>>conclusions about my usage patterns for 'elsif'. But I find myself
> You don't use 'next' as much as I do? Nor statement modifiers?
I don't always find myself in a loop, so next/last aren't always
an option, unless I make a gratuitous code block. I could always
use goto, but that's silly in a language that can do so much
behind the scenes if you let it.
>>more rurpsied than ever that you don't use it. How would you have
> Is that an interesting typo for 'surprised'? It looks almost like
> something that might eventually end up in the Jargon File..
Okay, who's mailing ESR? We need at least two independent sightings. ;)
>>written (E) or (I) for example?
> Short circuit with next/return/die.
Handy when writing, but can be just a little tougher to maintain.
> HTH. I don't consider this a particularly important issue, but IMO
> it's interesting to compare personal coding styles in the process.
I think so too. Besides interesting, it can be helpful for the rest
of us to see wizards compare coding techniques. I know that although
I would never pick up someone else's complete style even if I was
silly enough to force myself into it, I find myself using things
I see in the group all the time that I otherwise would have tried,
well, otherwise. ;) Sometimes what I try that seems foreign at
first turns out to be a good idea, sometimes I see something I
wouldn't have thought up but which makes sense instantly, and
sometimes I'm glad I've already found my own style of doing some
particular task.
Chris
--
Christopher E. Stith
Product shown enlarged to make you think you're getting more.
------------------------------
Date: Sat, 13 Jan 2001 02:11:59 GMT
From: "Joseph Gottman" <joegottman@worldnet.att.net>
Subject: Anchoring at pos
Message-Id: <PPO76.1557$Ep3.92336@bgtnsc04-news.ops.worldnet.att.net>
Suppose I have a regular expression like
$foo =~ m/\w+\s*/g;
Every time I run it, I only want to find matches that start where the
previous one left off, Is there any metacharacter I can use to match only
strings that begin at pos($foo)?
Joe Gottman
------------------------------
Date: Sat, 13 Jan 2001 04:23:35 GMT
From: Rick Delaney <rick.delaney@home.com>
Subject: Re: Anchoring at pos
Message-Id: <3A5FDC24.1E3A8BA9@home.com>
[posted & mailed]
Joseph Gottman wrote:
>
> Is there any metacharacter I can use to match only
> strings that begin at pos($foo)?
\G
See perlre and examples under m// in perlop and in perlfaq6.
--
Rick Delaney
rick.delaney@home.com
------------------------------
Date: Fri, 12 Jan 2001 19:03:26 -0800
From: Bruce McEachern <nospam@ucdavis.edu>
Subject: BerkeleyDB vs. DB_File (cat does battle with self?)
Message-Id: <3A5FC57E.76FE6046@ucdavis.edu>
I have run into a problem installing/accessing/using Berkeley DB v3.1(.17), the
Perl (v5.6.0) and BerkeleyDB module (0.12) to access it on a Tru64 Unix (v4.0f)
box. The problem is that when I try to run something using the BerkeleyDB module
(say, the "make test" suite), I get instant failure, with a message of the form:
<snip edited="to fit screen">
/usr/local/bin/perl -Iblib/arch -Iblib/lib -I/usr/local/Perl5.6/lib
-I/usr/local/Perl5.6/lib -e 'use Test::Harness qw(&runtests $verbose);
$verbose=0; runtests "t/btree.t";'
t/btree.............Can't load 'blib/arch/auto/BerkeleyDB/BerkeleyDB.so'
for module BerkeleyDB: Unresolved symbol in
blib/arch/auto/BerkeleyDB/BerkeleyDB.so: db_create at
/usr/local/Perl5.6/lib/DynaLoader.pm line 200.
at t/btree.t line 25
Compilation failed in require at t/btree.t line 25.
BEGIN failed--compilation aborted at t/btree.t line 25.
t/btree.............dubious
Test returned status 255 (wstat 65280, 0xff00)
FAILED--1 test script could be run, alas--no output ever seen
</snip>
After a good bit of thrashing about, I believe that this comes about because
the perl, when configured and built, finds the OSF proffered libdb.so (in
/usr/shlib), a Berkeley DB v1.85 would be my guess, and links to it. This I
know, since ./Configure asks you to confirm a link switch containing:
... -ldb ... (that, and I checked the config files).
What I think is happening is that Perl, when launching, hauls in the v1.85
libdb.so (or at least the link table). Then, afterward, when the loader is
trying to resolve symbols (found in BerkeleyDB.so)--particularly db_create--
it knows it already has libdb loaded and does not try again. (FYI, it does not
appear that db_create was a defined entity in v1.85.) So, even though I have
told the configure/make of BerkeleyDB.so about where the v3.1.17 libdb.a lives,
and my ENV yells LD_LIBRARY_PATH and screams LD_RUN_PATH at the loader, the
above error just keeps on truckin' across my screen.
Beyond the obvious question: "does this explanation make sense?," I am
wondering about the most rational, sustainable, fix.
Do I want to pull the "-ldb" out of the Perl configure and just leave all
Berkeley DB access to be handled by BerkeleyDB.so (a v0.12, I might point out
here)? Wouldn't this break a bunch of "simple-API" stuff available through the
DB_File module? I'm fairly sure I can't just flip the v3.1.17 libdb.a into the
front of the loader's search path and rebuild perl and all (it's not nice to
jump up 2 major revs on libraries your O/S uses--usually).
Any thoughts on this would be truly appreciated.
Bruce (make the obvious alterations_\/_to get my e-mail addr)
--------------------------------------------------------------------
Bruce McEachern >> brucem_at_library_ucdavis_edu <<
Library Systems Department The older I get, the better I...was.
Univ. of California, Davis Youth is fleeting
Phone: (916) 752-7685 --immaturity can last a lifetime.
--------------------------------------------------------------------
------------------------------
Date: 13 Jan 2001 02:47:02 GMT
From: The WebDragon <nospam@nospam.com>
Subject: Re: csv revisited
Message-Id: <93ofj6$nkm$1@216.155.32.137>
In article <Rj276.3043$CN6.471319@typhoon2.ba-dsg.net>, Alex Hart
<news@#nospam#althepal.com> wrote:
| I do not think this is in the faq. The faq deals with comma separated
| values when the entire entry is enclosed in quotes (,"One
| Entry","Another Entry",) . But in email addresses, often only part of
| the entry is enclosed in quotes(,"The Name"<email@domain>,"Num
| 2"<second@domain>). The regex in the faq would split up the previous
| examples into 2 entries each.
suggestion: you could always use the DBI to do this.. it's perfect for a
comma separated list..
install DBI, SQL::Statement, and Text::CSV_XS and then DBD::RAM,
DBD::CSV. all on CPAN.
--
send mail to mactech (at) webdragon (dot) net instead of the above address.
this is to prevent spamming. e-mail reply-to's have been altered
to prevent scan software from extracting my address for the purpose
of spamming me, which I hate with a passion bordering on obsession.
------------------------------
Date: 13 Jan 2001 02:13:29 GMT
From: The WebDragon <nospam@nospam.com>
Subject: Re: DBI and migrating a 'flat-file' script to use DBI
Message-Id: <93odk9$gp3$1@216.155.32.137>
In article <+fYAMKAXUZX6Ew+S@pathfind.demon.co.uk>, John Jones
<johnj@pathfind.demon.co.uk> wrote:
| In article <93jso1$doi$0@216.155.33.72>, The WebDragon
| <nospam@nospam.com> writes
| > the biggest question I have is how to get the DBI to give me a
| > count of the returned rows from the executed statement handle for
| > which I have no desire to actually fetch any rows for before
| > finishing it and moving onwards.
| I'm not sure if this helps...
|
| >
| "$rv = $sth->rows Returns the number of rows affected by the last row-
| effecting command, or -1 if the number of rows is not known or not
| available"
|
| However, rows is only accurate after completing all the fetches from a
| select or after a non-select operation. A recommended alternative
| technique is to use SELECT COUNT (*) FROM <more sql> where the <more
| sql> bit is the same as your query, and then use rows to get the row
| count.
Interestingly, for DBD::CSV this seems to work fine (the $sth->rows) ..
when I tried the COUNT statement, I got syntax errors from File.pm
This short test script works fine on my datafile.
I suspect that the COUNT statement may be specific to another type of
database, (or more recent than my current install)
Thank you!
#!perl -w
use strict;
use DBI;
my $connect_dir = "Primus 8.5GB:Applications:MacPerl
?:Nalicity:ratings:DBI testing:tables:";
my $dbh = DBI->connect("dbi:CSV:f_dir=${connect_dir};csv_sep_char=\,",
'', '', { RaiseError => 1 })
or die "Can't connect to database: $DBI::errstr";
my $sth = $dbh->prepare(" SELECT * FROM testmapslist WHERE filename
CLIKE '%after%' ORDER BY coercename DESC ");
$sth->execute;
print $sth->rows, " Rows\n" if $sth->rows;
my($id, $gametype, $coercename, $filename, $title, $size, $review,
$rating);
$sth->bind_columns(\($id, $gametype, $coercename, $filename, $title,
$size, $review, $rating));
my $count = 1;
while ($sth->fetchrow) {
print "Count:$count Game: $gametype, File: $filename, Title: $title,
Size: $size, Review: $review, Rating: $rating\n";
++$count;
}
$dbh->disconnect;
exit 0;
the output:
5 Rows
Count:1 Game: utctf, File: ctf-aftermath][.zip, Title: ctf-aftermath][,
Size: 207, Review: -1, Rating: -1
Count:2 Game: utctf, File: ctf-aftermath.zip, Title: ctf-aftermath,
Size: 209, Review: -1, Rating: -1
Count:3 Game: utdm, File: dm-afterdark.zip, Title: dm-afterdark, Size:
873, Review: /nalicity/review.asp?Id=7709, Rating: 3.5
Count:4 Game: utdm, File: dm-afterglow.zip, Title: dm-afterglow, Size:
139, Review: -1, Rating: -1
Count:5 Game: utdm, File: dm-aftertouch.zip, Title: dm-aftertouch, Size:
511, Review: -1, Rating: -1
Again, thank you.. this will hopefully do exactly what I need.
--
send mail to mactech (at) webdragon (dot) net instead of the above address.
this is to prevent spamming. e-mail reply-to's have been altered
to prevent scan software from extracting my address for the purpose
of spamming me, which I hate with a passion bordering on obsession.
------------------------------
Date: Sat, 13 Jan 2001 02:32:24 GMT
From: me@home.com (Rob)
Subject: File info on win32
Message-Id: <3a61bdcf.19695280@news.bens1.pa.home.com>
Does anyone know how to get the created, accessed and modified times
for a file on NT 4? I checked deja and the Perl documentation but
didn't find anything.
Thanks,
Rob
------------------------------
Date: Sat, 13 Jan 2001 04:30:04 GMT
From: Rick Delaney <rick.delaney@home.com>
Subject: Re: File info on win32
Message-Id: <3A5FDDA9.DC84C43@home.com>
Rob wrote:
>
> Does anyone know how to get the created, accessed and modified times
> for a file on NT 4? I checked deja and the Perl documentation but
> didn't find anything.
Nothing? Perhaps the tense you're using threw you off. Try looking for
"creation time", "access time" or "modify time" in perlfunc. Don't
believe the "NOT creation time" comment for NT. That would only make
sense for systems with inodes.
--
Rick Delaney
rick.delaney@home.com
------------------------------
Date: Sat, 13 Jan 2001 02:20:15 +0000
From: "Garry Knight" <garryknight@bigfoot.com>
Subject: Re: Help this newbie learn continued.
Message-Id: <93oe0v$qf7$1@taliesin.netcom.net.uk>
In article <93o4vk$6q7$1@brokaw.wa.com> "Mike McPherson"
<hafateltec@hotmail.com> wrote:
> Now the original program only accepts input via the command line. Now
> I would like it to
> 1. Accept input during runtime.
> 2. Have a escape parameter.
> 3. After one operation conversion is complete continue unless the
> escape parameter has been given.
> I have tried numerous things to accomplish above but to no avail.
It might help if you'd said what you'd tried...
Rather than modify your original code, I thought you might like to have
a look at the following. Note the use of the while (<>) construct to
read from stdin into the $_ variable in a loop, and the use of simple
regular expressions to match the text in $_ all embedded in a series of
if..elsif blocks.
Run it a couple of times without any command-line parameters. Now
create a file containing something like:
ASCII 102
CHAR d
ASCII 48
CHAR (
QUIT
and then call the script with the name of the file as a command-line
parameter. Just a simple demo of how versatile Perl is.
#!/usr/bin/perl -w
use strict;
sub usage {
print "Enter 'ASCII number' or 'CHAR character' or 'QUIT'.\n";
}
usage();
while (<>) { # read from stdin
if (/^ASCII\s+(\d+)/) {
print "ASCII $1 = CHAR " . chr($1) . "\n";
}
elsif (/^CHAR\s+(.)/) {
print "CHAR $1 = ASCII " . ord($1) . "\n";
}
elsif (/^QUIT/) { last }
else { usage(); }
}
--
Garry Knight
garryknight@bigfoot.com
print "Just another Perl neophyte"
------------------------------
Date: Sat, 13 Jan 2001 04:47:28 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Help this newbie learn continued.
Message-Id: <x74rz42h3z.fsf@home.sysarch.com>
>>>>> "GK" == Garry Knight <garryknight@bigfoot.com> writes:
GK> #!/usr/bin/perl -w
GK> use strict;
GK> sub usage {
GK> print "Enter 'ASCII number' or 'CHAR character' or 'QUIT'.\n";
GK> }
GK> usage();
GK> while (<>) { # read from stdin
GK> if (/^ASCII\s+(\d+)/) {
GK> print "ASCII $1 = CHAR " . chr($1) . "\n";
GK> }
GK> elsif (/^CHAR\s+(.)/) {
GK> print "CHAR $1 = ASCII " . ord($1) . "\n";
GK> }
GK> elsif (/^QUIT/) { last }
GK> else { usage(); }
GK> }
well, if you want to simplify it even more, then do something like this:
#!/usr/local/bin/perl -wn
BEGIN { usage() ; }
if ( /^ASCII\s+(\d+)/ ) {
print "ASCII $1 = CHAR " . chr($1) . "\n";
next ;
}
if ( /^CHAR\s+(.)/ ) {
print "CHAR $1 = ASCII " . ord($1) . "\n";
next ;
}
exit if /^QUIT/ ;
sub usage {
print "Enter 'ASCII number' or 'CHAR character' or 'QUIT'.\n";
}
or as a bunch of one liners (see the fascinating thread 'Ada feature
borrowed for Perl??)
/^ASCII\s+(\d+)/ && printf "ASCII $1 = CHAR %s\n", chr($1) and next ;
/^CHAR\s+(.)/ && printf "CHAR $1 = ASCII %s\n", ord($1) and next ;
/^QUIT/ && exit ;
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: Sat, 13 Jan 2001 14:21:38 +1000
From: "Merlin" <robert@chalmers.com.au>
Subject: How do I connect to a remote cgi-bin program and send it the form data from within my perl script?
Message-Id: <FPQ76.71$pj6.12681@nsw.nnrp.telstra.net>
I'm trying to discover how I can send data from a web page, that is passed
back to my perl script, to a remote cgi-bin program that expects it.
I know how a FORM does it from a web page of course, but how to I do the
same thing from within a perl script.
do makepayment {
....
....
...
}
sort of thing?
Thanks
Robert
------------------------------
Date: 13 Jan 2001 03:38:42 GMT
From: gorilla@elaine.furryape.com (Alan Barclay)
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <979357036.643932@elaine.furryape.com>
In article <t5uf51mvut2i71@corp.supernews.com>,
Chris Stith <mischief@velma.motion.net> wrote:
>If I were a recruiter wanting to make use of this newsgroup, I'd
>use the group itself AS a resume. Even if I knew nothing of Perl,
>I could go through and count how many answers a poster gave that
>went uncorrected, and could, from the context of the posts around
>a certain person's posts, figure out approximately how much experience
>they have.
That doesn't sound terribly reliable. By your method, Larry Wall has
no experience in Perl, because he never posts here.
------------------------------
Date: Sat, 13 Jan 2001 04:35:10 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <t5vmnu3hikid2e@corp.supernews.com>
Martien Verbruggen <mgjv@tradingpost.com.au> wrote:
> On Fri, 12 Jan 2001 17:19:29 -0000,
> Chris Stith <mischief@velma.motion.net> wrote:
>>
>> Some people here might not
>> even mind being emailed job offers directly to them, although I'm
>> sure some would.
> It depends on the email. If the email is clearly a personal one, written
> by a real life person, and it is clear that what they offer fits what I
> do, and who and where I am, then it is clear enough to me that they've
> done their homework. That's a normal practice for employment agencies
> and head hunters. You put a feeler out, investigate, then approach the
> person. Whether that's by email or phone is hardly relevant. I didn't
> ask for the email, but that doesn't mean it's UCE/UBE.
Very well said.
> And that's where the offensive bit comes in. I regularly get email (most
> of which get filtered away by procmail), of employment agencies who, in
> my view, have undiscriminately spammed every valid email address on
> clp.misc or clp.modules. A dead giveaway for me normally is 'Great job
> opportunity in Dinkyville, Arkansas.' Anyone who'd personally write an
> email to me would notice that my location is very unlikely to be close
> enough to the USA to be really interested in that job. Needless to say,
> all this email does is grow the procmail filter.
If I could employ you remotely for enough money, would yuou consider
that? (This is a hypothetical, of course, I'm a one-person programming
department at an ISP that needs more tech support than anything.)
> Occasionally, however, I do get a genuine email, one that didn't come
> out of a machine. I respond to these.
This is quotable. :)
> It's not the U in UBE that pisses people off. It's the B.
This is even more quotable. If you don't mind, you just made my
random tagline rotation.
I think that everyone has differences in what they find acceptable
or tasteful, but i think Martien hits the nail on the head with
this one for my sensibilities.
--
Christopher E. Stith
"Get real! This is a discussion group, not a helpdesk. You post
something, we discuss its implications. If the discussion happens to
answer a question you've asked, that's incidental." -- nobull in clpm
------------------------------
Date: Sat, 13 Jan 2001 04:16:10 GMT
From: jtbell@presby.edu (Jon Bell)
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <G732Iy.Is8@presby.edu>
Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Terrence" == Terrence Brannon <brannon@lnc.usc.edu> writes:
>
>Terrence> can we make a move to have comp.lang.perl.jobs created? I think this
>Terrence> would be a great thing.
>
>If anything, you'll be told "it should be misc.jobs.offered.perl", and
>then they'll wonder why Perl is so special that people can't simply
>grep for "perl" in misc.jobs.offered.
They can't do that any more (grep through misc.jobs.offered). That group
has been voted out of existence, 170 to 14, as announced in
news.announce.newgroups on 28 November 2000. For the RFD and CFV, see
<ftp://ftp.isc.org/pub.usenet/news.announce.newgroups/misc/misc.jobs.offered>
and scroll down a ways.
There *is* a misc.jobs.fields hierarchy with subgroups (so far) for
chemistry and legal jobs. Maybe misc.jobs.fields.programming.perl?
--
Jon Bell <jtbell@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
------------------------------
Date: Sat, 13 Jan 2001 15:51:09 +1100
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <slrn95vnlt.50v.mgjv@martien.heliotrope.home>
On Sat, 13 Jan 2001 04:35:10 -0000,
Chris Stith <mischief@velma.motion.net> wrote:
> Martien Verbruggen <mgjv@tradingpost.com.au> wrote:
>> On Fri, 12 Jan 2001 17:19:29 -0000,
>
>> And that's where the offensive bit comes in. I regularly get email (most
>> of which get filtered away by procmail), of employment agencies who, in
>> my view, have undiscriminately spammed every valid email address on
>> clp.misc or clp.modules. A dead giveaway for me normally is 'Great job
>> opportunity in Dinkyville, Arkansas.' Anyone who'd personally write an
>> email to me would notice that my location is very unlikely to be close
>> enough to the USA to be really interested in that job. Needless to say,
>> all this email does is grow the procmail filter.
>
> If I could employ you remotely for enough money, would yuou consider
> that? (This is a hypothetical, of course, I'm a one-person programming
> department at an ISP that needs more tech support than anything.)
It depends a bit. Money isn't always the main issue [1]. It has more to
do with the job being interesting, and trusting the people you would be
doing business with enough to commit to a relationship where you would
hardly ever meet in person. Working remotely, exclusively, can be done
for many sorts of contracts, and it is done. For long term working
relationships it's a bit harder to do.
I'm more used to working in a team, and believe that I function best
that way. I would probably take that into account when considering the
offer.
>> Occasionally, however, I do get a genuine email, one that didn't come
>> out of a machine. I respond to these.
>
> This is quotable. :)
If you're going to quote it, please remove the 'a' (just before genuine)
and the 'one', including the comma, from the sentence above :). They
shouldn't be there.
>> It's not the U in UBE that pisses people off. It's the B.
>
> This is even more quotable. If you don't mind, you just made my
> random tagline rotation.
:)
Martien
[1] For me, personally, it isn't an issue at all, with which mean that
I am in a permanently employed position. If, however, I'd be doing
contract work, or was looking for work, the above would be my train of
thought and my opinions.
That said, money is of course a factor :)
--
Martien Verbruggen |
Interactive Media Division |
Commercial Dynamics Pty. Ltd. | Curiouser and curiouser, said Alice.
NSW, Australia |
------------------------------
Date: 13 Jan 2001 02:42:06 GMT
From: The WebDragon <nospam@nospam.com>
Subject: Re: Mac Databases and MacPerl
Message-Id: <93of9u$nkm$0@216.155.32.137>
In article <3A5C73E3.B4C99336@mail1.jpl.nasa.gov>, Marc Pestana
<markp@mail1.jpl.nasa.gov> wrote:
| Hello Group,
|
| I want to create a CGI script in MacPerl that accesses a database. I've
| thought of using the DB_File.pm but it requires the Berkeley database
| which I don't have loaded on my Mac. Where can I obtain a version of the
| BD for a G3? Does anyone know of a MacPerl Newsgroup I could query? Is
| there an SQL database for the Mac that I could use instead of the BD?
|
| Thanks, Marc P
|
I haven't had much luck with the regular DB modules, but you can pick up
the DBI stuff that's been ported to MacPerl at Chris Nandor's MacPerl
porter's page
<http://pudge.net/mmp/>
you should first install DBI, SQL::Statement, and Text::CSV_XS from
Chris's site, then install DBD::CSV and DBD::RAM from
CPAN.
From there you can possibly move onwards to other Database types.
DBD::CSV is for Comma Separated Values, and is worth looking at for
flat-file type databases.
You could also look into Storable.pm (also ported on Chris's site) for
storage and retrieval of a hash if yu're looking for something simple. I
recent article I posted, <93jnh4$ll$0@216.155.33.72>, has a short script
that utilizes Storable.
If you go the DBI route, you'll want to pick up O'Reilly's Learning The
Perl DBI book. while much of it's content is duplicated in the pod
documentation, it lays things out in a fairly linear fashion and is a
worthwhile read for someone completely new to DBI.
I'm currently puzzling out how to convert a flat-file-using CGI script I
have into using a DBI-type of interface internally to save on RAM and
other overhead.
--
send mail to mactech (at) webdragon (dot) net instead of the above address.
this is to prevent spamming. e-mail reply-to's have been altered
to prevent scan software from extracting my address for the purpose
of spamming me, which I hate with a passion bordering on obsession.
------------------------------
Date: Sat, 13 Jan 2001 04:26:25 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: NO! [was: Re: can I chdir(DIRHANDLE)?]
Message-Id: <t5vm7hac8mbj2a@corp.supernews.com>
"Antoine Beaupre (LMC)" <lmcabea@lmc.ericsson.se> wrote:
> Wow, that's odd... I really remember having read this somewhere. Too
> [much|less] coffee. :)
> And by the way, I'm still out of it when I say:
> chdir(<FROM>); # evil!
> This is not working. In fact, it brings me back to my home dir.
That could be a handy feature. Or since this is Perl, should I
call that an idiom? :)
This question is closely related to the other current thread on
recovering a file name from a filehandle. If you could recover
a directory name from the directory handle, then you could
chdir() to that.
The suggestion in the other thread was to keep around a copy of
the real filehandle somewhere.
I did throw together a short thing to tell me the name of a
file I have open based on the filehandle, if I know in which
directory the file is. Maybe something similar could work for
a directory, too, under certain circumstances. The following
is tested, but it's just a simple proof-of-concept. It uses the
fact that stat() works on filehandles as well as file names,
and the fact that a file won't share an inode with another file.
It really does only work if the file is still open.
###############################################################
#!/usr/bin/perl
$match = 0;
if( $ARGV[1] ) {
$dir = $ARGV[1];
} else {
$dir = '.';
}
open(File, "$ARGV[0]") || die "Can't open file $ARGV[0]: $!\n";
opendir(Dir, "$dir") || die "Can't open directory $dir: $!\n";
@file = readdir(Dir);
close(Dir);
for(@file) {
if( ((stat(File))[1]) == ((stat("$dir/$_"))[1]) ) {
print "File opened is $_\n";
$match = 1;
}
}
unless( $match ) {
print "Never found opened file in the directory $dir.";
}
close(File);
################################################################
Here's how the above works:
$ filetest filetest
File opened is filetest
$ filetest mail/sent-mail mail
File opened is sent-mail
It's not a panacea, but it could come in handy in a pinch.
If all else fails, there's always syscall() if you aren't
worried about portability.
Chris
--
Christopher E. Stith
Disclaimer: Actual product may not resemble picture in ad in any way.
------------------------------
Date: Sat, 13 Jan 2001 03:28:29 GMT
From: Richard A. Schulman <RichardASchulmanXYZ@att.net>
Subject: Perl Unicode GUI for Win32 Environment?
Message-Id: <3jiv5ts0ebt4k5knqdvolf27t1t7aors87@4ax.com>
I've been unable to display East Asian Unicode characters
using Active State's Perl 5.6 and the Perl-Tk user interface
in a Windows NT 4 / SP 6a environment.
Is this a problem with Perl or Perl-Tk? If Perl-Tk, is there
another GUI I can use that will support the display of
Unicode characters?
---
Richard Schulman
To email me, remove the "XYZ"
------------------------------
Date: Fri, 12 Jan 2001 20:06:12 -0800
From: "Gary K. Nitzberg" <gknitz@NitzSpace.com>
Subject: Problem with while loop regexp?
Message-Id: <93ok7p011r3@enews2.newsguy.com>
I am using Perl 5.6.0 and I was expecting the code below to go through the
while loop only once. But the while loop executes twice. It appears that
once I do the substitution the regexp starts over at the beginning. Why
does it go through the loop twice? Thanks.
Gary.
----------------------------------------------------------------------
#!/usr/local/bin/perl
use strict;
use File::Basename;
my $data = q(<IMG SRC="/images/picture.gif">);
while ($data =~ /<IMG SRC=["'](.*?)["']/igos) {
my $href = $1;
my $file = basename($href);
$data =~ s/<IMG SRC=\"$href\"/<IMG SRC="$file"/igos;
print "IMAGE: $href, DATA: $data\n";
}
-----------------------------------------------------------------------
------------------------------
Date: Sat, 13 Jan 2001 05:12:15 GMT
From: "John Boy Walton" <johngros.NOSPAM@bigpond.net.au>
Subject: References
Message-Id: <PsR76.57700$xW4.465562@news-server.bigpond.net.au>
I have passed a reference to a subroutine which performs look ups and
modifications to arrays, it works OK.
I have tried to combine nine subs into three to utilise common code.
The first subs were called by topleft(\@cell,'+',$i)
Now I am calling add(topleftcell,$i) using a regex to check if cell is in
$_[0] it assigns the ref \@cell to $array then performs the function.
Except it is not working as I expected. I am getting Global symbol "@array"
requires explicit package name at working.pl line 810.
I have tried single quotes to assign the ref.
perlreftut says assigning a reference is the same as assigning a scalar.
The sub is below.
sub add {
my ($modx, $mody, $array) = 0;
$_ = $_[0];
if (/top/){
$mody = -1;
}
if (/bottom/){
$mody = 1;
}
if (/right/){
$modx = 1;
}
if (/left/){
$modx = -1;
}
if (/cell/){
$array = "\\@cell";
}
if (/old/){
$array = "\\@old";
}
if (/mask/){
$array = "\\@mask";
}
if (defined($_[2])){
$array[$xaxis[$_[2]] + $modx][$yaxis[$_[2]] + $ mody] =
$array[$xaxis[$_[2]] + $modx][$yaxis[$_[2]] + $ mody] + $_[1];
}else{
$array[$xaxis + $modx][$yaxis + $mody] = $array[$xaxis + $modx][$yaxis +
$mody] + $_[1];
}
}
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 54
*************************************
