[23037] in Perl-Users-Digest
Perl-Users Digest, Issue: 5257 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 22 14:07:11 2003
Date: Tue, 22 Jul 2003 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, 22 Jul 2003 Volume: 10 Number: 5257
Today's topics:
Re: cwd with Net::SFTP <yanoff@STOP-SPAMMINGyahoo.com>
Re: File::Find is slower than using recursion!? <syscjm@gwu.edu>
Re: Get file extention from path <shawn@magma.ca>
Re: Import - Read file <syscjm@gwu.edu>
Re: JOIN problem ? (2nd attempt to post) <syscjm@gwu.edu>
Re: localize values of an object's hash key (John Porter)
Re: Multiple object types in a single .pm? <ubl@schaffhausen.de>
Re: Notepad Bug when editing Perl scripts in Win XP? <bik.mido@tiscalinet.it>
Re: One Off Script (JP Ogden)
pass all cgi parameters to an exe <d@d.com>
Re: Passing parameters to a Perl Script from Command Li <jurgenex@hotmail.com>
Re: perlcc makes it big <butt-fuzz@ass.wipe.com>
Re: perlcc makes it big <syscjm@gwu.edu>
Re: perlcc makes it big (Randal L. Schwartz)
Re: perlcc makes it big <nntp@cox.net>
Re: priority queue ctcgag@hotmail.com
Re: s there a module to acess Micorsoft Access datafile <wsegrave@mindspring.com>
Re: s there a module to acess Micorsoft Access datafile <stanb@panix.com>
Re: Stupid newbie question re website hit counting <glex_nospam@qwest.net>
Re: Stupid newbie question re website hit counting <gabriel.reid@removethis.explio.andthistoo.com>
Re: theory vs practice ceases power <peter@semantico.com>
Re: theory vs practice ceases power <cwilbur@mithril.chromatico.net>
Re: <bwalton@rochester.rr.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 22 Jul 2003 08:44:47 -0500
From: Scott Yanoff <yanoff@STOP-SPAMMINGyahoo.com>
Subject: Re: cwd with Net::SFTP
Message-Id: <3f1d3fd0$0$842$39cecf19@news.twtelecom.net>
Inna wrote:
> There is an option to use 'cwd' with the Net::FTP. How can I perform
> this action with the SFTP (I didn't find it in the info pages of
> Net::SFTP)?
I am not sure if you can cwd with SFTP. The perldoc mentions opendir,
perhaps that will work for you?
http://search.cpan.org/author/BTROTT/Net-SFTP-0.05/lib/Net/SFTP.pm#_sftp_do_opendir_path_
HTH,
--
-Scott
yanoff@STOP-SPAMMINGyahoo.com | http://www.yanoff.org | AOL IM: SAY KJY
------------------------------
Date: Tue, 22 Jul 2003 12:24:00 -0400
From: Chris Mattern <syscjm@gwu.edu>
Subject: Re: File::Find is slower than using recursion!?
Message-Id: <3F1D6520.1030702@gwu.edu>
David Oswald wrote:
> From: "Benjamin Goldberg" <ben.goldberg@hotpop.com>
> Subject: Re: File::Find is slower than using recursion!?
>
>
>
>>Steve Allan wrote:
>>
>>>It could also be that my sense that recursion is
>>>inherently slow is outdated and just not true in Perl.
>>
>>Recursion is most certainly *not* inherently slow. I can't think of a
>>time when it was... at least, not in perl.
>>
>
>
> <A lot of other stuff snipped>
>
> Recursion was slow in Pascal as implemented on old Apple IIe's. I think the
> issue was the overhead requried to push another function onto the stack.
And then, of course, there was the old IBM mainframe architecture--which
*didn't have a stack!* Lotsa fun, that was. Let me tell ya about SAVEAREA...
Chris Mattern
------------------------------
Date: Tue, 22 Jul 2003 11:24:09 -0400
From: Shawn Corey <shawn@magma.ca>
Subject: Re: Get file extention from path
Message-Id: <fNucnRuHxqoZy4CiXTWJkg@magma.ca>
Hi,
perldoc File::Basename
Read about fileparse.
Ron wrote:
> I need to get the file extension from a path(file location+file
> name+extension)
>
> This code get's me to the file name + extension.
>
> My beginner question is. How do I get just the extension?
>
> my $filename1 = $FILE1;
> $filename1 =~ s/^.*(\\|\/)//;
> $filename1 =~ s/ +/\_/g;
>
> Thanks,
> Ron
>
>
------------------------------
Date: Tue, 22 Jul 2003 12:27:18 -0400
From: Chris Mattern <syscjm@gwu.edu>
Subject: Re: Import - Read file
Message-Id: <3F1D65E6.2040508@gwu.edu>
ttnguyen wrote:
> Originally posted by Bob Walton
>
>>ttnguyen wrote:
>>
>>...
>>
>>>I have been working with ColdFusion and DB2 for about 1 month.
>>
>> I have a
>>
>>>question and hope someone could me me with.
>>>"How can I import an excel file to DB2 table"?
>>
>>...
>>
>>
>>
>>>-Thien
>>
>>...
>>
>>
>>And your Perl question is? Oh, you want to do it with Perl, not
>>ColdFusion? Modules are your friend. Check out:
>>
>> Win32::OLE (if you're on Windoze)
>> DBI
>> DBD::DB2
>> DBD::Excel
>> DBD::ODBC (if you're on Windoze)
>> Spreadsheet::ParseExcel
>>
>>--
>>Bob Walton
>
>
>
> Thanks for your answer. I do it with coldFusion NOT Perl. Thanks.
>
Then why the devil are you posting on comp.lang.perl.misc if your
question has nothing to do with Perl?
Chris Mattern
------------------------------
Date: Tue, 22 Jul 2003 12:19:28 -0400
From: Chris Mattern <syscjm@gwu.edu>
Subject: Re: JOIN problem ? (2nd attempt to post)
Message-Id: <3F1D6410.6010300@gwu.edu>
Tad McClellan wrote:
>
>
> % wasteland domains
> Score:: -9000
> From: aol\.com
> From: msn\.com
No webtv.com? Well, I suppose it is msntv.com now,
and in any any case, they were always too clueless
to even *find* Usenet....
Chris Mattern
------------------------------
Date: 22 Jul 2003 07:30:18 -0700
From: johndporter@yahoo.com (John Porter)
Subject: Re: localize values of an object's hash key
Message-Id: <95f344ba.0307220630.6b85bea7@posting.google.com>
"Joly, Patrick: IAC" <Joly.Patrick@ic.gc.ca> wrote:
> I need to localise (dynamically scope) the value of a hash key in an
> object...
>
> $tempname = $oo->tempvar();
>
> followed by,
>
> local $oo->{DATA}{"$tempname"};
> $oo->any_method( ... );
How about:
{
local $oo->{'access_key'} = $oo->tempvar;
$oo->any_method(...);
}
In other words, have a slot in the object for the value of the
temporary access key. This you can localize directly.
--
John Douglas Porter
------------------------------
Date: Tue, 22 Jul 2003 17:47:49 +0200
From: Malte Ubl <ubl@schaffhausen.de>
Subject: Re: Multiple object types in a single .pm?
Message-Id: <bfjpf5$f0c$1@news.dtag.de>
Bernie Cosell wrote:
> I just didn't know if there was any other "same-named magic" going on under
> the covers that I'd need to worry about [cf trying to understand what "use
> vars" does..:o)]
"use vars" is easy. "our" could become trickey in your case.
------------------------------
Date: Tue, 22 Jul 2003 16:36:28 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Notepad Bug when editing Perl scripts in Win XP?
Message-Id: <gnbqhvcotsgteb952pntfiu3ggkgt3ob90@4ax.com>
On Sat, 19 Jul 2003 11:03:33 -0500, randy <cry-ofan@mylinuxisp.com>
wrote:
>Has anyone else tried editing perl scripts in notepad in XP? I am
>getting some characters inserted into the scripts.....
<OT>
One might use whatever editor for a quick hack, or if in a hurry or
under emergency conditions. But why not using *any* decent one for
writing perl programs on a regular basis?!?
</OT>
Michele
--
# This prints: Just another Perl hacker,
seek DATA,15,0 and print q... <DATA>;
__END__
------------------------------
Date: 22 Jul 2003 09:39:00 -0700
From: jp@in3corp.com (JP Ogden)
Subject: Re: One Off Script
Message-Id: <4340eaf1.0307220839.11fc8fc0@posting.google.com>
The characters in "Field 1" could be the same number -
Like 1234 and 1235
Or 234- and 334-
The characters in "Field 1" could be as Jeff put them -
abc1def and abc2def
Or 045D/123 and 055D/123
The characters in "Field 1" could also be as Tad put them -
123 and 12X3
Or add-34 and add34
The list goes on...
tadmc@augustmail.com (Tad McClellan) wrote in message news:<slrnbhovrd.esp.tadmc@magna.augustmail.com>...
> JP Ogden <jp@in3corp.com> wrote:
>
>
> > Here is a sample of my data:
> > Field 1 Field 2 Field 3 Field 4 Field 5
> > 123 5675.68 5/24/03 Misc Misc2
> > E4678 345.76 6/23/02 Test Test2
> > 123A 8756.67 7/3/03 Code Code2
> > 0234 10456.45 6/4/02 Man Man2
> > 234 456.34 10/5/02 Talk Talk2
> > 675-02 1045.45 3/5/03 Level Level1
> > etc...
> >
> > I would like to isolate only the records where the records in "Field
> > 1" are "one-off." The results from the above sample would look like
> > this:
> > Field 1 Field 2 Field 3 Field 4 Field 5
> > 123 5675.68 5/24/03 Misc Misc2
> > 123A 8756.67 7/3/03 Code Code2
> >
> > and
> >
> > 0234 10456.45 6/4/02 Man Man2
> > 234 456.34 10/5/02 Talk Talk2
> >
> > because the records in "Field 1" are what I am calling "one-off."
>
>
> You mean one character shorter, by either taking the first or
> the last character off?
>
> Or should 123 and 12X3 be "one off" too?
>
> I'll assume the former.
>
>
> > The characters in "Field 1" can be anything.
>
>
> I will assume "anything except whitespace" below.
>
>
> > Any help would be greatly appreciated.
>
>
> --------------------------------------------------------
> #!/usr/bin/perl
> use strict;
> use warnings;
>
> my %seen;
> while ( <DATA> ) {
> $seen{$1} = $_ if /^(\S+)/;
> }
>
> my %reported;
> foreach my $f1 ( sort keys %seen ) {
> foreach my $shorter ( substr($f1, 0, -1), substr($f1, 1) ) {
> if ( $seen{$shorter} and not $reported{ "$seen{$shorter}:$f1" }) {
> $reported{ "$seen{$shorter}:$f1" } = 1;
> print $seen{$shorter}, $seen{$f1}, "\n";
> }
> }
> }
>
> __DATA__
> 123 5675.68 5/24/03 Misc Misc2
> E4678 345.76 6/23/02 Test Test2
> 123A 8756.67 7/3/03 Code Code2
> 0234 10456.45 6/4/02 Man Man2
> 234 456.34 10/5/02 Talk Talk2
> 675-02 1045.45 3/5/03 Level Level1
> --------------------------------------------------------
>
>
>
>
> [ snip TOFU.
> Please learn the proper way of formatting followups.
> ]
------------------------------
Date: Tue, 22 Jul 2003 13:12:46 GMT
From: "D" <d@d.com>
Subject: pass all cgi parameters to an exe
Message-Id: <iLaTa.107825$wk6.27853@rwcrnsc52.ops.asp.att.net>
i want to pass all cgi parameters to an exe (cgi app) and run the executable
and capture all of its output.
use CGI;
my $all_params;
my $thing = `C:/Inetpub/scripts/webapp.exe $all_params`;
print $thing;
this gives me a web page that declares and error, wich is what i would
expect, but this is good because when i pass it the right parameters i will
get back htm and i can parse it easily. the problem is i want to
impersonate what IIS would have passed if i did something like
http://site/scripts/webapp.exe and i thing the CGI module would do this for
me easily but dont know how.
------------------------------
Date: Tue, 22 Jul 2003 14:11:59 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Passing parameters to a Perl Script from Command Line (Linux)
Message-Id: <PCbTa.51725$EZ2.19870@nwrddc01.gnilink.net>
Dave from Dublin wrote:
> I'm fairly new to both programming in shell script (linux) and in
> programming in perl.
You also seem to be new to Usenet. Please do not multipost. I just answered
your question in the other NG and now there are two disjoint threads where
nobody knows what's going on in the other.
If you want to post in several NGs (which in general is frowned upon anyway)
then at least do a cross-posting.
jue
------------------------------
Date: Tue, 22 Jul 2003 11:14:24 -0400
From: butt-fuzz <butt-fuzz@ass.wipe.com>
Subject: Re: perlcc makes it big
Message-Id: <3F1D54D0.7ADE0F1D@ass.wipe.com>
Bob X wrote:
>
> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote in message
> news:1651df374de446c67b3b9ff84ac3d9d3@free.teranews.com...
> > >>>>> "butt-fuzz" == butt-fuzz <butt-fuzz@ass.wipe.com> writes:
> >
.............
> and compile it. He probably didn't understand that the Perl engine needs to
> go along with it.
>
> Bob
oh, yah.
I wanted to convert perl to c/c++.
------------------------------
Date: Tue, 22 Jul 2003 12:47:21 -0400
From: Chris Mattern <syscjm@gwu.edu>
Subject: Re: perlcc makes it big
Message-Id: <3F1D6A99.1080609@gwu.edu>
butt-fuzz wrote:
>
> Bob X wrote:
>
>>"Randal L. Schwartz" <merlyn@stonehenge.com> wrote in message
>>news:1651df374de446c67b3b9ff84ac3d9d3@free.teranews.com...
>>
>>>>>>>>"butt-fuzz" == butt-fuzz <butt-fuzz@ass.wipe.com> writes:
>>>>>>>
> .............
>
>>and compile it. He probably didn't understand that the Perl engine needs to
>>go along with it.
>>
>>Bob
>
> oh, yah.
>
> I wanted to convert perl to c/c++.
Then you should know up front that you aren't going to find a program
to do it for you.
Chris Mattern
------------------------------
Date: Tue, 22 Jul 2003 17:06:11 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: perlcc makes it big
Message-Id: <fe842b74b39d4d27ecb0726add078a62@free.teranews.com>
>>>>> "butt-fuzz" == butt-fuzz <butt-fuzz@ass.wipe.com> writes:
butt-fuzz> I wanted to convert perl to c/c++.
I guess the real questions are "why" and "have you read the FAQ on that
very item?".
Also "why are you posting behind an alias, because otherwise
I could just ask you this privately instead of making you look
foolish in public?"
print "Just another Perl hacker,"
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Tue, 22 Jul 2003 17:59:05 GMT
From: Matt H <nntp@cox.net>
Subject: Re: perlcc makes it big
Message-Id: <slrnbhqrcs.s0p.nntp@distraction.ath.cx>
In article <3F1C2B57.44D98CA9@ass.wipe.com>, butt-fuzz wrote:
> I'm running perl 5.8.0 on linux.
>
> I wrote a very simple program:
> #!/usr/bin/perl
> print "test";
>
> that's it!
> and ran perlcc.
> it gave me an a.out 1MB in size!
> yikes!
That's odd, I just ran perlcc on the same program and ended up with
37K (after stripping).
------------------------------
Date: 22 Jul 2003 17:44:25 GMT
From: ctcgag@hotmail.com
Subject: Re: priority queue
Message-Id: <20030722134425.296$Vx@newsreader.com>
"j" <perseus_medusa@hotmail.com> wrote:
> Hi all ,
>
> I am trying to implement a priority queue where people will submit
> some job through cgi written in perl and then another independent perl
> script will clear the queue. Different submitter has different priority.
> What's the best way to implement a global queue that can be accessed by
> the cgi and the perl script concurrently? We cannot use database though.
Why can you not use a database? Without knowing the rationale behind that
restriction, it's kind of hard to predict what solutions are available that
you *can* use.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service New Rate! $9.95/Month 50GB
------------------------------
Date: Tue, 22 Jul 2003 09:12:45 -0500
From: "William Alexander Segraves" <wsegrave@mindspring.com>
Subject: Re: s there a module to acess Micorsoft Access datafiles?
Message-Id: <bfjgsm$6ir$1@slb2.atl.mindspring.net>
"William Alexander Segraves" <wsegrave@mindspring.com> wrote in message
news:bfh7i3$obk$1@slb6.atl.mindspring.net...
> "James Willmore" <jwillmore@cyberia.com> wrote
<snip>
> > A CGI environment. In other words, you used a web server to connect
> > to the ODBC datasource?
>
> Well, yes, in the example I cited. It certainly wasn't necessary to use
the
> web server to connect to the ODBC data source. The examples I cited work
> fine from the command line as well, with no CGI server running at all.
>
Additional tests with this Win32 (Win95 4.00.950b) workstation, connecting
to an identical Win32 workstation, show that no server on either client or,
well, server, side is required, subject to the clarification that a file
server is implicit in the discussion.
Client side:
Using the ODBC Data Source Administrator provided by Win32
1. I set up a User DSN on this workstation with a unique name, i.e., never
before used on either workstation.
2. I mapped the User DSN in 1 above to the hard drive on the other Win32
workstation, after having first created a read-only share of the directory
in which the target *.mdb file resides.
3. I selected the *.mdb file in which the target tables reside.
(File) Server side:
This is the only setup that was required, i.e., no DSN on this side was
needed.
1. I set up a read-only share of the directory in which the target *mdb file
resides.
IMO, this is the closest that a Win32-Win32 setup can get to the scenario
posed by the OP in his original post.
With this setup, I ran the following script from the command line on the
Client side:
#!perl -w
# dbi_odbc_test_v2.pl
# Reference - p. 107, Cheetah Book
# usage -
use strict;
use CGI qw(:standard);
use DBI;
my $DSN = param('dsn');
my $table = param('table');
### The database handle
my $dbh = DBI->connect( "dbi:ODBC:$DSN", "", "" );
### The statement handle
my $sth = $dbh->prepare( "SELECT * FROM $table" );
$sth->execute();
print header, start_html;
# Ref: Cheetah Book, p. 116
my $rows = $sth->dump_results();
print end_html;
exit;
i.e.,
perl dbi_odbc_test_v2.pl dsn=contacts_nettie table=register
produced a dump of all of the lines of the table "register" in the default
comma-sep format. Note that I only used CGI.pm's HTML shortcuts to generate
HTML. This particular script has *never* run on a web server, not was such a
server running anywhere in/on the system/network at the time said tests were
performed. If I wanted to produce a raw comma-sep file, I'd simply leave out
the HTML shortcuts and redirect the output to a text file, e.g.,
perl dbi_odbc_test_v2.pl dsn=contacts_nettie table=register >
register.txt
> > So, the drivers needed to access the ODBC
> > datasource were on the Windows box, right?
>
> Yes.
<snip>
But not in the sense I think Jim meant. The drivers needed to access the
ODBC datasource were the ones that are resident on the Client side of the
transaction. No drivers or DSNs on the (File) Server side, other that those
that are utilized in a read-only share of a directory, were involved in the
transaction.
> > And the connection to the
> > Windows box was through a web server, right? So, basiclly, it didn't
> > work FROM the non-Windows machine without the use of a web server.
No. The connection was generated by the above script, operating from the
command line (in an MS-DOS Prompt Window) on the Client side.
> > Which is why I suggested useing DBI::Proxy - same concept, different
> > approach. Still need a server or drivers to run on one box or the
> > other to accomplish the task. Simply setting up a DSN on the Windows
> > box won't work without a server
>
I haven't tried DBI::Proxy; but I agree with the rest of Jim's statements,
except for the server part. No server, in the sense I think Jim meant, was
involved.
My tests indicate, so far, that the DSN should be set up on the side from
which the connection is initiated.
> This has not been supported by my (limited) tests. I'm pursuaded by actual
> tests that a web server is not required in order for the connection to
> succeed.
>
> As soon as I've installed DBD::ODBC on one of my Linux systems, I
> expect I'll be able to confirm this works with System DSNs defined on the
> Win32 system
Most recent tests suggest that System DSNs on the target Win32 system may
not be necessary, provided that all of the resources needed, Perl, DBI, and
DBD::ODBC (have these for both Win32 and *nix), ODBC Data Source
Adminstrator and MS Access Driver (have these for Win32).
> and the script/program using DBI and DBD::ODBC hosted on a
> Linux box to to access said DSNs.
>
The tests I just performed suggest it may be possible for this to all be
done from the Client side, provided the read-only shares of the target files
are set up on the Win32 (File) Server side. DBI and DBD::ODBC appear to have
what it takes to establish and maintain the connection from a *nix Client to
the Win32 file system. I have not yet found, installed, and tested an ODBC
datasource manager and MS Access drivers for a *nix Client side setup.
> OTOH, this is a low priority item for me. If the OP's curiosity overwhelms
> him before I get to it, he can pursue it himself with the recommendations
> I've given him.
The OP has indicated in a private communication that he has enough
information to get started; so I think we can give this thread a decent
burial now. ;-)
Cheers,
Bill Segraves
------------------------------
Date: Tue, 22 Jul 2003 16:44:49 +0000 (UTC)
From: Stan Brown <stanb@panix.com>
Subject: Re: s there a module to acess Micorsoft Access datafiles?
Message-Id: <bfjpm1$irp$1@reader1.panix.com>
In <bfjgsm$6ir$1@slb2.atl.mindspring.net> "William Alexander Segraves" <wsegrave@mindspring.com> writes:
>"William Alexander Segraves" <wsegrave@mindspring.com> wrote in message
>news:bfh7i3$obk$1@slb6.atl.mindspring.net...
>> "James Willmore" <jwillmore@cyberia.com> wrote
><snip>
>> > A CGI environment. In other words, you used a web server to connect
>> > to the ODBC datasource?
>>
>> Well, yes, in the example I cited. It certainly wasn't necessary to use
>the
>> web server to connect to the ODBC data source. The examples I cited work
>> fine from the command line as well, with no CGI server running at all.
>>
>Additional tests with this Win32 (Win95 4.00.950b) workstation, connecting
>to an identical Win32 workstation, show that no server on either client or,
>well, server, side is required, subject to the clarification that a file
>server is implicit in the discussion.
>Client side:
>Using the ODBC Data Source Administrator provided by Win32
>1. I set up a User DSN on this workstation with a unique name, i.e., never
>before used on either workstation.
>2. I mapped the User DSN in 1 above to the hard drive on the other Win32
>workstation, after having first created a read-only share of the directory
>in which the target *.mdb file resides.
>3. I selected the *.mdb file in which the target tables reside.
>(File) Server side:
>This is the only setup that was required, i.e., no DSN on this side was
>needed.
>1. I set up a read-only share of the directory in which the target *mdb file
>resides.
>IMO, this is the closest that a Win32-Win32 setup can get to the scenario
>posed by the OP in his original post.
>With this setup, I ran the following script from the command line on the
>Client side:
>#!perl -w
># dbi_odbc_test_v2.pl
># Reference - p. 107, Cheetah Book
># usage -
>use strict;
>use CGI qw(:standard);
>use DBI;
>my $DSN = param('dsn');
>my $table = param('table');
>### The database handle
>my $dbh = DBI->connect( "dbi:ODBC:$DSN", "", "" );
>### The statement handle
>my $sth = $dbh->prepare( "SELECT * FROM $table" );
>$sth->execute();
>print header, start_html;
># Ref: Cheetah Book, p. 116
>my $rows = $sth->dump_results();
>print end_html;
>exit;
>i.e.,
> perl dbi_odbc_test_v2.pl dsn=contacts_nettie table=register
>produced a dump of all of the lines of the table "register" in the default
>comma-sep format. Note that I only used CGI.pm's HTML shortcuts to generate
>HTML. This particular script has *never* run on a web server, not was such a
>server running anywhere in/on the system/network at the time said tests were
>performed. If I wanted to produce a raw comma-sep file, I'd simply leave out
>the HTML shortcuts and redirect the output to a text file, e.g.,
> perl dbi_odbc_test_v2.pl dsn=contacts_nettie table=register >
>register.txt
>> > So, the drivers needed to access the ODBC
>> > datasource were on the Windows box, right?
>>
>> Yes.
><snip>
>But not in the sense I think Jim meant. The drivers needed to access the
>ODBC datasource were the ones that are resident on the Client side of the
>transaction. No drivers or DSNs on the (File) Server side, other that those
>that are utilized in a read-only share of a directory, were involved in the
>transaction.
>> > And the connection to the
>> > Windows box was through a web server, right? So, basiclly, it didn't
>> > work FROM the non-Windows machine without the use of a web server.
>No. The connection was generated by the above script, operating from the
>command line (in an MS-DOS Prompt Window) on the Client side.
>> > Which is why I suggested useing DBI::Proxy - same concept, different
>> > approach. Still need a server or drivers to run on one box or the
>> > other to accomplish the task. Simply setting up a DSN on the Windows
>> > box won't work without a server
>>
>I haven't tried DBI::Proxy; but I agree with the rest of Jim's statements,
>except for the server part. No server, in the sense I think Jim meant, was
>involved.
>My tests indicate, so far, that the DSN should be set up on the side from
>which the connection is initiated.
>> This has not been supported by my (limited) tests. I'm pursuaded by actual
>> tests that a web server is not required in order for the connection to
>> succeed.
>>
>> As soon as I've installed DBD::ODBC on one of my Linux systems, I
>> expect I'll be able to confirm this works with System DSNs defined on the
>> Win32 system
>Most recent tests suggest that System DSNs on the target Win32 system may
>not be necessary, provided that all of the resources needed, Perl, DBI, and
>DBD::ODBC (have these for both Win32 and *nix), ODBC Data Source
>Adminstrator and MS Access Driver (have these for Win32).
>> and the script/program using DBI and DBD::ODBC hosted on a
>> Linux box to to access said DSNs.
>>
>The tests I just performed suggest it may be possible for this to all be
>done from the Client side, provided the read-only shares of the target files
>are set up on the Win32 (File) Server side. DBI and DBD::ODBC appear to have
>what it takes to establish and maintain the connection from a *nix Client to
>the Win32 file system. I have not yet found, installed, and tested an ODBC
>datasource manager and MS Access drivers for a *nix Client side setup.
>> OTOH, this is a low priority item for me. If the OP's curiosity overwhelms
>> him before I get to it, he can pursue it himself with the recommendations
>> I've given him.
>The OP has indicated in a private communication that he has enough
>information to get started; so I think we can give this thread a decent
>burial now. ;-)
Mmm, as teh OP, I'm still trying to get a handle on this.
It _appears to me_ that what has been done hser, will still use teh
"provate knowledge" that the Win32 perl ODBC module has about the Access
database. Am I missing something here? If so then how would you specify
the DSb on the clinet side for a remote windows amchien? You would have to
be able to resolve both machine IP address, and the DSN on that machine,
right?
Or does the *NIX version of the ODBC perl module also have knowledge of the
format of Access files? Which seems to be the way that this assumes things
will work (based upon needing mountung the filesystem with the Access
files).
> perl dbi_odbc_test_v2.pl dsn=contacts_nettie table=register
How would this be specifed for a remote machien?
--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin
------------------------------
Date: Tue, 22 Jul 2003 08:58:28 -0500
From: "J. Gleixner" <glex_nospam@qwest.net>
Subject: Re: Stupid newbie question re website hit counting
Message-Id: <bpbTa.102$bG2.18165@news.uswest.net>
Michael McLaughlin wrote:
> Once a month, I run a (mostly perl) script that reads my all my
> webserver log files and tallies hits to several webpages. However, I
> have always wondered about the accuracy of these counts.
>
> Specifically, if a reader has been to a page before, has this page in
> his browser cache and surfs to that URL, does the log still register
> that hit with the usual status code (200)? Does it register it at all?
>
> Thanks in advance for any tips.
What does this have to do with perl? If you're curious, visit your site
and watch your log to see if it logs it or not.
------------------------------
Date: Tue, 22 Jul 2003 15:57:40 +0200
From: "Gabriel Reid" <gabriel.reid@removethis.explio.andthistoo.com>
Subject: Re: Stupid newbie question re website hit counting
Message-Id: <bfjg08$l3t$1@reader10.wxs.nl>
"Michael McLaughlin" <mpmcl@mitre.org> wrote in message
news:bfja38$hpb$1@newslocal.mitre.org...
> Once a month, I run a (mostly perl) script that reads my all my
> webserver log files and tallies hits to several webpages. However, I
> have always wondered about the accuracy of these counts.
>
> Specifically, if a reader has been to a page before, has this page in
> his browser cache and surfs to that URL, does the log still register
> that hit with the usual status code (200)? Does it register it at all?
>
> Thanks in advance for any tips.
>
> --
> Mike McLaughlin
>
This is a perl newsgroup, not a webserver newsgroup or HTTP newsgroup, and
as such this post is quite off-topic.
Additionally, the logging of requests in your webserver's logs are dependent
upon which server you are using (you neglected to post that information),
and how it is configured. However, in general an unmodified document that is
in the browser cache will be logged as a 304, not a 200. It will be logged
as a 200 if it is actually fetched from the server. For more information
about this I suggest that you look at this document:
http://www.w3.org/Protocols/rfc2616/rfc2616.html
Gabriel
------------------------------
Date: Tue, 22 Jul 2003 14:39:30 +0100
From: Peter Hickman <peter@semantico.com>
Subject: Re: theory vs practice ceases power
Message-Id: <3f1d3e92$0$14549$afc38c87@news.easynet.co.uk>
Xah Lee wrote:
> i'm posting the following in hope that "theory vs practice" can cease
> its misleading power.
And I read it with the hope that it might actually be about perl or the
practice of perl or even vaguley about programming.
Look out for someone called Arthur T. Murray, you should get along swell.
------------------------------
Date: Tue, 22 Jul 2003 13:57:07 GMT
From: Charlton Wilbur <cwilbur@mithril.chromatico.net>
Subject: Re: theory vs practice ceases power
Message-Id: <871xwi8y8o.fsf@mithril.chromatico.net>
xah@xahlee.org (Xah Lee) writes:
> i'm posting the following in hope that "theory vs practice" can cease
> its misleading power.
> merlyn@stonehenge.com (Randal L. Schwartz) quoted:
> | The difference between theory and practice in theory is much less
> | than the difference between theory and practice in practice.
>
> Popular quotes have attributes of equivocal interpretation and
> theatrical display. When interpreted and pondered by the wise, it
> lights up a wisdom, but dullards quote them equally, and delight in
> their drama. (the latter happens a lot in Perl and unix communities.)
Actually, what Mr Schwartz is pointing out is that there are details
encountered in practice that, for one reason or another, are not
sufficiently addressed by the theory. Because they are not addressed
by the theory, people who start with the theory are unlikely to be
aware of them, while people who start with the practice are likely to
be keenly aware of them.
This is what Mr Schwartz's quote means. There's not a whole lot of
room for equivocal interpretation of his words; perhaps you are
quoting it and delighting in any drama you may create by it?
Charlton
------------------------------
Date: Sat, 19 Jul 2003 01:59:56 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re:
Message-Id: <3F18A600.3040306@rochester.rr.com>
Ron wrote:
> Tried this code get a server 500 error.
>
> Anyone know what's wrong with it?
>
> if $DayName eq "Select a Day" or $RouteName eq "Select A Route") {
(---^
> dienice("Please use the back button on your browser to fill out the Day
> & Route fields.");
> }
...
> Ron
...
--
Bob Walton
------------------------------
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.
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 5257
***************************************
