From tim at consultix-inc.com Mon Sep 1 12:47:09 2003 From: tim at consultix-inc.com (Tim Maher) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: Reviewers for Perl-Cert article? Message-ID: <20030901104709.A18827@timji.consultix-inc.com> SPUGsters, I've written an article explaining my thoughts on why a Perl Certification program could be good for our community. It's slated for publication in a "well known on-line Perl-ezine" soon, but before I send it in, I'd be grateful for input from SPUGsters, ranging from typo-spotting to argument-debugging. Unlike my book chapters, which I haven't sent to any volunteer reviewer yet, this is ready to go and I can send it today. Any takers? -Tim *------------------------------------------------------------* | Tim Maher (206) 781-UNIX (866) DOC-PERL (866) DOC-UNIX | | tim(AT)Consultix-Inc.Com TeachMeUnix.Com TeachMePerl.Com | *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-* | Watch for my Book: "Minimal Perl for Shell Programmers" | *------------------------------------------------------------* From Marc.M.Adkins at Doorways.org Sun Sep 7 16:59:32 2003 From: Marc.M.Adkins at Doorways.org (Marc M. Adkins) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: Perl/POD -> doxygen filter In-Reply-To: <20030901104709.A18827@timji.consultix-inc.com> Message-ID: I got a wild hair several weekends ago and wrote some code to parse POD-enabled Perl and generate fake C/C++ and doxygen comments. The idea being to use doxygen on Perl projects, even if they weren't meant for it. The script does some guessing about what's in the POD. Like it matches up =item markers that have the same name as functions found in the Perl source. So all that legacy Perl code with POD comments dovetails nicely with the pretty pictures that doxygen can generate. I've been having some fun running it against pieces of the standard Perl library (the modules in @INC that just come with Perl). I haven't tried running it against the entire library yet, it takes long enough just to do pieces of it (mostly doxygen time). Still, it's kind of neat to see what it will generate out of the IO:: or LWP:: subtrees. I thought I might be able to get some local feedback on it prior to packaging it up for release. It's still pretty rough and a lot of things are missing (I don't try to parse out variables, for example). But it seems to work OK on 80-90% of test cases I've used. Anyone who is interested in this can find more information at: http://spugwiki.perlocity.org/index.cgi?doxyfilt mma From keith.reed at philips.com Wed Sep 10 17:41:14 2003 From: keith.reed at philips.com (keith.reed@philips.com) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: UW Extension Perl Offerings Message-ID: I just wanted to put in a shameless plug in for the Perl Programming Certificate through the UW Extension. I'll be teaching the winter "Advanced Concepts" course. Here are the details for the entire program: Basic Perl Programming Provides an introduction to Perl programming. Topics: The Perl world; www.perl.com, CPAN, documentation, resources Basic data types, scalar, arrays and hashes Regular expressions Control structures, loops and blocks Subroutines I/O and file and directory functions Understanding and using scope Schedule: (10 sessions), Mondays, 6-9 p.m., Sept. 29-Dec. 1, 2003; 3 CEUs. Advanced Perl Concepts Builds on the foundation of Basic Perl Programming, introducing increasingly sophisticated Perl tools and techniques. Topics: DBM files References and complex data structures Introduction to relational database access and the DBI module Object-oriented programming Encapsulation Inheritance Polymorphism Persistence Schedule: (10 sessions) Mondays, 6-9 p.m., Jan. 5-March 22, 2004 (no class Jan. 19 and Feb. 16); 3 CEUs. Perl, the Web and Databases The program's final term applies the tools of Perl to web and internet programming. Topics: HTML, HTTP, CGI, SSL Using CGI.pm Persistence on the web SQL and DBI.pm Apache and mod-Perl XML, SOAP and Web Services Real-world web site design Schedule: (10 sessions) Mondays, 6-9 p.m., March 29-June 7, 2004 (no class May 31); 3 CEUs. You can get more details at http://www.extension.washington.edu/ext/certificates/per/per_gen.asp Hope to see you there! Keith Reed --------------------------------- Software Engineer Philips Medical Systems (425) 482-8338 From jmail at poplarware.com Wed Sep 10 18:58:37 2003 From: jmail at poplarware.com (Jennifer Hodgdon) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: SPUG digest frequency In-Reply-To: <200309102242.h8AMg3J07728@mail.pm.org> Message-ID: <5.2.1.1.2.20030910165449.01aff140@mail.poplarware.com> Is it just me -- I'm on the SPUG digest, and I just got a notice today (9/10) that there was an Open Sauce lunch on 8/29. I thought the digest was supposed to be sent out daily -- this was almost two weeks too late. This digest included messages from 8/28 through 9/10. Anyway, I'll probably change my subscription to non-digest, but maybe the list admin could either check the digest settings, or put something on the mailing list subscription page that says the digest is every few weeks instead of daily. Thanks, Jennifer ____________________________ Jennifer Hodgdon Poplar ProductivityWare Practical Solutions for Office Tedium Reduction jmail@poplarware.com http://www.poplarware.com From cjcollier at colliertech.org Thu Sep 11 14:27:15 2003 From: cjcollier at colliertech.org (C.J. Collier) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: Dancerboy Message-ID: <1063308435.954.14.camel@karma.localnet> One of our members, dancerboy, recently passed away. He left us this: http://my.strangelight.com/ C.J. From kmeyer at blarg.net Fri Sep 12 13:21:36 2003 From: kmeyer at blarg.net (Ken Meyer) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: Greater Seattle Linux Users Group Mtg. Sat, Sept 13th Message-ID: The next Greater Seattle Linux User Group (GSLUG) meeting will be on Saturday, September 13th. It starts promptly at 10:00 a.m. at the North Seattle Community College Campus. For directions, agenda, and lecturer bios, please visit the GSLUG monthly meetings web page at: http://www.gslug.org/meeting.html The lecture subjects will be: 10:00 AM: "Content Wars: Fighting the Gatekeepers", by special guest JD "Illiad" Frazer, cartoonist and proprietor of the User Friendly web comic strip. http://www.userfriendly.org/ J.D. uses UserFriendly.org as a case study of not only why, but how, the traditional content distributors should be fought tooth and nail, given the advent of the Net. He explains the harsh realities of doing business as a content creator and covers both the upside and downside of the medium that we rely on for much of our information and entertainment. 11:15 AM: "The Linux Boot Process", by Jeremy C. Reed, open source columnist, developer, and trainer. http://www.pugetsoundtechnology.com/ This lecture will cover the Linux boot process, starting with the Linux System V init process (the parent of all processes) and the various System V-style resource control (RC) scripts. It will include examples of common inittab configurations, the ordering of startup scripts and their application to different runlevels. It will also address examples of various Unix startup scripts. If you have any questions about the boot process, or examples to suggest for the presentation, feel free to discuss them with Jeremy ahead of time (reed@reedmedia.net). Also, as this meeting is likely to draw a larger-than-normal crowd, anyone interested in exchanging PGP keys is encouraged to bring copies of their keyid/fingerprint to the meeting for an informal key exchange. Please feel free to forward this announcement as appropriate. To ensure that you receive future GSLUG announcements. Please join the GSLUG-Announce list at: http://lists.gslug.org/mailman/listinfo/gslug-announce You are also cordially invited to join the general discussion list at: http://lists.gslug.org/mailman/listinfo/gslug-general A message board alternative may be found at: http://msgboard.gslug.org/ And a fledgling wiki site at: http://wiki.gslug.org/ The GSLUG Crew ------------------------- NOTE: The overall GSLUG meeting schedule is as follows: 10:00 AM Lecture #1 11:00 AM Break 11:10 AM Raffle Quiz 11:15 AM Lecture #2 12:15 AM Break 12:30 PM Raffle prizes giveaway 12:35 PM GSLUG Announcements Announcements from attendees Request for assistance 1:00 PM-ish Formal meeting is adjourned, 'help/gab' session begins * Informal PGP key signing * Attendees can help those who requested assistance * Install fest/assistance * Talking, chatting, blathering, etc, etc 4:00 PM End of meeting From tim at consultix-inc.com Fri Sep 12 13:42:09 2003 From: tim at consultix-inc.com (Tim Maher) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: "Illiad" spkg to GSLUG 9/13 Message-ID: <20030912114209.A17803@timji.consultix-inc.com> The next Greater Seattle Linux User Group (GSLUG) meeting will be on Saturday, September 13th. It starts promptly at 10:00 a.m. at the North Seattle Community College Campus. For directions, agenda, and lecturer bios, please visit the GSLUG monthly meetings web page at: http://www.gslug.org/meeting.html The lecture subjects will be: 10:00 AM: "Content Wars: Fighting the Gatekeepers", by special guest JD "Illiad" Frazer, cartoonist and proprietor of the User Friendly web comic strip. http://www.userfriendly.org/ J.D. uses UserFriendly.org as a case study of not only why, but how, the traditional content distributors should be fought tooth and nail, given the advent of the Net. He explains the harsh realities of doing business as a content creator and covers both the upside and downside of the medium that we rely on for much of our information and entertainment. 11:15 AM: "The Linux Boot Process", by Jeremy C. Reed, open source columnist, developer, and trainer. http://www.pugetsoundtechnology.com/ This lecture will cover the Linux boot process, starting with the Linux System V init process (the parent of all processes) and the various System V-style resource control (RC) scripts. It will include examples of common inittab configurations, the ordering of startup scripts and their application to different runlevels. It will also address examples of various Unix startup scripts. If you have any questions about the boot process, or examples to suggest for the presentation, feel free to discuss them with Jeremy ahead of time (reed@reedmedia.net). Also, as this meeting is likely to draw a larger-than-normal crowd, anyone interested in exchanging PGP keys is encouraged to bring copies of their keyid/fingerprint to the meeting for an informal key exchange. Please feel free to forward this announcement as appropriate. To ensure that you receive future GSLUG announcements. Please join the GSLUG-Announce list at: http://lists.gslug.org/mailman/listinfo/gslug-announce You are also cordially invited to join the general discussion list at: http://lists.gslug.org/mailman/listinfo/gslug-general A message board alternative may be found at: http://msgboard.gslug.org/ And a fledgling wiki site at: http://wiki.gslug.org/ The GSLUG Crew ------------------------- NOTE: The overall GSLUG meeting schedule is as follows: 10:00 AM Lecture #1 11:00 AM Break 11:10 AM Raffle Quiz 11:15 AM Lecture #2 12:15 AM Break 12:30 PM Raffle prizes giveaway 12:35 PM GSLUG Announcements Announcements from attendees Request for assistance 1:00 PM-ish Formal meeting is adjourned, 'help/gab' session begins * Informal PGP key signing * Attendees can help those who requested assistance * Install fest/assistance * Talking, chatting, blathering, etc, etc 4:00 PM End of meeting -- -Tim *------------------------------------------------------------* | Tim Maher (206) 781-UNIX (866) DOC-PERL (866) DOC-UNIX | | tim(AT)Consultix-Inc.Com TeachMeUnix.Com TeachMePerl.Com | *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-* | Watch for my Book: "Minimal Perl for Shell Programmers" | *------------------------------------------------------------* From kmeyer at blarg.net Sat Sep 13 00:15:06 2003 From: kmeyer at blarg.net (Ken Meyer) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: ATTENTION: GSLUG Meeting Room Change Message-ID: Greetings fellow Geek-ites -- Response to the meeting tomorrow seems very strong, judging from my mailbox today. For those who just returned to Earth: http://www.gslug.org/meeting.html I was pleasantly surprised to be able to snare for us the room on campus that I really wanted; but at the cost of possible temporary consternation amongst the troops. Sorry for the late notice. The new location is in the "High Technology Learning Center, Room 2843A" -- the big room on the top floor. For GSLUG old-timers, this is the room we used to meet in at NSCC. For others, this building is now officially referred to as the "Dr. Peter C. Ku Education Building" -- but you will never hear me call it that (at least without a few well-chosen adjectives attached). By the way, it is NOT the Technology Building, which is one tier to the west. In any event, it is located diagonally completely across the campus from our accustomed location, in the Southeast corner of the campus. See: http://www.northseattle.edu/maps/directions.htm For general directions, and: http://www.northseattle.edu/maps/campus.htm For the building location. See it up at the top of the picture, vanishing into the perspective convergence? It is located right at the intersection of "Eighth Avenue" (Latitude) and Grid-line 47 (Longitude). Lots of parking to the East of the building -- no charge on Saturday. I will try to have directions at the old location, as well. About 56 seats at tables and another 40 chairs in racks, if the Grounds Staff doesn't kype them tonight. First class, uptown, etc. Hope to se a lot of you! Ken Meyer From tim at consultix-inc.com Sat Sep 13 15:13:55 2003 From: tim at consultix-inc.com (Tim Maher) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: Sept. Mtg 9/16: Ingy on Kwiki Message-ID: <20030913131355.A21742@timji.consultix-inc.com> SPUGsters, Andy Sweger will be your host for next Tuesday's meeting, while I'm in New York on "Dalai Lama Business" -- and no, I'm not teaching him Perl! Enjoy! -Tim September Seattle Perl Users Group Meeting -------------------------------------------------------- Title: "Kwiki" Speaker: Brian Ingerson Ingy will review the latest developments in his popular Kwiki software (see kwiki.org), that fuels spugwiki.perlocity.org, and many other Wiki sites. Meeting Time: Tuesday, Sept. 16, 2003 7-9pm Location: SAFECO bldg, Brooklyn St. and NE 45th St. Cost: Admission is free and open to the general public. Info: http://seattleperl.org/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Pre- and Post- Meeting Activities --------------------------------- The pre-meeting dinner will be at the Cedars restaurant, at 50th St. and Brooklyn, in the University District, near the Safeco building where the meeting will take place. The phone number is 527-5247. If you are planning to be there, please enter your name on the Kwiki RSVP page by 2pm on the meeting day. (NOTE: Arrival by 5:45pm is recommended for those ordering food). Those who comply with the RSVP policy, and are therefore counted in the seating reservation, will have top priority for seating at the speaker's table. ====================================================== | Tim Maher, Ph.D. tim@timmaher.org | | SPUG Founder & Leader spug@seattleperl.org | | Seattle Perl Users Group www.seattleperl.org | ====================================================== From bri at ifokr.org Sun Sep 14 00:47:41 2003 From: bri at ifokr.org (Brian Hatch) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: 'Last chance' for Nmap scans. Message-ID: <20030914054741.GM27660@ifokr.org> The newest Nmap scanner, with it's new service fingerprinting feature, is likely going to be released next week. As one of the beta testers, I'd love to have it populated with as many fingerprints as possible when it ships. If anyone has a machine or machines that they'd be willing for me to scan, please email me back. The 'requirements' are as follows: * machine/machines need to be reachable from the Internet. * machine/machines are yours, or you have permission to give me permission to scan them. * if unknown services are found, you would be willing to look up and tell me the name and version of the software that's listening on that port. I'm particularly interested in any SSL services, as I helped add the SSL support and would like to test it on as many different machines as possible. If you're interested, just send me an email. All scans will come from my server IP addr 216.162.217.155, I'll tell you when I begin and end the scans, and send you the report when done even if it doesn't find anything interesting. If you want to be really trusting and turn off any firewall for that port, all the better. -- Brian Hatch There is no god but good, Systems and And Occam is his Prophet. Security Engineer -- Dave Champion http://www.ifokr.org/bri/ Every message PGP signed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/spug-list/attachments/20030913/a50c3afe/attachment.bin From andrew at sweger.net Tue Sep 16 10:40:17 2003 From: andrew at sweger.net (Andrew Sweger) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: Wireless fun at SPUG Message-ID: In theory, I will have a server and 802.11b wireless access point (and possibly a wired hub too) at tonight's meeting for the purpose of demonstrating Brian's Kwiki (however, we will not be demonstrating Brian's modules[1]). The system should allow folks to connect to the private network and interact with Brian's demonstrations. Access to the Internet cannot be provided at this time. I'll be working on setting up the server today (which was having hardware problems the last time I worked on it) and hopefully everything works out. Besides my usual procrastination, I just returned yesterday from a road trip with my dad to see his father in Hemet, CA. Grandpa recently "broke his neck and fell down" (which, amazingly, hasn't effected his ability to walk and breathe). He's doing fine. Don't forget that, if you intend to join SPUG'ers for dinner tonight, you need to RSVP on the SPUGwiki by putting your name (or nom de plume) on this page: http://spugwiki.perlocity.org/?NextMeetingDinnerRSVPs I will not be joining folks for dinner tonight as I need to get things set up in the auditorium. I'll call in a reservation under the name "Spug" to the restaurant at 2:00 this afternoon based on RSVP's at that time. [1] - It's a YAPC joke. If you don't get it, talk to me on the side and I'll explain. It's crass. -- Andrew B. Sweger -- The great thing about multitasking is that several things can go wrong at once. From pdarley at kinesis-cem.com Tue Sep 16 12:09:14 2003 From: pdarley at kinesis-cem.com (Peter Darley) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: while question Message-ID: Folks, I have yet another stupid question: I regularly get data out of a DBI statement handle by doing: while ($MyData = $sth->fetchrow()) { stuff } This falls down when the data returned from the statement is '0', since it's not true, and the while breaks. I've tried while (defined $MyData = $sth->fetchrow()), but this is not syntacticly correct, and would break on a database NULL (which is undef in perl) anway. I can do something like while ($MyRef = $sth->fetchrow_hashref()) {$MyData = $$MyRef{datapoint}; stuff}, but I'm not too fond of that. Does anyone have a suggestion on a better way to construct this loop? Thanks, Peter Darley From mathin at mathin.com Tue Sep 16 12:33:56 2003 From: mathin at mathin.com (Dan Ebert) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: while question In-Reply-To: References: Message-ID: <1063733635.22731.11.camel@algernon.lan.enic.cc> I think you could use: while( my @data = $sth->fetchrow_array) { } Dan. On Tue, 2003-09-16 at 10:09, Peter Darley wrote: > Folks, > I have yet another stupid question: > > I regularly get data out of a DBI statement handle by doing: > > while ($MyData = $sth->fetchrow()) > { > stuff > } > > This falls down when the data returned from the statement is '0', since > it's not true, and the while breaks. I've tried while (defined $MyData = > $sth->fetchrow()), but this is not syntacticly correct, and would break on a > database NULL (which is undef in perl) anway. I can do something like while > ($MyRef = $sth->fetchrow_hashref()) {$MyData = $$MyRef{datapoint}; stuff}, > but I'm not too fond of that. Does anyone have a suggestion on a better way > to construct this loop? > > Thanks, > Peter Darley > > _____________________________________________________________ > Seattle Perl Users Group Mailing List > POST TO: spug-list@mail.pm.org http://spugwiki.perlocity.org > ACCOUNT CONFIG: http://mail.pm.org/mailman/listinfo/spug-list > MEETINGS: 3rd Tuesdays, U-District, Seattle WA > WEB PAGE: http://www.seattleperl.org > From tnight at pobox.com Tue Sep 16 12:42:06 2003 From: tnight at pobox.com (Terry Nightingale) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: while question In-Reply-To: References: Message-ID: <3F674B6E.9030503@pobox.com> Peter, I personally would use either $sth->fetchrow_hashref() or $sth->fetchrow_arrayref() in exactly the manner you describe below. The nice thing about getting a reference to the data rather than just the data itself is exactly what you're running up against. Even if you have a reference to '0' or undef, the reference itself is both defined and true, so your loop works correctly. Hope that helps, Terry Peter Darley wrote: > Folks, > I have yet another stupid question: > > I regularly get data out of a DBI statement handle by doing: > > while ($MyData = $sth->fetchrow()) > { > stuff > } > > This falls down when the data returned from the statement is '0', since > it's not true, and the while breaks. I've tried while (defined $MyData = > $sth->fetchrow()), but this is not syntacticly correct, and would break on a > database NULL (which is undef in perl) anway. I can do something like while > ($MyRef = $sth->fetchrow_hashref()) {$MyData = $$MyRef{datapoint}; stuff}, > but I'm not too fond of that. Does anyone have a suggestion on a better way > to construct this loop? > > Thanks, > Peter Darley > > _____________________________________________________________ > Seattle Perl Users Group Mailing List > POST TO: spug-list@mail.pm.org http://spugwiki.perlocity.org > ACCOUNT CONFIG: http://mail.pm.org/mailman/listinfo/spug-list > MEETINGS: 3rd Tuesdays, U-District, Seattle WA > WEB PAGE: http://www.seattleperl.org > > > From pdarley at kinesis-cem.com Tue Sep 16 13:06:24 2003 From: pdarley at kinesis-cem.com (Peter Darley) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: while question In-Reply-To: <3F674B6E.9030503@pobox.com> Message-ID: Folks, Thanks for everyone's suggestions. It looks like the consensus is that its best to get back a reference so the while() doesn't check the value of what's returned, just that there's something there. The only reason I don't like getting the reference is that I want to make sure that if I have a single value, it's in a scalar. If there is a hash or an array it should hold multiple values. This keeps the application stylistically consistent and easier to go through at some later date. I guess I'll go with while ($Ref = $sth->fetchrow) {$MyValue = $$Ref[1]; stuff} Thanks for everyone's input! :) Thanks, Peter Darley -----Original Message----- From: Terry Nightingale [mailto:tnight@pobox.com] Sent: Tuesday, September 16, 2003 10:42 AM To: Peter Darley Cc: SPUG Subject: Re: SPUG: while question Peter, I personally would use either $sth->fetchrow_hashref() or $sth->fetchrow_arrayref() in exactly the manner you describe below. The nice thing about getting a reference to the data rather than just the data itself is exactly what you're running up against. Even if you have a reference to '0' or undef, the reference itself is both defined and true, so your loop works correctly. Hope that helps, Terry Peter Darley wrote: > Folks, > I have yet another stupid question: > > I regularly get data out of a DBI statement handle by doing: > > while ($MyData = $sth->fetchrow()) > { > stuff > } > > This falls down when the data returned from the statement is '0', since > it's not true, and the while breaks. I've tried while (defined $MyData = > $sth->fetchrow()), but this is not syntacticly correct, and would break on a > database NULL (which is undef in perl) anway. I can do something like while > ($MyRef = $sth->fetchrow_hashref()) {$MyData = $$MyRef{datapoint}; stuff}, > but I'm not too fond of that. Does anyone have a suggestion on a better way > to construct this loop? > > Thanks, > Peter Darley > > _____________________________________________________________ > Seattle Perl Users Group Mailing List > POST TO: spug-list@mail.pm.org http://spugwiki.perlocity.org > ACCOUNT CONFIG: http://mail.pm.org/mailman/listinfo/spug-list > MEETINGS: 3rd Tuesdays, U-District, Seattle WA > WEB PAGE: http://www.seattleperl.org > > > From AEH at akc.org Tue Sep 16 13:25:21 2003 From: AEH at akc.org (Adrian Hands) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: while question Message-ID: The real problem here is fetchrow() returns a list and you're assigning it to a scalar. Simply add some parens and your while loop will no longer incorrectly break on zero. I.e.: while ( ( $MyData ) = $sth->fetchrow() ) Peter Darley wrote: > Folks, > I have yet another stupid question: > > I regularly get data out of a DBI statement handle by doing: > > while ($MyData = $sth->fetchrow()) > { > stuff > } > > This falls down when the data returned from the statement is '0', since > it's not true, and the while breaks. I've tried while (defined $MyData = > $sth->fetchrow()), but this is not syntacticly correct, and would break on a > database NULL (which is undef in perl) anway. I can do something like while > ($MyRef = $sth->fetchrow_hashref()) {$MyData = $$MyRef{datapoint}; stuff}, > but I'm not too fond of that. Does anyone have a suggestion on a better way > to construct this loop? > > Thanks, > Peter Darley From pdarley at kinesis-cem.com Tue Sep 16 13:37:32 2003 From: pdarley at kinesis-cem.com (Peter Darley) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: while question In-Reply-To: Message-ID: Adrian, That is exactly what I was looking for! Thanks, Peter Darley -----Original Message----- From: spug-list-bounces@mail.pm.org [mailto:spug-list-bounces@mail.pm.org]On Behalf Of Adrian Hands Sent: Tuesday, September 16, 2003 11:25 AM To: spug-list@mail.pm.org Subject: Re: SPUG: while question The real problem here is fetchrow() returns a list and you're assigning it to a scalar. Simply add some parens and your while loop will no longer incorrectly break on zero. I.e.: while ( ( $MyData ) = $sth->fetchrow() ) Peter Darley wrote: > Folks, > I have yet another stupid question: > > I regularly get data out of a DBI statement handle by doing: > > while ($MyData = $sth->fetchrow()) > { > stuff > } > > This falls down when the data returned from the statement is '0', since > it's not true, and the while breaks. I've tried while (defined $MyData = > $sth->fetchrow()), but this is not syntacticly correct, and would break on a > database NULL (which is undef in perl) anway. I can do something like while > ($MyRef = $sth->fetchrow_hashref()) {$MyData = $$MyRef{datapoint}; stuff}, > but I'm not too fond of that. Does anyone have a suggestion on a better way > to construct this loop? > > Thanks, > Peter Darley _____________________________________________________________ Seattle Perl Users Group Mailing List POST TO: spug-list@mail.pm.org http://spugwiki.perlocity.org ACCOUNT CONFIG: http://mail.pm.org/mailman/listinfo/spug-list MEETINGS: 3rd Tuesdays, U-District, Seattle WA WEB PAGE: http://www.seattleperl.org From ced at carios2.ca.boeing.com Tue Sep 16 13:41:16 2003 From: ced at carios2.ca.boeing.com (ced@carios2.ca.boeing.com) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: while question Message-ID: <200309161841.LAA28343@carios2.ca.boeing.com> > while ($MyData = $sth->fetchrow()) > { > stuff > } > > This falls down when the data returned from the statement is '0', since > it's not true, and the while breaks. I've tried while (defined $MyData = > $sth->fetchrow()), but this is not syntacticly correct, and would break on a > database NULL (which is undef in perl) anway. I can do something like while > ($MyRef = $sth->fetchrow_hashref()) {$MyData = $$MyRef{datapoint}; stuff}, > but I'm not too fond of that. Does anyone have a suggestion on a better way > to construct this loop? I'm not sure why fetchrow_hashref doesn't make the cut but you could fetch the list rather than the scalar: while ( ($item) = fetchrow_array() ) { In general, though, this'll still be slower than just returning a ref. with fetchrow_hashref() or fetch(). -- Charles DeRykus From ben at reser.org Tue Sep 16 13:25:39 2003 From: ben at reser.org (Ben Reser) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: while question In-Reply-To: References: Message-ID: <20030916182539.GW30808@titanium.brain.org> On Tue, Sep 16, 2003 at 10:09:14AM -0700, Peter Darley wrote: > Folks, > I have yet another stupid question: > > I regularly get data out of a DBI statement handle by doing: > > while ($MyData = $sth->fetchrow()) > { > stuff > } > > This falls down when the data returned from the statement is '0', since > it's not true, and the while breaks. I've tried while (defined $MyData = > $sth->fetchrow()), but this is not syntacticly correct, and would break on a > database NULL (which is undef in perl) anway. I can do something like while > ($MyRef = $sth->fetchrow_hashref()) {$MyData = $$MyRef{datapoint}; stuff}, > but I'm not too fond of that. Does anyone have a suggestion on a better way > to construct this loop? Assuming you are only returning one column you could do this: $sth->bind_columns(\$MyData); while ($sth->fetch) { stuff } -- Ben Reser http://ben.reser.org "What upsets me is not that you lied to me, but that from now on I can no longer believe you." -- Nietzsche From sthoenna at efn.org Tue Sep 16 14:26:30 2003 From: sthoenna at efn.org (Yitzchak Scott-Thoennes) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: while question In-Reply-To: References: Message-ID: <20030916192630.GA1304@efn.org> The two forms: $foo = $obj->method() ($foo) = $obj->method() can have quite different results. Saying $foo = $obj->method() will call it in scalar context while ($foo) = $obj->method() will call it in list context and assign the first item returned to $foo. Some implications are: If method() is always returning an explicit list or slice, $foo = $obj->method() will give $foo the *last* item in the list, while ($foo) = $obj->method() will give $foo the *first* item. If method() is returning an array or hash, the assignment with parens will give $foo the first element or key. Without parens, it will give a count of elements for an array. For a non-tied hash, $foo will be false if the hash is empty and (true) bucket usage otherwise. For a tied hash, the returned value will be meaningless and probably false. Saying "defined $foo = $obj->method()" doesn't work because defined is a unary operator with higher precedence than =. You would say defined( $foo = $obj->method()) instead. On Tue, Sep 16, 2003 at 11:37:32AM -0700, Peter Darley wrote: > Adrian, > That is exactly what I was looking for! > Thanks, > Peter Darley > > -----Original Message----- > From: spug-list-bounces@mail.pm.org > [mailto:spug-list-bounces@mail.pm.org]On Behalf Of Adrian Hands > Sent: Tuesday, September 16, 2003 11:25 AM > To: spug-list@mail.pm.org > Subject: Re: SPUG: while question > > > The real problem here is fetchrow() returns a list and you're assigning it > to a scalar. > Simply add some parens and your while loop will no longer incorrectly break > on zero. > I.e.: > > while ( ( $MyData ) = $sth->fetchrow() ) From dvergin at igc.org Tue Sep 16 10:05:52 2003 From: dvergin at igc.org (David Vergin) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: while question In-Reply-To: <20030916192630.GA1304@efn.org> References: <20030916192630.GA1304@efn.org> Message-ID: <1063724751.1735.39.camel@localhost.localdomain> On Tue, 2003-09-16 at 19:26, Yitzchak Scott-Thoennes wrote: > If method() is always returning an explicit list... > ... > If method() is returning an array... I would be interested to see two simple, contrasting examples of the two behaviors you describe. dv From sthoenna at efn.org Tue Sep 16 17:33:02 2003 From: sthoenna at efn.org (Yitzchak Scott-Thoennes) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: while question In-Reply-To: <1063724751.1735.39.camel@localhost.localdomain> References: <20030916192630.GA1304@efn.org> <1063724751.1735.39.camel@localhost.localdomain> Message-ID: <20030916223302.GA2836@efn.org> On Tue, Sep 16, 2003 at 03:05:52PM +0000, David Vergin wrote: > On Tue, 2003-09-16 at 19:26, Yitzchak Scott-Thoennes wrote: > > If method() is always returning an explicit list... > > ... > > If method() is returning an array... > > I would be interested to see two simple, contrasting examples of the two > behaviors you describe. Does this help? $ perl -wlne'eval;print$@if$@' print " first: $INC[0]\n last: $INC[-1]" first: /usr/lib/perl5/5.8.0/cygwin-multi-64int last: . sub foo { @INC } $x = foo; print $x 6 ($x) = foo; print $x /usr/lib/perl5/5.8.0/cygwin-multi-64int # now try it with a slice (an array or hash or list converted to a list) sub bar { @INC[0..$#INC] } $x = bar; print $x . ($x) = bar; print $x /usr/lib/perl5/5.8.0/cygwin-multi-64int exit From dvergin at igc.org Tue Sep 16 16:52:24 2003 From: dvergin at igc.org (David Vergin) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: Returning array/list? (Was: "while question") In-Reply-To: <20030916223302.GA2836@efn.org> References: <20030916192630.GA1304@efn.org> <1063724751.1735.39.camel@localhost.localdomain> <20030916223302.GA2836@efn.org> Message-ID: <1063749143.1715.36.camel@localhost.localdomain> Hi Yitzchak (et omnes), First, let me to offer a more painstakingly transparent example that illustrates the behavior you are pointing to: ------------------------------------------------ #!/usr/bin/perl -w use strict; sub with_array { my @ary = qw/a b c d e/; @ary } sub with_list { qw/a b c d e/ } my $x; $x = with_array(); print $x, "\n"; # 5 ($x) = with_array(); print $x, "\n"; # a $x = with_list(); print $x, "\n"; # e ($x) = with_list(); print $x, "\n"; # a ------------------------------------------------- Then let us just note for the record that there is an alternate explanation of what is happening in these examples. There are Perl adepts that argue strongly that what is happening in all these cases is that the context of the subroutine call is propagating into the subroutine to the point where a value is returned. Consistent with that, they would argue that with_array() in a scalar context returns 5 rather than the @ary array, and that with_list() in a scalar context returns 'e' rather than the list ('a', 'b', 'c', 'd', 'e'). I'm not trying to advance the ultimate proof of this (I'm not qualified to do so) -- but just to note for the record that there are different interpretations by some pretty knowledgable people of the behavior you originally aluded to in writing of a sub returning an array vs. returning a list. Here are a couple of discussions that touch on this (lively-debated) question: http://www.perlmonks.org/index.pl?node_id=72247 http://www.perlmonks.org/index.pl?node_id=26319 http://www.perlmonks.org/index.pl?node_id=33670 Regards, David V. On Tue, 2003-09-16 at 22:33, Yitzchak Scott-Thoennes wrote: > On Tue, Sep 16, 2003 at 03:05:52PM +0000, David Vergin wrote: > > On Tue, 2003-09-16 at 19:26, Yitzchak Scott-Thoennes wrote: > > > If method() is always returning an explicit list... > > > ... > > > If method() is returning an array... > > > > I would be interested to see two simple, contrasting examples of the two > > behaviors you describe. > > Does this help? > > $ perl -wlne'eval;print$@if$@' > print " first: $INC[0]\n last: $INC[-1]" > first: /usr/lib/perl5/5.8.0/cygwin-multi-64int > last: . > sub foo { @INC } > $x = foo; print $x > 6 > ($x) = foo; print $x > /usr/lib/perl5/5.8.0/cygwin-multi-64int > # now try it with a slice (an array or hash or list converted to a list) > sub bar { @INC[0..$#INC] } > $x = bar; print $x > . > ($x) = bar; print $x > /usr/lib/perl5/5.8.0/cygwin-multi-64int > exit From ced at carios2.ca.boeing.com Wed Sep 17 00:15:58 2003 From: ced at carios2.ca.boeing.com (ced@carios2.ca.boeing.com) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: Returning array/list? (Was: "while question") Message-ID: <200309170515.WAA29981@carios2.ca.boeing.com> > First, let me to offer a more painstakingly transparent example that > illustrates the behavior you are pointing to: > > ------------------------------------------------ > #!/usr/bin/perl -w > use strict; > > sub with_array { my @ary = qw/a b c d e/; @ary } > sub with_list { qw/a b c d e/ } > > my $x; > > $x = with_array(); > print $x, "\n"; # 5 > ($x) = with_array(); > print $x, "\n"; # a > > $x = with_list(); > print $x, "\n"; # e > ($x) = with_list(); > print $x, "\n"; # a > ------------------------------------------------- > > Then let us just note for the record that there is an alternate > explanation of what is happening in these examples. > > There are Perl adepts that argue strongly that what is happening in all > these cases is that the context of the subroutine call is propagating > into the subroutine to the point where a value is returned. Consistent > with that, they would argue that with_array() in a scalar context > returns 5 rather than the @ary array, and that with_list() in a scalar > context returns 'e' rather than the list ('a', 'b', 'c', 'd', 'e'). > > I'm not trying to advance the ultimate proof of this (I'm not qualified > to do so) -- but just to note for the record that there are different > interpretations by some pretty knowledgable people of the behavior you > originally aluded to in writing of a sub returning an array vs. > returning a list. I recall similar threads. As I remember, the differing semantics are those of list vs.array. An array is an AV* structure which can have a scalar context. There's an actual length embedded in the structure. A list, however,is just values on a stack and there's no comparable context; its behaviour is more like that of the comma operator. -- Charles DeRykus From sthoenna at efn.org Wed Sep 17 03:12:41 2003 From: sthoenna at efn.org (Yitzchak Scott-Thoennes) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: Returning array/list? (Was: "while question") In-Reply-To: <1063749143.1715.36.camel@localhost.localdomain> References: <20030916192630.GA1304@efn.org> <1063724751.1735.39.camel@localhost.localdomain> <20030916223302.GA2836@efn.org> <1063749143.1715.36.camel@localhost.localdomain> Message-ID: <20030917081241.GA3588@efn.org> On Tue, Sep 16, 2003 at 09:52:24PM +0000, David Vergin wrote: > Hi Yitzchak (et omnes), > > First, let me to offer a more painstakingly transparent example that > illustrates the behavior you are pointing to: > > ------------------------------------------------ > #!/usr/bin/perl -w > use strict; > > sub with_array { my @ary = qw/a b c d e/; @ary } > sub with_list { qw/a b c d e/ } > > my $x; > > $x = with_array(); > print $x, "\n"; # 5 > ($x) = with_array(); > print $x, "\n"; # a > > $x = with_list(); > print $x, "\n"; # e > ($x) = with_list(); > print $x, "\n"; # a > ------------------------------------------------- Thanks, that's a lot clearer than my hastily typed example. > Then let us just note for the record that there is an alternate > explanation of what is happening in these examples. > > There are Perl adepts that argue strongly that what is happening in all > these cases is that the context of the subroutine call is propagating > into the subroutine to the point where a value is returned. I don't think that's an alternate explanation. That's reality. If I said anything that conflicts with that, it was an error. (Though you could describe it in reverse--when a piece of perl guts needs to know the context, it gets whatever was determined at compile time. If it wasn't determined at compile time (i.e. return value for a block or sub), it looks upward through the calling stack to find a level where it was determined.) My point was that changing a scalar assignment to a list assignment changes not only the boolean value of the assignment (from testing the scalar that was assigned to testing the count of elements on the right of the assignment) [which is the part that seemed to be intended by the poster to whom I responded] but can also have repercussions on the value assigned because the right side is now in list context instead of scalar. [As an implementation detail, perl does sometimes build lists in scalar context and then throws all but the last element away, but that doesn't contradict the purist view that on a language-syntactic level, there is no such thing as a list in scalar context.] From cwilkes-spug at ladro.com Wed Sep 17 11:54:01 2003 From: cwilkes-spug at ladro.com (Chris Wilkes) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: Installing CPAN from CPAN on RH9 -- issus Message-ID: <20030917165401.GB42082@www.ladro.com> I created a Wiki Page for the installation of CPAN from within CPAN on RH9 that I mentioned at Ingy's Kwiki talk last night: http://spugwiki.perlocity.org/index.cgi?PerlOnRH9 Okay so the formatting isn't the greatest, but I think a wiki's a great way to keep information around and alive (as opposed to mailing lists which never seen to get a definitive "this is how you do it" post). Installing Bundle::CPAN from within the CPAN shell gets me this error: Bundle::libnet and the following items had problems during recursive bundle calls: Data::Dumper That also occurs when I try and install Bundle::libnet. Installing Data::Dumper works fine. However I can install CPAN and libnet if I go into the ./.cpan/build/ directories. My LANG is set to en_US: # cat /etc/sysconfig/i18n LANG="en_US" SUPPORTED="en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16" Which I had to do to get perldocs to show up without some wacky capital A's with accents. I tried setting LANG=C per a Usenet post but that didn't help. Its not that big of an issue as I can always install by having CPAN get the modules and then installing by hand. I looked into the __DATA__ issue I brought up about Kwiki and found out that I was thinking about Apache::Registry which forbids you from having __END__ or __DATA__ in your scripts. I would still like to see the wiki files move into their own seperate files. I smell a plugin! Chris From jmates at sial.org Wed Sep 17 12:27:13 2003 From: jmates at sial.org (Jeremy Mates) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: Re: Installing CPAN from CPAN on RH9 -- issus In-Reply-To: <20030917165401.GB42082@www.ladro.com> References: <20030917165401.GB42082@www.ladro.com> Message-ID: <20030917172713.GB61999@darkness.sial.org> * Chris Wilkes > Installing Bundle::CPAN from within the CPAN shell gets me this error: > Bundle::libnet and the following items had problems during recursive > bundle calls: Data::Dumper I would avoid Bundle::libnet and Bundle::CPAN. Instead: install CPAN To get the most up-to-date version of CPAN, e.g. a version that does not attempt to upgrade perl itself or other annoyances. The new version of CPAN might then allow you to upgrade modules. However, RedHat Linux probably has broken other things about perl... From m3047 at inwa.net Wed Sep 17 14:27:27 2003 From: m3047 at inwa.net (Fred Morris) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: a technique for avoiding circularity Message-ID: The issue came up at last evening's meeting of avoiding circularity. In addition to circular lists, this can come up in object-oriented collections where all members of the collection need to be "aware" of other members of the collection: typically this is done by their being aware of some sort of "connector". I hearken back to the patent on canonical storage of numbers on network-accessible storage, which claimed that K&R said that this was a "problem".. in spite of the fact that K&R carefully elucidated the canonicalization which the compiler itself used to manipulate numbers of dissimilar machine types... I actually wrote to somebody about it, and as I recall they wrote back and said would I please not tell anybody... oh well. So I want to be careful saying circularity is a problem in need of a solution, because it's not; nonetheless in these days of diminishing herds, people are keen to put a brand on anything that moves. With that apologaeia here is an old, tried and true technique which is particularly convenient given Perl's free and easy attitude towards name spaces (although it can be accomplished in almost any language with a little bit of craft). With a nod to Asa Mercer, I hope you enjoy it. -- Fred Morris m3047@inwa.net -- #!/usr/bin/perl -w use strict; # -=-=- MARKET, connecting scoundrels everywhere -=-=- package Market; my %Markets; sub new { my $class = shift; my $name = shift; my $self = { name_ => $name }; bless $self, $class; $Markets{ $name } = $self; return $self; } # &new sub add { my $self = shift; foreach my $item (@_) { $self->{$item->{name_}} = $item; $item->{market} = $self->{name_} } return $self; } # &add sub locate { my $market_name = shift; my $actor_name = shift; return $Markets{$market_name}{$actor_name}; } # &locate sub crash { my $self = shift; return delete $Markets{$self->{name_}}; } # &crash sub markets() { return join ' ', keys %Markets; } # &markets # -=-=- COWBOY, base class for scoundrels -=-=- package Cowboy; sub ilk { my $self = shift; my $name = shift; return Market::locate( $self->{market}, $name ); } # &ilk # -=-=- OLDSCHOOL, ah the wild west... -=-=- package OldSchool; use vars qw/ @ISA /; @ISA = qw( Cowboy ); sub new { my $class = shift; my $name = shift; my $self = { name_ => $name }; bless $self, $class; return $self; } # &new sub excuse { my $self = shift; return "$self->{name_} says: they stole my cows\n"; } # &excuse # -=-=- KINDERRICHER, of course things are different now. -=-=- package KinderRicher; use vars qw/ @ISA /; @ISA = qw( Cowboy ); sub new { my $class = shift; my $name = shift; my $self = { name_ => $name }; bless $self, $class; return $self; } # &new sub excuse { my $self = shift; return "$self->{name_} says: they stole my intellectual property\n"; } # &excuse # -=-=- MAIN, the actors on the stage -=-=- package main; my $market = Market->new( 'Financial' ); my @banditti; push @banditti, OldSchool->new('Greely'); push @banditti, KinderRicher->new('Billy'); $market->add( @banditti ); print $banditti[0]->excuse(); print $banditti[0]->ilk($banditti[1]{name_})->excuse(); print "before: ", Market::markets(), "\n"; $market->crash(); print "after: ", Market::markets(), "\n"; From sthoenna at efn.org Wed Sep 17 15:13:39 2003 From: sthoenna at efn.org (Yitzchak Scott-Thoennes) Date: Mon Aug 2 21:37:08 2004 Subject: SPUG: a technique for avoiding circularity In-Reply-To: References: Message-ID: <20030917201338.GA2732@efn.org> On Wed, Sep 17, 2003 at 12:27:27PM -0700, Fred Morris wrote: > With that apologaeia here is an old, tried and true technique which is > particularly convenient given Perl's free and easy attitude towards name > spaces (although it can be accomplished in almost any language with a > little bit of craft). With a nod to Asa Mercer, I hope you enjoy it. > > #!/usr/bin/perl -w .. > print "after: ", Market::markets(), "\n"; > > > _____________________________________________________________ > Seattle Perl Users Group Mailing List > POST TO: spug-list@mail.pm.org http://spugwiki.perlocity.org > ACCOUNT CONFIG: http://mail.pm.org/mailman/listinfo/spug-list > MEETINGS: 3rd Tuesdays, U-District, Seattle WA > WEB PAGE: http://www.seattleperl.org Just a formatting comment: if you put an __END__ at the end of your code, those with a decent mail reader can just pipe your message to "perl -x" to run it (only needed because the list appends stuff to your message). -- seattle culture junkies: my wife highly recommends Seattle Shakespeare Company's Measure for Measure production, opening tomorrow ("Pay What You Will" preview 7:30 tonight at Seattle Center's Center House) From m3047 at inwa.net Wed Sep 17 20:48:10 2003 From: m3047 at inwa.net (Fred Morris) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Is there some other recommended replacement for CGI.pm with Apache2? Message-ID: I think the subject line says it all: Just wondering if maybe I should be moving to something else.. if there is anything else. Basically I use CGI.pm to get parameters and to emit response headers, and that's about it. -- Fred Morris m3047@inwa.net From douglas at slugstone.net Wed Sep 17 22:24:50 2003 From: douglas at slugstone.net (Douglas Kirkland) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Is there some other recommended replacement for CGI.pm with Apache2? In-Reply-To: References: Message-ID: <200309172024.51136.douglas@slugstone.net> Take a look at CGI::Simple. I have not tried it but hear some good things with mod_perl. Douglas On Wednesday 17 September 2003 18:48, Fred Morris wrote: > I think the subject line says it all: > > > Just wondering if maybe I should be moving to something else.. if there is > anything else. Basically I use CGI.pm to get parameters and to emit > response headers, and that's about it. > > -- > > Fred Morris > m3047@inwa.net > > > _____________________________________________________________ > Seattle Perl Users Group Mailing List > POST TO: spug-list@mail.pm.org http://spugwiki.perlocity.org > ACCOUNT CONFIG: http://mail.pm.org/mailman/listinfo/spug-list > MEETINGS: 3rd Tuesdays, U-District, Seattle WA > WEB PAGE: http://www.seattleperl.org > > From m3047 at inwa.net Wed Sep 17 22:46:29 2003 From: m3047 at inwa.net (Fred Morris) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: proper checking of file status after read? (mod_perl Apache2) Message-ID: Well, I got my calendar thingie working with Apache 2 (prefork model) and mod_perl... more or less. This would be the Apache 2, Perl 5.8 and mod_perl which ship with SuSE 8.2 for x86, plus their patches for them. (Apache ids as 2.0.46, but since SuSE tends to retrofit patches and not change the version number, who can be sure?). I also had to download the latest version of CGI.pm from Lincoln Stein's website. I suppose I might as well describe what it took: CHANGES TO DIRECTIVES: PerlHandler Apache::Registry becomes PerlResponseHandler ModPerl::Registry PerlSendHeader On becomes PerlOptions +ParseHeaders Note that the latter is probably unnecessary when using CGI.pm. CHANGES TO @INC: The most irritating thing is that it doesn't chdir to where the script is executing! That may change in the future according to some doc I read somewhere, but that's the way it is for now. This means that if you have modules and you don't want to install them in your perl5 tree, you need to find PerlRequire (or create one if need be) and add a use lib for the path. SuSE 8.2 provides it as /etc/apache2/mod_perl-startup.pl. That was really all it took. However, it doesn't seem completely stable. I get sporadic failures where it seems like the CGI parameters didn't make it to the script, or files don't read. The only one which actually gets logged is Inappropriate ioctl for device. At first I thought it was always occurring at the same place in the file (the end, maybe?) but now I see that's not the case. Most of the time when it occurs it reports line 4 (and there are 4 lines in the file), but one time it reported line 12! And of course, sometimes it works. This brings up a question about the code which is being executed, and if it is correct. open( INFILE, '/path/spec') ... no errors, notice no mode == read while ($line = ) { all ok... } if ($!) ... <--- this is what sporadically fails! The point is to determine that the file was read ok. If not like this, then how? Is $! unsafe/indeterminate when a file has been successfully read? I don't see this behavior on my stable server, which is running older stuff. If anybody's got any insights to share.... -- Fred Morris m3047@inwa.net From adamm at wazamatta.com Thu Sep 18 11:41:13 2003 From: adamm at wazamatta.com (Adam Monsen) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Is there some other recommended replacement for CGI.pm with Apache2? In-Reply-To: References: Message-ID: <3F69E029.9020803@wazamatta.com> Fred Morris wrote: > Just wondering if maybe I should be moving to something else.. if there is > anything else. Basically I use CGI.pm to get parameters and to emit > response headers, and that's about it. CGI.pm is a resource waster and the code looks a bit scary, but it seems to be quite an axiom, probably because it has the most desirable namespace. :) CGI::Minimal is a nice drop-in replacement for CGI.pm param extraction (similar syntax), and HTTP::Headers could be used for, uh, HTTP headers. Both are relatively fast and lightweight. Arguably, headers aren't that hard to conjure by hand. -- Adam Monsen From joneil at cobaltgroup.com Thu Sep 18 12:26:07 2003 From: joneil at cobaltgroup.com (O'neil, Jerome) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Is there some other recommended replacement for CGI.pm with Apache2? Message-ID: <25160AB2660F8B449892B0EB9C29C1650C4014@ex-sea-is2.cobaltgroup.com> CGI.pm isn't nearly the monster that it's reputed to be. It might be a bit heavyweight for simple query term extraction, but for general purpose use, its the best thing going. -J -----Original Message----- From: Adam Monsen [mailto:adamm@wazamatta.com] Sent: Thursday, September 18, 2003 9:41 AM To: spug-list@mail.pm.org Subject: Re: SPUG: Is there some other recommended replacement for CGI.pm with Apache2? Fred Morris wrote: > Just wondering if maybe I should be moving to something else.. if there is > anything else. Basically I use CGI.pm to get parameters and to emit > response headers, and that's about it. CGI.pm is a resource waster and the code looks a bit scary, but it seems to be quite an axiom, probably because it has the most desirable namespace. :) CGI::Minimal is a nice drop-in replacement for CGI.pm param extraction (similar syntax), and HTTP::Headers could be used for, uh, HTTP headers. Both are relatively fast and lightweight. Arguably, headers aren't that hard to conjure by hand. -- Adam Monsen _____________________________________________________________ Seattle Perl Users Group Mailing List POST TO: spug-list@mail.pm.org http://spugwiki.perlocity.org ACCOUNT CONFIG: http://mail.pm.org/mailman/listinfo/spug-list MEETINGS: 3rd Tuesdays, U-District, Seattle WA WEB PAGE: http://www.seattleperl.org This e-mail transmission contains information intended only for the use of the recipient(s) named above. Further, it contains information that may be privileged and confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message (including any attachments) is strictly prohibited. If you have received this e-mail in error, please notify the sender by reply e-mail and then delete this message from your mail system. Thank you for your compliance. From christopher.w.cantrall at boeing.com Thu Sep 18 13:00:57 2003 From: christopher.w.cantrall at boeing.com (Cantrall, Christopher W) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Is there some other recommended replacement for CGI.pm with Apache2? Message-ID: I have repeatedely heard that CGI.pm only compiles what is needed, leaving the rest of the monster outside the castle gates, unable to slow down the festivities inside the Castle Script. See the linked docs and discussions for more info, but suffice it to say that all of CGI.pm is not loaded every time your script starts. I don't know if this is what Adam meant by "resource waster", or what Jerome meant by "isn't nearly the monster that it's reputed to be", but it's a complaint that I've heard many times, namely, loading 'that huge beast into my simple form script will slow the whole server'. Adam, if I've missed your point, I'm sorry and could you clarify. :) http://search.cpan.org/author/LDS/CGI.pm-3.00/CGI.pm#PRAGMAS See the -compile section for this sentence: "This causes the indicated autoloaded methods to be compiled up front, rather than deferred to later." http://perlmonks.org/index.pl?node_id=267364 "That's because, by default, CGI only compiles a function when it's requested." Cheers. ____________________________________________ Chris Cantrall Structural Engineer, 767 Fuselage, Boeing Christopher.W.Cantrall@Boeing.com chris@cantrall.org http://perlmonks.org/index.pl?node=Louis_Wu -----Original Message----- Fred Morris wrote: > Just wondering if maybe I should be moving to something else.. if there is > anything else. Basically I use CGI.pm to get parameters and to emit > response headers, and that's about it. Adam Monsen wrote: CGI.pm is a resource waster and the code looks a bit scary, but it seems to be quite an axiom, probably because it has the most desirable namespace. :) Jerome O'neil wrote: CGI.pm isn't nearly the monster that it's reputed to be. It might be a bit heavyweight for simple query term extraction, but for general purpose use, its the best thing going. From joneil at cobaltgroup.com Thu Sep 18 13:14:55 2003 From: joneil at cobaltgroup.com (O'neil, Jerome) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Is there some other recommended replacement for CGI.pm with Apache2? Message-ID: <25160AB2660F8B449892B0EB9C29C1650C4016@ex-sea-is2.cobaltgroup.com> > I don't know if this is what Adam meant by "resource waster", or what Jerome meant by > "isn't nearly the monster that it's reputed to be", but it's a complaint that I've heard > many times, namely, loading 'that huge beast into my simple form script will slow the > whole server'. That sums it up quite nicely. CGI.pm is a large module, to be sure, but most of that is pod, and the remainder of the compilation is deferred until the methods are called. Here is a simple test. %time perl -M"CGI qw(-no_debug)" -e 'my $c = new CGI' 0.08 user 0.07 system 0:00.16 elapsed. If you use the function oriented interface, i.e. use CGI qw(:all), it can be a bit slower, but still, not nearly the beast it's reputed to be. HTH! -J This e-mail transmission contains information intended only for the use of the recipient(s) named above. Further, it contains information that may be privileged and confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message (including any attachments) is strictly prohibited. If you have received this e-mail in error, please notify the sender by reply e-mail and then delete this message from your mail system. Thank you for your compliance. From ben at reser.org Thu Sep 18 11:08:56 2003 From: ben at reser.org (Ben Reser) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: proper checking of file status after read? (mod_perl Apache2) In-Reply-To: References: Message-ID: <20030918160856.GA9055@titanium.brain.org> On Wed, Sep 17, 2003 at 08:46:29PM -0700, Fred Morris wrote: > This brings up a question about the code which is being executed, and if it > is correct. > > > open( INFILE, '/path/spec') ... no errors, notice no mode == read > > while ($line = ) { > > all ok... > } > > if ($!) ... <--- this is what sporadically fails! > > > The point is to determine that the file was read ok. If not like this, then > how? Is $! unsafe/indeterminate when a file has been successfully read? > > I don't see this behavior on my stable server, which is running older stuff. > > If anybody's got any insights to share.... Per perlvar: If used numerically, yields the current value of the C "errno" variable, or in other words, if a system or library call fails, it sets this variable. This means that the value of $! is meaningful only immediately after a failure: if (open(FH, $filename)) { # Here $! is meaningless. ... } else { # ONLY here is $! meaningful. ... # Already here $! might be meaningless. } # Since here we might have either success or failure, # here $! is meaningless. In the above meaningless stands for anything: zero, non-zero, "undef". A successful system or library call does not set the variable to zero. So yes, your code is wrong. The better way to write this is: open (INFILE, '/path/spec') or die "Couldn't open /path/spec: $!"; @lines = or die "Error reading /path/spec: $!"; ... -- Ben Reser http://ben.reser.org "Conscience is the inner voice which warns us somebody may be looking." - H.L. Mencken From adamm at wazamatta.com Thu Sep 18 18:26:56 2003 From: adamm at wazamatta.com (Adam Monsen) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Is there some other recommended replacement for CGI.pm with Apache2? In-Reply-To: References: Message-ID: <3F6A3F40.1090606@wazamatta.com> Cantrall, Christopher W wrote: > I have repeatedely heard that CGI.pm only compiles what is needed, > leaving the rest of the monster outside the castle gates, unable to > slow down the festivities inside the Castle Script. See the linked > docs and discussions for more info, but suffice it to say that all of > CGI.pm is not loaded every time your script starts. > > I don't know if this is what Adam meant by "resource waster", or what > Jerome meant by "isn't nearly the monster that it's reputed to be", > but it's a complaint that I've heard many times, namely, loading > 'that huge beast into my simple form script will slow the whole > server'. Adam, if I've missed your point, I'm sorry and could you > clarify. :) I basically said that CGI.pm is overkill for param extraction, and headers could be printed out by hand or with help from HTTP::Headers. Here's a benchmark comparing param setting and extraction with both CGI.pm and CGI::Minimal, showing CGI::Minimal to be approximately 3x faster. I'd definitely like to see other more complete and conclusive benchmarks. #!/usr/bin/perl -w use strict; use Benchmark (); use CGI (); use CGI::Minimal (); $ENV{REQUEST_METHOD} = 'GET'; # turn off STDIN processing sub cgi_pm_test () { my $cgi = CGI->new; $cgi->param('name' => 'Joe Shmoe'); my (@fake_input) = $cgi->param; } sub cgi_minimal_test () { my $cgi = CGI::Minimal->new; $cgi->param('name' => 'Joe Shmoe'); my (@fake_input) = $cgi->param; } Benchmark::cmpthese 10_000, { 'CGI.pm' => \&cgi_pm_test, 'CGI::Minimal' => \&cgi_minimal_test, } # Typical result: # # $ perl -w cgitest.pl # Rate CGI.pm CGI::Minimal # CGI.pm 1089/s -- -76% # CGI::Minimal 4630/s 325% -- # __END__ -- Adam Monsen From smorton at pobox.com Thu Sep 18 18:49:39 2003 From: smorton at pobox.com (Sanford Morton) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Is there some other recommended replacement for wiApache2? In-Reply-To: <3F6A3F40.1090606@wazamatta.com> Message-ID: If all you want to do is read the form data, this old, old, old function is all that's needed: # Adapted from cgi-lib.pl by S.E.Brenner@bioc.cam.ac.uk # Copyright 1994 Steven E. Brenner sub ReadParse { local (*in) = @_ if @_; local ($i, $key, $val); if ( $ENV{'REQUEST_METHOD'} eq "GET" ) { $in = $ENV{'QUERY_STRING'}; } elsif ($ENV{'REQUEST_METHOD'} eq "POST") { read(STDIN,$in,$ENV{'CONTENT_LENGTH'}); } else { # Added for command line debugging # Supply name/value form data as a command line argument # Format: name1=value1\&name2=value2\&... # (need to escape & for shell) # Find the first argument that's not a switch (-) $in = ( grep( !/^-/, @ARGV )) [0]; $in =~ s/\\&/&/g; } @in = split(/&/,$in); foreach $i (0 .. $#in) { # Convert plus's to spaces $in[$i] =~ s/\+/ /g; # Split into key and value. ($key, $val) = split(/=/,$in[$i],2); # splits on the first =. # Convert %XX from hex numbers to alphanumeric $key =~ s/%(..)/pack("c",hex($1))/ge; $val =~ s/%(..)/pack("c",hex($1))/ge; # Associate key and value. \0 is the multiple separator $in{$key} .= "\0" if (defined($in{$key})); $in{$key} .= $val; } return length($in); } From m3047 at inwa.net Thu Sep 18 22:12:48 2003 From: m3047 at inwa.net (Fred Morris) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Is there some other recommended replacement for CGI.pm with Apache2? Message-ID: At 11:14 AM 9/18/03, O'neil, Jerome wrote: >> I don't know if this is what Adam meant by "resource waster", or what >Jerome meant by >> "isn't nearly the monster that it's reputed to be", but it's a complaint >that I've heard >> many times, namely, loading 'that huge beast into my simple form script >will slow the >> whole server'. Actually, it hasn't been a practical issue with mod_perl, and the rest of the app is comparatively many times larger. Hey, memory is cheap, the total package is (still) wicked fast. No, I was more concerned because in order to get a CGI.pm which worked with A2, the latest mod_perl and a reasonably current Linux kernel I had to go to Stein's site and get the latest. If I had to think anything, I would think the large amount of code (and it is fairly large) was more of an issue for maintenance than performance. I wasn't thinking, I was askin'! I'll take at least a cursory look at CGI::Simple, and yeah rolling your own headers ain't that bad (do it for the 'bot motel). The issue is peeps having to download stuff from various and sundry places to get something to work... especially when that stuff is a moving target. -- Fred Morris m3047@inwa.net From m3047 at inwa.net Thu Sep 18 22:12:48 2003 From: m3047 at inwa.net (Fred Morris) Date: Mon Aug 2 21:37:09 2004 Subject: I/O status Re: SPUG: proper checking of file status after read? Message-ID: This wouldn't be something beyond theoretical concern, except on continued analysis the SPOF leads back to I/O error: in other words since everything is templated, errors reading templates would result in downline errors with parameters on subsequent GETs/POSTs. Not saying that the theoretical issue wouldn't personally irritate me.. because it would.. but I would figure some grandiose inefficiency covered for it, such as reading in the entire file on open, such that any I/O error would be reflected there, or something like that. Did I mention that some warns don't seem to show? No, I didn't. For the most part then, Ben's reportage is without blame, although its applicability to the real world can be questioned. At 9:08 AM 9/18/03, Ben Reser wrote: >On Wed, Sep 17, 2003 at 08:46:29PM -0700, Fred Morris wrote: >> This brings up a question about the code which is being executed, and if it >> is correct. >> >> >> open( INFILE, '/path/spec') ... no errors, notice no mode == read >> >> while ($line = ) { >> >> all ok... >> } >> >> if ($!) ... <--- this is what sporadically fails! >> >> >> The point is to determine that the file was read ok. If not like this, then >> how? Is $! unsafe/indeterminate when a file has been successfully read? >> >> I don't see this behavior on my stable server, which is running older stuff. >> >> If anybody's got any insights to share.... > >Per perlvar: >If used numerically, yields the current value of the C "errno" >variable, or in other words, if a system or library call fails, >it sets this variable. This means that the value of $! is >meaningful only immediately after a failure: >if (open(FH, $filename)) { > # Here $! is meaningless. > ... >} else { > # ONLY here is $! meaningful. > ... > # Already here $! might be meaningless. >} ># Since here we might have either success or failure, ># here $! is meaningless. In the real world, this has never been the case, but thanks for pointing it out. This sounds like bad documentation more than anything else: there are side effects which call system libraries which mere mortals are unaware or uninformed of. (Nobody's encountered crufty and perhaps slightly arrogant documentation before?) Or are we to believe that $! is used merely for scratch when the whim strikes? >In the above meaningless stands for anything: zero, non-zero, >"undef". A successful system or library call does not >set the variable to zero. > >So yes, your code is wrong. The better way to write this is: >open (INFILE, '/path/spec') or die "Couldn't open /path/spec: $!"; Herein is the allusion to buffering gone bad... (do that, doesn't fail) >@lines = or die "Error reading /path/spec: $!"; How is this different from a while loop on individual lines until (presumably) an undef occurs? In the newer versions of Perl, (no I stand corrected, any version of Perl 5) this would fail if the file was empty. However, if there was no error, are you saying that $! is "meaningless"? This is the snag, you see. And it's not just "any value", it's an ioctl.. every time. As a matter of fact, I just tried your suggestion on an empty file with perl v5.8.0 i586-linux-thread-multi (plus SuSE patches) and by golly I got Inappropriate ioctl for device. On 5.005_03 $! is .. well... false. Anything else I missed here? Yes. The system with 5.5.3 is on an ext2 fs, and the system with 5.8.0 is reiserfs. FWIW. But again: I am sure that the file(s) in question in the real app are *not* empty. How does one check for a "no problem" condition when at end of file.. because we can ascertain, by both documentation and practice, that "end of file" is reached when the end of file is reached as well as when there is an I/O error. Am I a flipper baby for wanting to be able to check for I/O read status? Does nobody do this? Wow. -- Fred Morris m3047@inwa.net From ben at reser.org Thu Sep 18 23:47:11 2003 From: ben at reser.org (Ben Reser) Date: Mon Aug 2 21:37:09 2004 Subject: I/O status Re: SPUG: proper checking of file status after read? In-Reply-To: References: Message-ID: <20030919044710.GD9055@titanium.brain.org> On Thu, Sep 18, 2003 at 08:12:48PM -0700, Fred Morris wrote: > At 9:08 AM 9/18/03, Ben Reser wrote: > >if (open(FH, $filename)) { > > # Here $! is meaningless. > > ... > >} else { > > # ONLY here is $! meaningful. > > ... > > # Already here $! might be meaningless. > >} > ># Since here we might have either success or failure, > ># here $! is meaningless. > > In the real world, this has never been the case, but thanks for pointing it > out. This sounds like bad documentation more than anything else: there are > side effects which call system libraries which mere mortals are unaware or > uninformed of. (Nobody's encountered crufty and perhaps slightly arrogant > documentation before?) Or are we to believe that $! is used merely for > scratch when the whim strikes? What you seem to be missing is the key sentence in the following paragraph: > >A successful system or library call does not > >set the variable to zero. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Which means, if errno got set for whatever reason previously it will still be set even after a successful library call. This is by *DESIGN*. $! is not used to tell you that an error occured, the return value of the operation tells you if it was successful or not. It simply provides you the error number of the *LAST* error. Theoretically you could work around this by setting $! to 0 prior to starting your while loop. But this is also possible to break. Say perl ends up calling some function to request some information be put in a buffer and the buffer was too small so the call sets the errno. Even if perl handles this buffer issue for you, then the errno will be set. At any rate I wouldn't consider the documentation wrong, crufty or arrogant. > Herein is the allusion to buffering gone bad... (do that, doesn't fail) > > >@lines = or die "Error reading /path/spec: $!"; > > How is this different from a while loop on individual lines until > (presumably) an undef occurs? It's not different, except that it has error handling in a much simpler way. To try and detect and error while reading with while () {...} would be difficult. > In the newer versions of Perl, (no I stand > corrected, any version of Perl 5) this would fail if the file was empty. I can't imagine why you wouldn't consider reading an empty file an error condition... If there's nothing to read it's not a successful read. > However, if there was no error, are you saying that $! is "meaningless"? > This is the snag, you see. If there is no error the die call never happens so $! is never used. > And it's not just "any value", it's an ioctl.. every time. > > As a matter of fact, I just tried your suggestion on an empty file with > perl v5.8.0 i586-linux-thread-multi (plus SuSE patches) and by golly I got > Inappropriate ioctl for device. > > On 5.005_03 $! is .. well... false. > > Anything else I missed here? Yes. The system with 5.5.3 is on an ext2 fs, > and the system with 5.8.0 is reiserfs. FWIW. reiserfs is considering the attempt to read an empty file an error and setting errno. ext2 apparently doesn't consider it as such. Not all filesystems are created equally. However, perl does consider it an error because there is nothing to put in the array i.e. the assignment failed. > But again: I am sure that the file(s) in question in the real app are *not* > empty. How does one check for a "no problem" condition when at end of > file.. because we can ascertain, by both documentation and practice, that > "end of file" is reached when the end of file is reached as well as when > there is an I/O error. > > Am I a flipper baby for wanting to be able to check for I/O read status? > Does nobody do this? Wow. This is generally not a concern when reading files in perl because perl handles the I/O issues for you. Sounds to me like you're trying to do work that's already handled for you... -- Ben Reser http://ben.reser.org "Conscience is the inner voice which warns us somebody may be looking." - H.L. Mencken From m3047 at inwa.net Fri Sep 19 03:52:20 2003 From: m3047 at inwa.net (Fred Morris) Date: Mon Aug 2 21:37:09 2004 Subject: I/O status Re: SPUG: proper checking of file status after read? Message-ID: I wrote: >As a matter of fact, I just tried your suggestion on an empty file with >perl v5.8.0 i586-linux-thread-multi (plus SuSE patches) and by golly I got >Inappropriate ioctl for device. > >On 5.005_03 $! is .. well... false. > >Anything else I missed here? Yes. The system with 5.5.3 is on an ext2 fs, >and the system with 5.8.0 is reiserfs. FWIW. Just made an ext2 partition on the very same box which has reiserfs (SuSE 8.2, Perl 5.8.0, patches) and tried the empty file test. Same error, Inappropriate ioctl for device. In an attempt at falsifiability, deleted the file and the error is No such file or directory on open (not read). I think that rules out reiserfs. The entirety of the program: #!/usr/bin/perl -w use strict; open (FOO, 'foo') or die "open: $!"; my @lines = or die "reading: $!"; close FOO or die "close: $!"; __END__ (for YS-T) -- Fred Morris m3047@inwa.net From spug-list at l.ifokr.org Fri Sep 19 03:59:04 2003 From: spug-list at l.ifokr.org (Brian Hatch) Date: Mon Aug 2 21:37:09 2004 Subject: I/O status Re: SPUG: proper checking of file status after read? In-Reply-To: References: Message-ID: <20030919085904.GZ28270@ifokr.org> > Just made an ext2 partition on the very same box which has reiserfs (SuSE > 8.2, Perl 5.8.0, patches) and tried the empty file test. Same error, > Inappropriate ioctl for device. In an attempt at falsifiability, deleted > the file and the error is No such file or directory on open (not read). I > think that rules out reiserfs. > > The entirety of the program: > > #!/usr/bin/perl -w > use strict; > > open (FOO, 'foo') or die "open: $!"; > > my @lines = or die "reading: $!"; > > close FOO or die "close: $!"; > > __END__ I can't see why this wouldn't work. I even ran it - works fine. Can't imagine why it'd be giving you an ioctl error. Try 'strace perl /path/to/script' and let's see exactly what it's trying to do. -- Brian Hatch We had the 80's Systems and Then the 90's Security Engineer And then what? http://www.ifokr.org/bri/ The Naughties? Every message PGP signed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/spug-list/attachments/20030919/a961bcdf/attachment.bin From sthoenna at efn.org Fri Sep 19 04:32:10 2003 From: sthoenna at efn.org (Yitzchak Scott-Thoennes) Date: Mon Aug 2 21:37:09 2004 Subject: I/O status Re: SPUG: proper checking of file status after read? In-Reply-To: References: Message-ID: <20030919093210.GA3988@efn.org> On Thu, Sep 18, 2003 at 08:12:48PM -0700, Fred Morris wrote: > > And it's not just "any value", it's an ioctl.. every time. I've seen an explanation of this, somewhere...it might depend on whether you give perl the script name as a relative or absolute path. But this just demonstrates that you can't check $! without knowing that there was an error. > Am I a flipper baby for wanting to be able to check for I/O read status? > Does nobody do this? Wow. I've seen the question come up half a dozen times or so on various lists, so you're not the only one. You can check !eof(FILE) and then check $!, but that doesn't work very well for terminal input. From m3047 at inwa.net Fri Sep 19 05:49:21 2003 From: m3047 at inwa.net (Fred Morris) Date: Mon Aug 2 21:37:09 2004 Subject: I/O status Re: SPUG: proper checking of file status after read? Message-ID: At 9:47 PM 9/18/03, Ben Reser wrote: >On Thu, Sep 18, 2003 at 08:12:48PM -0700, Fred Morris wrote: >> At 9:08 AM 9/18/03, Ben Reser wrote: >> >if (open(FH, $filename)) { >> > # Here $! is meaningless. >> > ... >> >} else { >> > # ONLY here is $! meaningful. >> > ... >> > # Already here $! might be meaningless. >> >} >> ># Since here we might have either success or failure, >> ># here $! is meaningless. >> >> In the real world, this has never been the case, but thanks for pointing it >> out. This sounds like bad documentation more than anything else: there are >> side effects which call system libraries which mere mortals are unaware or >> uninformed of. (Nobody's encountered crufty and perhaps slightly arrogant >> documentation before?) Or are we to believe that $! is used merely for >> scratch when the whim strikes? > >What you seem to be missing is the key sentence in the following >paragraph: > >> >A successful system or library call does not >> >set the variable to zero. >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >Which means, if errno got set for whatever reason previously it will >still be set even after a successful library call. This is by *DESIGN*. >$! is not used to tell you that an error occured, the return value of >the operation tells you if it was successful or not. It simply provides >you the error number of the *LAST* error. There are times I consider documentation to be the final arbiter, and times I consider behavior paramount. I observe that perlvar seems to ignore status checking on read in its examples. >Theoretically you could work around this by setting $! to 0 prior to >starting your while loop. But this is also possible to break. Say perl >ends up calling some function to request some information be put in a >buffer and the buffer was too small so the call sets the errno. Even if >perl handles this buffer issue for you, then the errno will be set. > >At any rate I wouldn't consider the documentation wrong, crufty or >arrogant. > >> Herein is the allusion to buffering gone bad... (do that, doesn't fail) >> >> >@lines = or die "Error reading /path/spec: $!"; >> >> How is this different from a while loop on individual lines until >> (presumably) an undef occurs? > >It's not different, except that it has error handling in a much simpler >way. To try and detect and error while reading with while () {...} >would be difficult. I'm sorry. Hold that thought.... >> In the newer versions of Perl, (no I stand >> corrected, any version of Perl 5) this would fail if the file was empty. > >I can't imagine why you wouldn't consider reading an empty >file an error condition... If there's nothing to read it's not a >successful read. I consider it a success because the failure to read data was not due to a failure of the storage management layer. Is there another language which considers end-of-file on initial read to be a storage layer failure? (Incidentally, I would say that Perl does not consider it an error condition either.) Attempting to read beyond EOF is considered an error in many languages; languages which do so on initial read typically provide an EOF test, used as until EOF() read(). Try for mainstream here; provide an example or be discarded. Even with SQL, reading 0 records returns an empty set.. not an error. man errno(3) lists ENOTTY as Inappropriate I/O control operation, but there is no error for end of file or empty file. BTW, attempting to read beyond EOF in Perl 5.8 reads 0 lines and does not set $!. That's really a side issue, I'm not going to go back and test in other versions. I can tell this might be the start of a religious difference of opinion, so I'm simply going to state mine and move on: reading 0 bytes from a file is not an error (at least initially) if the file is empty and there is no provision for testing for EOF, and the reason for that is so that reading bytes (or the lack thereof) is distinguishable from a storage management layer error... unless the storage management layer chooses to return an end of file condition as an error, of course. >> However, if there was no error, are you saying that $! is "meaningless"? >> This is the snag, you see. > >If there is no error the die call never happens so $! is never used. That's predicated on the religious opinion that reading 0 bytes is an error. >> And it's not just "any value", it's an ioctl.. every time. >> >> As a matter of fact, I just tried your suggestion on an empty file with >> perl v5.8.0 i586-linux-thread-multi (plus SuSE patches) and by golly I got >> Inappropriate ioctl for device. >> >> On 5.005_03 $! is .. well... false. >> >> Anything else I missed here? Yes. The system with 5.5.3 is on an ext2 fs, >> and the system with 5.8.0 is reiserfs. FWIW. > >reiserfs is considering the attempt to read an empty file an error and >setting errno. ext2 apparently doesn't consider it as such. This has just been proven to be an unfounded and in fact incorrect assumption. >Not all >filesystems are created equally. Apparently they are in this case. Perhaps it's Linux? No, just tried it on a Solaris box with 5.5.3, and $! was false. Anybody else out there care to try and flesh out the failure matrix? >However, perl does consider it an error because there is nothing to put >in the array i.e. the assignment failed. OK, I understand: your argument is that Perl has been "fixed" so that it conforms to the documentation. That conforms to the matrix thus far, at any rate. (Or taking it at face value, this three line program is generating a valid Inappropriate ioctl error unrelated to reading an empty file? No, just tested that and in fact $! is being set to Inappropriate ioctl by the open, it's false prior to that; this is in spite of the fact that open returns successfully.) (So Perl has been "fixed" to conform to the documentation by having open set $! to an error number while returning successfully? Occam, sharpen your razor!) >> But again: I am sure that the file(s) in question in the real app are *not* >> empty. How does one check for a "no problem" condition when at end of >> file.. because we can ascertain, by both documentation and practice, that >> "end of file" is reached when the end of file is reached as well as when >> there is an I/O error. >> >> Am I a flipper baby for wanting to be able to check for I/O read status? >> Does nobody do this? Wow. > >This is generally not a concern when reading files in perl because perl >handles the I/O issues for you. Sounds to me like you're trying to do >work that's already handled for you... "Generally" is not the issue here. I have a specific problem, and this peccadillo of Perl is interfering with my ability to trace it. Specifically, I appear to be having a problem with mod_perl on Apache 2 where file I/O (input, specifically) is failing in an inconsistent manner. Therefore there exists a reasonable basis for concluding that Perl is *not* handling the I/O issues for me. Reading $! is proving not to be a reliable mechanism for determining I/O status. I need a reliable mechanism for determining I/O status; I am appealing for suggestions to this end. I am profoundly uninterested in continuing to bloviate on the Perlishness of Perl, except insofar as it may provide a means to refine this appeal. The section in perlvar on _Error Indicators_ states that $! corresponds to errors detected in the C library. perlvar says about $!: 'You can assign a number to $! to set errno if, for instance, you want "$!" to return the string for error n, or you want to set the exit value for the die() operator." Should I set it to undef or 0 prior to the loop? It does eliminate the Inappropriate ioctl message when used on the test program. Is this best practice? As good as it gets? Can anybody else confirm this? Have I been enlisted in yet another snark hunt because "it's not a problem with Perl" that $! is not being altered by the read, and that "yes it is a problem with Perl" that open is returning success (and successfully) yet leaving $! set to Inappropriate ioctl (which it does even when the file is *not* empty, for anybody who came in late or has a short attention span.. and I retested this just now with the test program to be sure)? Is that cause for concern? (Occam? Occam?) >"Conscience is the inner voice which warns us somebody may be looking." >- H.L. Mencken "Why do people go to the zoo?" -- H.L. Mencken, when asked why he didn't leave America since he didn't have anything good to say about it. -- Fred Morris m3047@inwa.net From ben at reser.org Fri Sep 19 11:24:46 2003 From: ben at reser.org (Ben Reser) Date: Mon Aug 2 21:37:09 2004 Subject: I/O status Re: SPUG: proper checking of file status after read? In-Reply-To: References: Message-ID: <20030919162446.GE9055@titanium.brain.org> On Fri, Sep 19, 2003 at 03:49:21AM -0700, Fred Morris wrote: > There are times I consider documentation to be the final arbiter, and > times I consider behavior paramount. > > I observe that perlvar seems to ignore status checking on read in its > examples. Yeah, because as I pointed out it's usually not an issue at all. > I consider it a success because the failure to read data was not due to a > failure of the storage management layer. Is there another language which > considers end-of-file on initial read to be a storage layer failure? > (Incidentally, I would say that Perl does not consider it an error > condition either.) Attempting to read beyond EOF is considered an error in > many languages; languages which do so on initial read typically provide an > EOF test, used as until EOF() read(). Try for mainstream here; provide an > example or be discarded. Even with SQL, reading 0 records returns an empty > set.. not an error. man errno(3) lists ENOTTY as Inappropriate I/O control > operation, but there is no error for end of file or empty file. BTW, > attempting to read beyond EOF in Perl 5.8 reads 0 lines and does not set > $!. That's really a side issue, I'm not going to go back and test in other > versions. I understand what you mean, but you're trying to separate the read from what you're doing with it. The code I provided is not written that way. No data returned from the RHS of an assignment is an error. If I wasn't trapping it then normaly you wouldn't notice it, because as with most errors perl simply sets the left hand side to undef. It looks like blaming it on the file system was incorrect. I'll get to why it's happening in a little bit. I jumped to that conclusion on my cursory testing here and past experience with file systems behaving slightly differently in some situations. > I can tell this might be the start of a religious difference of opinion, so > I'm simply going to state mine and move on: reading 0 bytes from a file is > not an error (at least initially) if the file is empty and there is no > provision for testing for EOF, and the reason for that is so that reading > bytes (or the lack thereof) is distinguishable from a storage management > layer error... unless the storage management layer chooses to return an end > of file condition as an error, of course. I don't think it's religious. I think you're looking at it from a different perspective. My thought is why would you open a file to read nothing? Your thoughts seem to be, that since the read didn't fail per se, then there's no error. The difference is I'm looking from it at your applications standpoint and you're looking at it from the system calls standpoint. Frankly, I don't generally look at things from the system calls standpoint unless: a) I'm having an issue with making a system call work. b) I'm writing a system call. > Apparently they are in this case. Perhaps it's Linux? No, just tried it on > a Solaris box with 5.5.3, and $! was false. Anybody else out there care to > try and flesh out the failure matrix? Actually it's coming from the fact that $! is undefined unless there has been an error. There was an error but the particular error I trapped doesn't set errno. As a result it's getting an errno from a prvious call. At any rate it looks like in 5.8.1 they cleaned up this particular issue, because after the open $! is set back to zero. In 5.8.0 it's coming from this: ioctl(3, TCGETS, 0x7ffff078) = -1 ENOTTY (Inappropriate ioctl for device) on 5.8.1 it does this: ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbffff420) = -1 ENOTTY (Inappropriate ioctl for device) But $! is 0 when it dies due to the assignment not setting anything. Technically, it looks like they fixed open to set errno back to 0 if it was successful. But the documentation is still correct because you can't assume that other system calls will do this. Indeed we know many of them do not. Since those system calls are not part of perl and $! is just an interface to errno there's not much they can do about that. At least not in all cases. > OK, I understand: your argument is that Perl has been "fixed" so that it > conforms to the documentation. That conforms to the matrix thus far, at any > rate. (Or taking it at face value, this three line program is generating a > valid Inappropriate ioctl error unrelated to reading an empty file? No, > just tested that and in fact $! is being set to Inappropriate ioctl by the > open, it's false prior to that; this is in spite of the fact that open > returns successfully.) (So Perl has been "fixed" to conform to the > documentation by having open set $! to an error number while returning > successfully? Occam, sharpen your razor!) I doubt it's been "fixed" that way. I'd just imagine prior to 5.8.1 it wasn't unsetting errno. The difference on other platforms (Solaris) may simply be that it isn't calling an ioctl that's inappropriate on that platform. > I need a reliable mechanism for determining I/O status; I am appealing for > suggestions to this end. I am profoundly uninterested in continuing to > bloviate on the Perlishness of Perl, except insofar as it may provide a > means to refine this appeal. If you really don't want to consider a read of an zero length file an error, which may or may not be an issue for your app.... Then you'll have to do something like this: open(TEST, 'perlfiletest') or die "Couldn't open perlfiletest: $!"; until (eof(TEST)) { my $buffer; read(TEST,$buffer,1024) or die "Read error on perlfiletest: $!"; # mystuff with file contents goes here } I went with the more perlish @foo = or die previously because it was simpler and more perlish. I really didn't think that reading an empty file would be an issue for you. > The section in perlvar on _Error Indicators_ states that $! corresponds to > errors detected in the C library. perlvar says about $!: 'You can assign a > number to $! to set errno if, for instance, you want "$!" to return the > string for error n, or you want to set the exit value for the die() > operator." Should I set it to undef or 0 prior to the loop? It does > eliminate the Inappropriate ioctl message when used on the test program. > > Is this best practice? As good as it gets? Can anybody else confirm this? I think it's a bad idea because it is bound to break under some conditions. If you really want to test the reads for errors you'll have to do them yourself rather than doing it in a perlish way. > Have I been enlisted in yet another snark hunt because "it's not a problem > with Perl" that $! is not being altered by the read, and that "yes it is a > problem with Perl" that open is returning success (and successfully) yet > leaving $! set to Inappropriate ioctl (which it does even when the file is > *not* empty, for anybody who came in late or has a short attention span.. > and I retested this just now with the test program to be sure)? Is that > cause for concern? (Occam? Occam?) I don't think it's a problem with perl. The manual already tells you that $! isn't likely to be unset by a successful call. But at any rate it does not exhibit the same behavior on 5.8.1. So it really doesn't matter now. On another matter. I don't know if it's just me but your replies seem to have a rather arrogant tone to them. I don't think this is your intention, but it certainly is the way it is coming across to me. It's usually not a good way to get help with something by coming across that way. -- Ben Reser http://ben.reser.org "Conscience is the inner voice which warns us somebody may be looking." - H.L. Mencken From ced at carios2.ca.boeing.com Fri Sep 19 14:07:47 2003 From: ced at carios2.ca.boeing.com (ced@carios2.ca.boeing.com) Date: Mon Aug 2 21:37:09 2004 Subject: I/O status Re: SPUG: proper checking of file status after read? Message-ID: <200309191907.MAA08630@carios2.ca.boeing.com> > If you really don't want to consider a read of an zero length file an > error, which may or may not be an issue for your app.... Then you'll > have to do something like this: > open(TEST, 'perlfiletest') or die "Couldn't open perlfiletest: $!"; > until (eof(TEST)) { > my $buffer; > read(TEST,$buffer,1024) or die "Read error on perlfiletest: $!"; > # mystuff with file contents goes here >... FIONREAD from the Cookbook (recipe 7.15) might be a workaround by peeking first to see if there's anything there: $size = pack( "L", 0 ); ioctl( TEST, $FIONREAD, $size ) or die $!; read( TEST, $buff, $size) if $size = unpack( "L", $size); [untested] -- Charles DeRykus From pate at eylerfamily.org Fri Sep 19 17:06:13 2003 From: pate at eylerfamily.org (Pat Eyler) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: open-sauce lunch Message-ID: Hi all, Anyone up for a lunch on 9/24 in the International District? I'll take suggestions for an actual location and post something on Monday. -pate From m3047 at inwa.net Sat Sep 20 00:08:53 2003 From: m3047 at inwa.net (Fred Morris) Date: Mon Aug 2 21:37:09 2004 Subject: eof() Re: I/O status Re: SPUG: proper checking of file status... Message-ID: Is there anything which says that eof() is or is not true when there has been an I/O error on a read? -- Fred Morris m3047@inwa.net From m3047 at inwa.net Sat Sep 20 03:19:25 2003 From: m3047 at inwa.net (Fred Morris) Date: Mon Aug 2 21:37:09 2004 Subject: mod_perl/Apache 2 fixed Re: I/O status Re: SPUG: proper checking... Message-ID: Well, I set $! = 0 before my while () read loop, and now it properly and consistently reads files... with no errors. To reiterate, I was having problems with what appeared to be files corrupted on read. A lot of them slurped (most of them in fact), but there were several config files which were read in a line at a time (and an empty file is not an error). Sometimes a 4 line file would read 4 lines, sometimes it would not. mod_perl was generally behaving poorly. The sensible hack of testing $! after the loop was failing on Perl 5.8.0/SuSE Linux 8.2 (x86). Separate testing revealed that open() was returning successfully but leaving $! set. The error was Inappropriate ioctl, and strace pinned this on an operation code of SNDCTL_TMR_TIMEBASE, which is a soundcard call (the machine in question doesn't even have a sound card!). Searching on the 'net including Google, SuSE's support database, perlbug and whatnot turned up no mention of this problem in the context of Perl. However, there were several mentions of ioctls with SNDCTL_TMR_TIMEBASE in the context of problems with file I/O. Furthermore, it appears major work was done on I/O in Perl 5.8. Ignoring the advice of everyone, I set $! = 0 after the (successful) open and immediately prior to the while loop in the module which reads the config files. No more errors at (implicit) end of file (and I'm continuing to test $! at that point). 4 line files always read at 4 lines. Warns print in the logs consistently. mod_perl is happy. I'm happy. Do I know why? No. Does that bother me? Just remember this: Perl doesn't kill problem solving ability, people kill problem solving ability. I would like to extend my appreciation to Yitzchak Scott-Thoennes and Brian Hatch for their insightful suggestions, which didn't lead directly to solving the problem but which did assist in whacking some of the early working hypotheses: greatly appreciated, thanks. Well, in retrospect a close comparative examination of the strace between working and nonworking systems certainly argues for the virtues of the hack. I'll probably follow up on Adam Monsen's and Douglas Kirkland's suggestions and at least look at CGI::Simple, CGI::Minimal and HTTP::Headers, although at this point I conclude CGI.pm is not the culprit (provided you have the latest version from Stein's site). -- Fred Morris m3047@inwa.net From sthoenna at efn.org Sat Sep 20 23:23:00 2003 From: sthoenna at efn.org (Yitzchak Scott-Thoennes) Date: Mon Aug 2 21:37:09 2004 Subject: mod_perl/Apache 2 fixed Re: I/O status Re: SPUG: proper checking... In-Reply-To: References: Message-ID: <20030921042300.GA1860@efn.org> On Sat, Sep 20, 2003 at 01:19:25AM -0700, Fred Morris wrote: > at this point I conclude CGI.pm is not the culprit (provided you > have the latest version from Stein's site). Weird. CGI.pm lists different sites in the beginning comments vs. in the pod, and neither seems to have anything newer than 2.98. CPAN has 3.00 (and so does bleadperl and 5.8.1-to-be). From ben at reser.org Sun Sep 21 03:29:46 2003 From: ben at reser.org (Ben Reser) Date: Mon Aug 2 21:37:09 2004 Subject: mod_perl/Apache 2 fixed Re: I/O status Re: SPUG: proper checking... In-Reply-To: <20030921042300.GA1860@efn.org> References: <20030921042300.GA1860@efn.org> Message-ID: <20030921082946.GQ9055@titanium.brain.org> On Sat, Sep 20, 2003 at 09:23:00PM -0700, Yitzchak Scott-Thoennes wrote: > Weird. CGI.pm lists different sites in the beginning comments vs. in > the pod, and neither seems to have anything newer than 2.98. CPAN has > 3.00 (and so does bleadperl and 5.8.1-to-be). And it's important to use the current version off CPAN as it has important security fixes. -- Ben Reser http://ben.reser.org "Conscience is the inner voice which warns us somebody may be looking." - H.L. Mencken From m3047 at inwa.net Sun Sep 21 15:49:33 2003 From: m3047 at inwa.net (Fred Morris) Date: Mon Aug 2 21:37:09 2004 Subject: mod_perl/Apache 2 fixed Re: I/O status Re: SPUG: proper Message-ID: At 9:23 PM 9/20/03, Yitzchak Scott-Thoennes wrote: >On Sat, Sep 20, 2003 at 01:19:25AM -0700, Fred Morris wrote: >> at this point I conclude CGI.pm is not the culprit (provided you >> have the latest version from Stein's site). > >Weird. CGI.pm lists different sites in the beginning comments vs. in >the pod, and neither seems to have anything newer than 2.98. CPAN has >3.00 (and so does bleadperl and 5.8.1-to-be). I originally had something older than 2.98, don't remember what. It definitely had some issues. I did a quick search for CGI.pm at CPAN, and I'm guessing it didn't include the standard modules since it didn't find CGI.pm. So I went to Stein's site and got 2.98. I'm not particularly worried about the cross-site scripting issue.. I'm not that trusting in the first place. *shrug* The Calendar Thingie (thank Tim for that name) works with mod_perl/Apache 2, and I learned that Linux is trying to determine the MIDI clock settings of my filesystem! :-\ I'm putting the box back on 1.3 now, because there's a lot of stuff on the SuSE 8.2 distro which doesn't seem to run on A2, at least not out of the box. Unfortunately, I have to uninstall the A2 mod_perl and install the 1.3 mod_perl so it's not quite as simple as stopping one and starting the other. PS: the link on the SPUG page to the S.W.A.N. is wrong, it moved and it now has a name: http://devil.m3047.inwa.net/... FWIW. (And no, that's not the box running SuSE 8.2.) -- Fred Morris m3047@inwa.net From tim at consultix-inc.com Mon Sep 22 23:57:52 2003 From: tim at consultix-inc.com (Tim Maher) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Amazon Tech. Recruiting Event Message-ID: <20030922215752.A28908@timji.consultix-inc.com> (This message is going out to and gslug-general. I'm bcc'ing a few -admin addresses for other UGs out here to allow the administrators to decide if it's on topic for their list or not.) An Amazon recruiter I know[1] asked me to let local Linux folks know about an upcoming recruitment event they're having. Their 'glossy' ad is at the following URL: http://www.harvestadsdepot.com/nwclassified/outgoing/E228008201.245.htm And the ad + additional text is at http://tinyurl.com/oa7z and I'll include some of the text below. See the above two URLs for it in full. The short version: They're looking for a bunch of techies, and are having an 'invitation-only' interview/meeting with their CTO. Email your resume to the address listed in the ad to find out more. [1] Our kids go to the same day care - I had no idea I knew any Amazon recruiters... ------------ Amazing Careers for Smart Engineers Why do smart engineers enjoy working at Amazon.com? We asked them. They told us they get to work on some of the planet's most complex challenges in large scale computing. They get to work with smart experienced people on small cross-functional teams. And, they know that their hard work helps us create a world class customer experience for the millions of people who use.Amazon.com. Software Development Engineers - UI (Web Development Engineers) We seek smart, results oriented and customer-focused people who write code and build systems to solve real business problems. Our Software Engineers require knowledge of Object Oriented design and development, experience building large-scale systems in C++ or Java on UNIX or Linux, and algorithms expertise. Our Software Development Engineers-UI/Web Development Engineers must have experience with Perl/Mason to build software for the presentation layer, as well as proficiency in usability/HCI, C/C++ Javascript, DHTML and Flash. A Computer Science or Math degree and 7+ years' experience are preferred for both positions. We'll be holding several invite only interview days in early October Participants can attend a special presentation from our CTO. Please email your resume directly to: anna@amazon.com. Please indicate "CTO" in the subject line include info on the type of challenges you'd enjoy most, and let us know your availability for an in-person interview. More information about these and other opportunities is available at www.amazon.com/techjobs ------------ -- Brian Hatch Justify my text? Systems and I'm sorry, but Security Engineer it has no excuse. http://www.ifokr.org/bri/ Every message PGP signed From cmeyer at helvella.org Thu Sep 25 12:14:50 2003 From: cmeyer at helvella.org (Colin Meyer) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Perl 5.8.1 Message-ID: <20030925101450.A11714@hobart.helvella.org> After a long and arduous development cycle, Jarkko Hietaniemi has released Perl 5.8.1. http://www.cpan.org/authors/id/J/JH/JHI/perl-5.8.1.tar.gz Jarkko's announcement on p5p: http://nntp.perl.org/group/perl.perl5.porters/82678 Have fun, -Colin. From kenslinux at shaw.ca Thu Sep 25 16:48:12 2003 From: kenslinux at shaw.ca (Ken Clarke) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: DB connection via SSH tunneling Message-ID: <001b01c383ae$b7bbeb40$13c46c18@gv.shawcable.net> Hi Folks, Does anyone on the list have experience connecting to a remote database through an SSH tunnel? Here's the problem I've been handed: Write a series of CGI scripts for use on a publicly hosted (third party ISP) website which are capable of retrieving data from an MS SQL server running on a private, internal LAN. I feel that an SSH tunnel is the idea answer since it provides host authentication (the request comes from client's web host), user authentication (it's one of my scripts) and data encryption (protects the database access parameters and other advantages). Here's what I have in mind. They can run Vandyke's VShell behind their corporate firewall. VShell can be configured to provide ODBC connectivity to any system DSN on the internal LAN. I can create an SSH connection using Net::SSH::Perl but this is as far as I get. I have the ODBC connection in my left hand and DBI's methods in the right hand. How do I bring the two together? Any input or alternative suggestions are greatly appreciated. From jmates at sial.org Thu Sep 25 17:14:32 2003 From: jmates at sial.org (Jeremy Mates) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Re: DB connection via SSH tunneling In-Reply-To: <001b01c383ae$b7bbeb40$13c46c18@gv.shawcable.net> References: <001b01c383ae$b7bbeb40$13c46c18@gv.shawcable.net> Message-ID: <20030925221432.GB80610@darkness.sial.org> * Ken Clarke > Here's what I have in mind. They can run Vandyke's VShell behind their > corporate firewall. VShell can be configured to provide ODBC > connectivity to any system DSN on the internal LAN. I can create an > SSH connection using Net::SSH::Perl but this is as far as I get. I > have the ODBC connection in my left hand and DBI's methods in the > right hand. How do I bring the two together? Port forwarding, perhaps? The 5333 is the (random, honest!) port to bind to on 127.0.0.1 on your system, and the ???? should be replaced with the port ODBC listens on. my $ssh = Net::SSH::Perl->new("host", options => [ "LocalForward 5333 internalodbchostname:????" ]); Once the SSH connection is made, in theory you should be able to connect to 127.0.0.1:5333 and be automagically connected to the internal host. From jimfl at tensegrity.net Thu Sep 25 17:23:59 2003 From: jimfl at tensegrity.net (Jim Flanagan) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: DB connection via SSH tunneling In-Reply-To: <001b01c383ae$b7bbeb40$13c46c18@gv.shawcable.net> References: <001b01c383ae$b7bbeb40$13c46c18@gv.shawcable.net> Message-ID: On Thu, 25 Sep 2003, Ken Clarke wrote: > Here's what I have in mind. They can run Vandyke's VShell behind their > corporate firewall. VShell can be configured to provide ODBC connectivity > to any system DSN on the internal LAN. I can create an SSH connection using > Net::SSH::Perl but this is as far as I get. I have the ODBC connection in > my left hand and DBI's methods in the right hand. How do I bring the two > together? You need to set up a port forward with ssh, then have DBI connect to the local port. Let's say that the database on the remote machine is running on port 123. We will set up a local port 9123 on the local machine that forwards traffic to the 123 on the remote machine over the SSH connection. With the command line, that would look like: ssh -L9123:localhost:123 user@remote With Net::SSH::Perl, you'd have to use the options parameter to the constructor to set this up: $ssh = new Net::SSH::Perl("remote", options => ["LocalForward 9123 localhost:123"]); Then you can use DBI to connect to the database on locahost:9123 as usual. -- Flanagan::Jim http://jimfl.tensegrity.net mailto:jimfl%40t%65ns%65gr%69ty.n%65t From sthoenna at efn.org Thu Sep 25 18:56:35 2003 From: sthoenna at efn.org (Yitzchak Scott-Thoennes) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Perl 5.8.1 In-Reply-To: <20030925101450.A11714@hobart.helvella.org> References: <20030925101450.A11714@hobart.helvella.org> Message-ID: <20030925235634.GA2928@efn.org> On Thu, Sep 25, 2003 at 10:14:50AM -0700, Colin Meyer wrote: > After a long and arduous development cycle, Jarkko Hietaniemi has > released Perl 5.8.1. > > http://www.cpan.org/authors/id/J/JH/JHI/perl-5.8.1.tar.gz > > Jarkko's announcement on p5p: > http://nntp.perl.org/group/perl.perl5.porters/82678 I think Jarkko had to release it now or never...the perl5-porters hive mind was beginning to break down. Witness: On Wed, 24 Sep 2003 10:34:26 -0400, those who shall remain anonymous wrote: >>>>>> In my day, we used to edit the inodes by hand. With >>>>>> magnets. >>>>> >>>>> You had magnets?! >>>> >>>> Yeah, we were right posh in our house. >>> >>> We had to hang our inodes north-south and whack them with hammers to >>> try to get them inodes to shuffle right. >> >> You're lucky! We had to align the inodes and wait for the Earth's >> magnetic poles to flip! Take about a slow read/write rate... > >Poles? You had two poles? Wow, that must have made things easy. We >only had one pole... From tim at consultix-inc.com Sat Sep 27 16:17:26 2003 From: tim at consultix-inc.com (Tim Maher) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: testing Message-ID: <20030927141726.A5193@timji.consultix-inc.com> Sat Sep 27 14:17:26 PDT 2003 From djames at serv.net Sat Sep 27 16:23:48 2003 From: djames at serv.net (Daniel James) Date: Mon Aug 2 21:37:09 2004 Subject: (was) SPUG: testing In-Reply-To: <20030927141726.A5193@timji.consultix-inc.com> References: <20030927141726.A5193@timji.consultix-inc.com> Message-ID: <19340.216.39.185.245.1064697828.squirrel@www.oz.net> Tim Maher said: > Sat Sep 27 14:17:26 PDT 2003 Got it... ...but the real question is, have you watched Office Space yet... ;-) From djames at serv.net Sat Sep 27 16:30:10 2003 From: djames at serv.net (Daniel James) Date: Mon Aug 2 21:37:09 2004 Subject: (was) SPUG: testing In-Reply-To: <20030927141726.A5193@timji.consultix-inc.com> References: <20030927141726.A5193@timji.consultix-inc.com> Message-ID: <19343.216.39.185.245.1064698210.squirrel@www.oz.net> Tim Maher said: > Sat Sep 27 14:17:26 PDT 2003 Got it... ...but the real question is, have you watched Office Space yet... ;-) From jdevlin at stadiumdistrict.com Sun Sep 28 03:37:52 2003 From: jdevlin at stadiumdistrict.com (Joe Devlin) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Re: Dancerboy References: <1063308435.954.14.camel@karma.localnet> Message-ID: <03b501c3859b$cf93c960$e1cb4b43@oemcomputer> I barely survived Paxil. This prescription antidepressant drug is killing people. There are very effective natural alternatives. For example: vitamin B and Omega-3 DHA (fish oil), exercise, sunshine and zero debt. The knowledge is free, and the market is open source. No need to be hooked on one manufacturers drug. See... http://www.antidepressantsfacts.com/ClassActionAmerica-Prozac-Zoloft-Paxil.htm I hope this message can help you or someone you know. Joe Devlin ----- Original Message ----- From: "C.J. Collier" To: "Seattle Perl Users Group" Sent: Thursday, September 11, 2003 12:27 PM Subject: SPUG: Dancerboy > One of our members, dancerboy, recently passed away. He left us this: > > http://my.strangelight.com/ > > C.J. > > > > _____________________________________________________________ > Seattle Perl Users Group Mailing List > POST TO: spug-list@mail.pm.org http://spugwiki.perlocity.org > ACCOUNT CONFIG: http://mail.pm.org/mailman/listinfo/spug-list > MEETINGS: 3rd Tuesdays, U-District, Seattle WA > WEB PAGE: http://www.seattleperl.org > > From richard at richard-anderson.org Sun Sep 28 19:25:56 2003 From: richard at richard-anderson.org (Richard Anderson) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Congrats, Brian - Inline to be adopted into core of Perl Message-ID: <003901c38622$0da4a590$a52efea9@TOSHIBARGA> Congratulations to Brian Ingerson, whose Inline module is scheduled to be incorporated into the core Perl distribution in a future release (according to the Perl 5.8.1 Release Announcement at http://use.perl.org/articles/03/09/26/2231256.shtml?tid=6 ). This is a de facto statement by the Perl inner circle that Brian's module is a good solution and is widely used. Richard Anderson richard@richard-anderson.org www.richard-anderson.org Richard.Anderson@raycosoft.com www.raycosoft.com From spug at ifokr.org Tue Sep 30 12:11:08 2003 From: spug at ifokr.org (Brian Hatch) Date: Mon Aug 2 21:37:09 2004 Subject: SPUG: Open Sauce Lunch today in Ballard Message-ID: <20030930171108.GE29124@ifokr.org> The next Open Sauce Lunch is Today, Sep 30th at 12:30 at Thai Siam Restraunt in Ballard, on 15th Ave and 83rd street. For more details and maps, go to http://spugwiki.perlocity.org/index.cgi?TuesdaySep30inBallard If you are coming, either add your name to the wiki entry above, or send me an email so I can reserve an appropriate table. If you have a PGP/GPG key, bring a copy of your fingerprint/bits/etc and ID with you, so we can exchange and sign keys as well. Look for a 3.5 year old girl wearing a blue jogging suit, that will be this lunch's Convener, Reegen Hatch. (Why the short notice? Because I've been busier than hell and haven't had the time to organize one, but my daughter's home "sick" from day care, so that forces/frees my hand...) -- Brian Hatch What do you call a firewall Systems and that proxies HTTP, SMTP, Security Engineer ftp, telnet, and ping? http://www.ifokr.org/bri/ A router. Every message PGP signed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/spug-list/attachments/20030930/88326ec4/attachment.bin