From jeff at planetoid.net Thu Jun 1 18:24:50 2000 From: jeff at planetoid.net (jeff) Date: Thu Aug 5 00:20:05 2004 Subject: system call exit status Message-ID: <3936F0C2.97A6CD4@planetoid.net> ~sdpm~ How can I decode a non-zero exit status returned from the system function call? I'm trying the following my @unzip_system = ('unzip', '-d', $tmp, '-q', "$tmp/file.zip"); if (system(@unzip_system)) { carp "system (@unzip_system) failed ($?)"; system("rm -fr $tmp"); next; } and getting the error... system (unzip -d /tmp/unzip.20763 -q /tmp/unzip.20763/file.zip) failed (65280) at /prod/newsfeed/bin/get_news line 90 What does the number 65280 mean? -- Jeff Saenz jeff@planetoid.net ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From rkleeman at neta.com Thu Jun 1 18:33:36 2000 From: rkleeman at neta.com (Bobby Kleemann) Date: Thu Aug 5 00:20:05 2004 Subject: system call exit status In-Reply-To: <3936F0C2.97A6CD4@planetoid.net> Message-ID: ~sdpm~ >From http://www.perl.com/pub/doc/manual/html/pod/perlfunc/system.html You can check all the failure possibilities by inspecting $? like this: $exit_value = $? >> 8; $signal_num = $? & 127; $dumped_core = $? & 128; _ _ _ Bobby Kleemann http://www.neta.com/~rkleeman/ On Thu, 1 Jun 2000, jeff wrote: > ~sdpm~ > How can I decode a non-zero exit status returned from the system > function call? > > I'm trying the following > > my @unzip_system = ('unzip', '-d', $tmp, '-q', "$tmp/file.zip"); > if (system(@unzip_system)) { > carp "system (@unzip_system) failed ($?)"; > system("rm -fr $tmp"); > next; > } > > and getting the error... > > system (unzip -d /tmp/unzip.20763 -q /tmp/unzip.20763/file.zip) failed > (65280) at /prod/newsfeed/bin/get_news line 90 > > What does the number 65280 mean? > > -- > Jeff Saenz > jeff@planetoid.net > > > ~sdpm~ > > The posting address is: san-diego-pm-list@hfb.pm.org > > List requests should be sent to: majordomo@hfb.pm.org > > If you ever want to remove yourself from this mailing list, > you can send mail to with the following > command in the body of your email message: > > unsubscribe san-diego-pm-list > > If you ever need to get in contact with the owner of the list, > (if you have trouble unsubscribing, or have questions about the > list itself) send email to . > This is the general rule for most mailing lists when you need > to contact a human. > ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From jeff at planetoid.net Thu Jun 1 18:51:12 2000 From: jeff at planetoid.net (jeff) Date: Thu Aug 5 00:20:05 2004 Subject: system call exit status References: Message-ID: <3936F6F0.D1838215@planetoid.net> ~sdpm~ well the exit_value comes out to 255 and the signal_num is 0. What do they mean? Bobby Kleemann wrote: > ~sdpm~ > >From http://www.perl.com/pub/doc/manual/html/pod/perlfunc/system.html > > You can check all the failure possibilities by inspecting $? like this: > > $exit_value = $? >> 8; > $signal_num = $? & 127; > $dumped_core = $? & 128; > > _ _ _ > Bobby Kleemann > http://www.neta.com/~rkleeman/ > > On Thu, 1 Jun 2000, jeff wrote: > > > ~sdpm~ > > How can I decode a non-zero exit status returned from the system > > function call? > > > > I'm trying the following > > > > my @unzip_system = ('unzip', '-d', $tmp, '-q', "$tmp/file.zip"); > > if (system(@unzip_system)) { > > carp "system (@unzip_system) failed ($?)"; > > system("rm -fr $tmp"); > > next; > > } > > > > and getting the error... > > > > system (unzip -d /tmp/unzip.20763 -q /tmp/unzip.20763/file.zip) failed > > (65280) at /prod/newsfeed/bin/get_news line 90 > > > > What does the number 65280 mean? > > > > -- > > Jeff Saenz > > jeff@planetoid.net > > > > > > ~sdpm~ > > > > The posting address is: san-diego-pm-list@hfb.pm.org > > > > List requests should be sent to: majordomo@hfb.pm.org > > > > If you ever want to remove yourself from this mailing list, > > you can send mail to with the following > > command in the body of your email message: > > > > unsubscribe san-diego-pm-list > > > > If you ever need to get in contact with the owner of the list, > > (if you have trouble unsubscribing, or have questions about the > > list itself) send email to . > > This is the general rule for most mailing lists when you need > > to contact a human. > > > > ~sdpm~ > > The posting address is: san-diego-pm-list@hfb.pm.org > > List requests should be sent to: majordomo@hfb.pm.org > > If you ever want to remove yourself from this mailing list, > you can send mail to with the following > command in the body of your email message: > > unsubscribe san-diego-pm-list > > If you ever need to get in contact with the owner of the list, > (if you have trouble unsubscribing, or have questions about the > list itself) send email to . > This is the general rule for most mailing lists when you need > to contact a human. -- Jeff Saenz jeff@planetoid.net ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From rkleeman at neta.com Thu Jun 1 19:05:26 2000 From: rkleeman at neta.com (Bobby Kleemann) Date: Thu Aug 5 00:20:05 2004 Subject: system call exit status In-Reply-To: <3936F6F0.D1838215@planetoid.net> Message-ID: ~sdpm~ >From what I read in my copy of the man page (pull from it what you will) (see below). I'm not sure what it means in your case (I don't see a 255 error code) so you may want to visit whatever website there is (ftp://ftp.freesoftware.com/pub/infozip/Info-ZIP.html) and see if there is more documentation on error codes. DIAGNOSTICS The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the following values, except under VMS: 0 normal; no errors or warnings detected. 1 one or more warning errors were encountered, but processing completed successfully anyway. This includes zipfiles where one or more files was skipped due to unsupported compression method or encryption with an unknown password. 2 a generic error in the zipfile format was detected. Processing may have completed success- fully anyway; some broken zipfiles created by other archivers have simple work-arounds. 3 a severe error in the zipfile format was detected. Processing probably failed immediately. 4 unzip was unable to allocate memory for one or more buffers during program initialization. 5 unzip was unable to allocate memory or unable to obtain a tty to read the decryption password(s). 6 unzip was unable to allocate memory during decompression to disk. 7 unzip was unable to allocate memory during in- memory decompression. 8 [currently not used] 9 the specified zipfiles were not found. Info-ZIP Last change: 3 November 1997 (v5.32) 11 Maintenance Commands UNZIP(1M) 10 invalid options were specified on the command line. 11 no matching files were found. 50 the disk is (or was) full during extraction. 51 the end of the ZIP archive was encountered prema- turely. 80 the user aborted unzip prematurely with control-C (or similar) 81 testing or extraction of one or more files failed due to unsupported compression methods or unsup- ported decryption. 82 no files were found due to bad decryption password(s). (If even one file is successfully processed, however, the exit status is 1.) VMS interprets standard Unix (or PC) return values as other, scarier-looking things, so unzip instead maps them into VMS-style status codes. The current mapping is as follows: 1 (success) for normal exit, 0x7fff0001 for warning errors, and (0x7fff000? + 16*normal_unzip_exit_status) for all other errors, where the `?' is 2 (error) for unzip values 2, 9-11 and 80-82, and 4 (fatal error) for the remaining ones (3-8, 50, 51). In addition, there is a compilation option to expand upon this behavior: defining RETURN_CODES results in a human-readable explanation of what the error status means. _ _ _ Bobby Kleemann http://www.neta.com/~rkleeman/ On Thu, 1 Jun 2000, jeff wrote: > ~sdpm~ > well the exit_value comes out to 255 and the signal_num is 0. What do they mean? > > Bobby Kleemann wrote: > > > ~sdpm~ > > >From http://www.perl.com/pub/doc/manual/html/pod/perlfunc/system.html > > > > You can check all the failure possibilities by inspecting $? like this: > > > > $exit_value = $? >> 8; > > $signal_num = $? & 127; > > $dumped_core = $? & 128; > > > > _ _ _ > > Bobby Kleemann > > http://www.neta.com/~rkleeman/ > > > > On Thu, 1 Jun 2000, jeff wrote: > > > > > ~sdpm~ > > > How can I decode a non-zero exit status returned from the system > > > function call? > > > > > > I'm trying the following > > > > > > my @unzip_system = ('unzip', '-d', $tmp, '-q', "$tmp/file.zip"); > > > if (system(@unzip_system)) { > > > carp "system (@unzip_system) failed ($?)"; > > > system("rm -fr $tmp"); > > > next; > > > } > > > > > > and getting the error... > > > > > > system (unzip -d /tmp/unzip.20763 -q /tmp/unzip.20763/file.zip) failed > > > (65280) at /prod/newsfeed/bin/get_news line 90 > > > > > > What does the number 65280 mean? > > > > > > -- > > > Jeff Saenz > > > jeff@planetoid.net > > > > > > > > > ~sdpm~ > > > > > > The posting address is: san-diego-pm-list@hfb.pm.org > > > > > > List requests should be sent to: majordomo@hfb.pm.org > > > > > > If you ever want to remove yourself from this mailing list, > > > you can send mail to with the following > > > command in the body of your email message: > > > > > > unsubscribe san-diego-pm-list > > > > > > If you ever need to get in contact with the owner of the list, > > > (if you have trouble unsubscribing, or have questions about the > > > list itself) send email to . > > > This is the general rule for most mailing lists when you need > > > to contact a human. > > > > > > > ~sdpm~ > > > > The posting address is: san-diego-pm-list@hfb.pm.org > > > > List requests should be sent to: majordomo@hfb.pm.org > > > > If you ever want to remove yourself from this mailing list, > > you can send mail to with the following > > command in the body of your email message: > > > > unsubscribe san-diego-pm-list > > > > If you ever need to get in contact with the owner of the list, > > (if you have trouble unsubscribing, or have questions about the > > list itself) send email to . > > This is the general rule for most mailing lists when you need > > to contact a human. > > -- > Jeff Saenz > jeff@planetoid.net > > > ~sdpm~ > > The posting address is: san-diego-pm-list@hfb.pm.org > > List requests should be sent to: majordomo@hfb.pm.org > > If you ever want to remove yourself from this mailing list, > you can send mail to with the following > command in the body of your email message: > > unsubscribe san-diego-pm-list > > If you ever need to get in contact with the owner of the list, > (if you have trouble unsubscribing, or have questions about the > list itself) send email to . > This is the general rule for most mailing lists when you need > to contact a human. > ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From cabney at cyberpass.net Thu Jun 1 20:15:26 2000 From: cabney at cyberpass.net (C. Abney) Date: Thu Aug 5 00:20:05 2004 Subject: system call exit status In-Reply-To: Message-ID: ~sdpm~ On Thu, 1 Jun 2000, Bobby Kleemann wrote: > DIAGNOSTICS > The exit status (or error level) approximates the exit codes > defined by PKWARE and takes on the following values, except > under VMS: maybe a 'perldoc -f system' while you are about it??? That 1st example given is revealing. CA -- Einstein himself said that God doesn't roll dice. But he was wrong. And in fact, anyone who has played role-playing games knows that God probably had to roll quite a few dice to come up with a character like Einstein. -- Larry Wall C. Abney ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From eugene at securityarchitects.com Thu Jun 1 20:47:01 2000 From: eugene at securityarchitects.com (Eugene Tsyrklevich) Date: Thu Aug 5 00:20:05 2004 Subject: system call exit status In-Reply-To: <3936F0C2.97A6CD4@planetoid.net>; from jeff@planetoid.net on Thu, Jun 01, 2000 at 04:24:50PM -0700 References: <3936F0C2.97A6CD4@planetoid.net> Message-ID: <20000601184701.E9681@securityarchitects.com> ~sdpm~ what do you get when you run the unzip from a command line? On Thu, Jun 01, 2000 at 04:24:50PM -0700, jeff wrote: > ~sdpm~ > How can I decode a non-zero exit status returned from the system > function call? > > I'm trying the following > > my @unzip_system = ('unzip', '-d', $tmp, '-q', "$tmp/file.zip"); > if (system(@unzip_system)) { > carp "system (@unzip_system) failed ($?)"; > system("rm -fr $tmp"); > next; > } > > and getting the error... > > system (unzip -d /tmp/unzip.20763 -q /tmp/unzip.20763/file.zip) failed > (65280) at /prod/newsfeed/bin/get_news line 90 > > What does the number 65280 mean? > > -- > Jeff Saenz > jeff@planetoid.net ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From cabney at cyberpass.net Thu Jun 1 20:59:50 2000 From: cabney at cyberpass.net (C. Abney) Date: Thu Aug 5 00:20:05 2004 Subject: system call exit status In-Reply-To: Message-ID: ~sdpm~ On Thu, 1 Jun 2000, C. Abney wrote: > On Thu, 1 Jun 2000, Bobby Kleemann wrote: > > DIAGNOSTICS > > The exit status (or error level) approximates the exit codes > > defined by PKWARE and takes on the following values, except > > under VMS: > > maybe a 'perldoc -f system' while you are about it??? That 1st example > given is revealing. Say, wasn't there some kind of explanation about this regarding underlying philosophy behind error messages? 'Pessimal' is maximally bad, but in language parlance the error messages generated can be optimal or pessimal in the sense of which result conveys the richest depth of meaning. Most shells follow 'C's lead and choose the pessimal route, conveying the complexity of failure: You can fail in innumerable ways and somewhere is a key to gaining information about the numerical value of your failure. A simple zero (0) as a return value indicates 'no known failure'. Perl breaks tradition with this: zero (0) indicates 'no result'. But lets you succeed with the standard one (1), or with REF, HASH, ARRAY, SCALAR, etc. as a return value. Some operations will even fail (in a way) with a negative (-1) return value. Therefore it can be a point of confusion for the new Perler, doing a system call (to the shell!) returns a pessimal value in an optimal environment. (oh, that wouldn't be my bias showing, not at all...) CA -- Einstein himself said that God doesn't roll dice. But he was wrong. And in fact, anyone who has played role-playing games knows that God probably had to roll quite a few dice to come up with a character like Einstein. -- Larry Wall C. Abney ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From rkleeman at neta.com Mon Jun 5 18:46:35 2000 From: rkleeman at neta.com (Bobby Kleemann) Date: Thu Aug 5 00:20:05 2004 Subject: Python vs Perl (w/ PHP) (fwd) Message-ID: ~sdpm~ PerlMongers, A friend of mine is looking for some knowledge/guidance/experience. Can anyone help? _ _ _ Bobby Kleemann http://www.neta.com/~rkleeman/ ---------- Forwarded message ---------- Date: Mon, 5 Jun 2000 14:53:48 -0700 (PDT) From: Jim Serio Reply-To: linux-ucsd@mib.org To: linux-ucsd@mib.org Subject: Python vs Perl (w/ PHP) Hopefully someone in additon to Bob will have some insight. THere's this guy at work that apparently use to be an engineer at Infoseek and has a Python background. But he now works in Marketing at my company and is leading a new project that I am developer on. My choice is naturally Perl. His role is purely to produce the content where I am to produce the scripting to generate that. To me there is a fine line. He provides an MRD and I provide the solution. Unfortunately he keeps pestering me and my supervisor about how much better Python is. (I just can't see why Python users constantly rip on Perl). I've take a defensive to this which is affecting my work. I'm definately game for learning a new language if my current onoe doesn't offer the same solutions, but to a non-Python user, I thought that Perl and Python were very similar. I took a look at some of the docs on Python's site and it sure does seem that it's the same as Perl, although it does force you to adhear to stricter syntax. I've also read that it's a good beginner language. But _WHAT_ are the differences other than that? I can't see a darn one. There is a mod_python but it seems to be in it's infancy. There is some kind of module/class system but it's nowhere near as comprehensive as CPAN. In my mind it's be more useful to learn PHP since it's compliments Perl more... and has a quiker time to market. I even went as far as telling this prick if he wants to writ ethe scripts he's welcome to join the engineering dept but if he's not than he shouldn't force his beliefs down my throat. Anyway... has anyone gone through this yet? Any helpful insight from both perl/Python/PHP developers would be appreciated. Jim -- Jim Serio - jim@rollercoaster.com Producer, World of Coasters ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From jeff at planetoid.net Mon Jun 5 19:35:42 2000 From: jeff at planetoid.net (jeff) Date: Thu Aug 5 00:20:05 2004 Subject: Python vs Perl (w/ PHP) (fwd) References: Message-ID: <393C475D.34CAD2B5@planetoid.net> ~sdpm~ i know that python gets psuedo compiled into something like java byte code, so you can hide the source. also, i have heard that thread programming might be better or easier in python. Bobby Kleemann wrote: > ~sdpm~ > PerlMongers, > A friend of mine is looking for some > knowledge/guidance/experience. Can anyone help? > > _ _ _ > Bobby Kleemann > http://www.neta.com/~rkleeman/ > > ---------- Forwarded message ---------- > Date: Mon, 5 Jun 2000 14:53:48 -0700 (PDT) > From: Jim Serio > Reply-To: linux-ucsd@mib.org > To: linux-ucsd@mib.org > Subject: Python vs Perl (w/ PHP) > > Hopefully someone in additon to Bob will have some > insight. > > THere's this guy at work that apparently use to > be an engineer at Infoseek and has a Python background. > But he now works in Marketing at my company and is > leading a new project that I am developer on. My > choice is naturally Perl. > > His role is purely to produce the content where I > am to produce the scripting to generate that. To > me there is a fine line. He provides an MRD and I > provide the solution. > > Unfortunately he keeps pestering me and my supervisor > about how much better Python is. (I just can't see > why Python users constantly rip on Perl). I've > take a defensive to this which is affecting my work. > > I'm definately game for learning a new language if > my current onoe doesn't offer the same solutions, but > to a non-Python user, I thought that Perl and Python were > very similar. I took a look at some of the docs on > Python's site and it sure does seem that it's the > same as Perl, although it does force you to adhear > to stricter syntax. I've also read that it's a > good beginner language. > > But _WHAT_ are the differences other than that? I can't > see a darn one. There is a mod_python but it seems to > be in it's infancy. There is some kind of module/class > system but it's nowhere near as comprehensive as CPAN. > > In my mind it's be more useful to learn PHP since it's > compliments Perl more... and has a quiker time to market. > > I even went as far as telling this prick if he wants to > writ ethe scripts he's welcome to join the engineering > dept but if he's not than he shouldn't force his beliefs > down my throat. > > Anyway... has anyone gone through this yet? Any helpful > insight from both perl/Python/PHP developers would be > appreciated. > > Jim > -- > Jim Serio - jim@rollercoaster.com > Producer, World of Coasters > > ~sdpm~ > > The posting address is: san-diego-pm-list@hfb.pm.org > > List requests should be sent to: majordomo@hfb.pm.org > > If you ever want to remove yourself from this mailing list, > you can send mail to with the following > command in the body of your email message: > > unsubscribe san-diego-pm-list > > If you ever need to get in contact with the owner of the list, > (if you have trouble unsubscribing, or have questions about the > list itself) send email to . > This is the general rule for most mailing lists when you need > to contact a human. -- Jeff Saenz jeff@planetoid.net ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From cabney at cyberpass.net Mon Jun 5 20:06:09 2000 From: cabney at cyberpass.net (C. Abney) Date: Thu Aug 5 00:20:05 2004 Subject: Python vs Perl (w/ PHP) (fwd) In-Reply-To: Message-ID: ~sdpm~ On Mon, 5 Jun 2000, Bobby Kleemann wrote: > A friend of mine is looking for some > knowledge/guidance/experience. Can anyone help? Never be closed to another approach. CA -- Einstein himself said that God doesn't roll dice. But he was wrong. And in fact, anyone who has played role-playing games knows that God probably had to roll quite a few dice to come up with a character like Einstein. -- Larry Wall C. Abney ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From comeaujr at sd.conexant.com Wed Jun 7 13:00:11 2000 From: comeaujr at sd.conexant.com (John R. Comeau) Date: Thu Aug 5 00:20:05 2004 Subject: capturing X Windows application in pTk Message-ID: <200006071800.LAA28736@pirr.sd.conexant.com> ~sdpm~ Is it possible to capture the display of an X Windows application in a Perl Tk window? For instance, I'd like to be able to embed an emacs session in a Perl Tk application and have the emacs display (in X Windows mode) be captured in a Perl Tk window. Maybe only a window manager can do this? -- _ _ _ _ _ _ _ _ * * * * * * * * / \ / \ / \ / \ / \ / \ / \ / \ / / / / / / / / | | | | | | | | | | | | | | | | / / / / / / / / \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ * * * * * * * * _ _ _ _ * * * * John Comeau / \ / \ / \ / \ Systems Engineer / / / / | | | | Conexant Systems, Inc | | | | / / / / john.comeau@conexant.com \_/ \_/ \_/ \_/ 858-713-3593 (W) * * * * Como te llamas? _ _ _ _ _ _ _ _ * * * * * * * * / \ / \ / \ / \ / \ / \ / \ / \ / / / / / / / / | | | | | | | | | | | | | | | | / / / / / / / / \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ * * * * * * * * ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From comeaujr at sd.conexant.com Wed Jun 7 13:00:11 2000 From: comeaujr at sd.conexant.com (John R. Comeau) Date: Thu Aug 5 00:20:05 2004 Subject: capturing X Windows application in pTk Message-ID: <200006071800.LAA28736@pirr.sd.conexant.com> ~sdpm~ ~sdpm~ Is it possible to capture the display of an X Windows application in a Perl Tk window? For instance, I'd like to be able to embed an emacs session in a Perl Tk application and have the emacs display (in X Windows mode) be captured in a Perl Tk window. Maybe only a window manager can do this? -- _ _ _ _ _ _ _ _ * * * * * * * * / \ / \ / \ / \ / \ / \ / \ / \ / / / / / / / / | | | | | | | | | | | | | | | | / / / / / / / / \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ * * * * * * * * _ _ _ _ * * * * John Comeau / \ / \ / \ / \ Systems Engineer / / / / | | | | Conexant Systems, Inc | | | | / / / / john.comeau@conexant.com \_/ \_/ \_/ \_/ 858-713-3593 (W) * * * * Como te llamas? _ _ _ _ _ _ _ _ * * * * * * * * / \ / \ / \ / \ / \ / \ / \ / \ / / / / / / / / | | | | | | | | | | | | | | | | / / / / / / / / \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ * * * * * * * * ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From robertl1 at home.com Thu Jun 8 08:26:19 2000 From: robertl1 at home.com (Bob La Quey) Date: Thu Aug 5 00:20:05 2004 Subject: Open Source Perl eCommerce Application Message-ID: <3.0.6.32.20000608062619.01c187d0@mail.dt1.sdca.home.com> ~sdpm~ Just ran across this ... it looks pretty good if you are into this kind of thing. OpenSales AllCommerce is a commerce, content, customer and relationship management system. This high-performance, scalable Internet application is written in Perl and uses a backend database. OpenSales AllCommerce is released under the GPL. http://www.opensales.org/ Bob La Quey ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From comeaujr at sd.conexant.com Fri Jun 9 13:20:46 2000 From: comeaujr at sd.conexant.com (John R. Comeau) Date: Thu Aug 5 00:20:05 2004 Subject: opening pipe to process already running Message-ID: <200006091820.LAA02192@pirr.sd.conexant.com> ~sdpm~ I'm running on SunOS5.5.1, and I'd like to be able to open a pipe to a process that's already running. That is, suppose I have a 'daemon' process that runs all the time. Then periodically another process will run and communicate with the daemon process over a Unix pipe. I don't even know if this is possible in Unix; all the Perl examples I've seen deal with pipes between parent and child processes. However, in my case the processes do not have a parent-child relationship. What I currently have implemented is that the daemon process looks for special files created by the periodic processes. However, this is messy since those files may be left over if one of the processes is killed before it can delete them. I know that you can send a signal to a running process, but how do you open a pipe to it? I guess another possibility is that I could use a FIFO file (named pipe) instead of the normal files I currently have implemented. But still that seems messy. -- John Comeau (john.comeau@conexant.com) 858-713-3593 (W) ------------------------------------------------------- Ich bin gespannt, wie die Ausfuhrung des Planes vonstatten gehen wird I'd love to know how the plan will be carried out ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From comeaujr at sd.conexant.com Fri Jun 9 13:20:46 2000 From: comeaujr at sd.conexant.com (John R. Comeau) Date: Thu Aug 5 00:20:06 2004 Subject: opening pipe to process already running Message-ID: <200006091820.LAA02192@pirr.sd.conexant.com> ~sdpm~ ~sdpm~ I'm running on SunOS5.5.1, and I'd like to be able to open a pipe to a process that's already running. That is, suppose I have a 'daemon' process that runs all the time. Then periodically another process will run and communicate with the daemon process over a Unix pipe. I don't even know if this is possible in Unix; all the Perl examples I've seen deal with pipes between parent and child processes. However, in my case the processes do not have a parent-child relationship. What I currently have implemented is that the daemon process looks for special files created by the periodic processes. However, this is messy since those files may be left over if one of the processes is killed before it can delete them. I know that you can send a signal to a running process, but how do you open a pipe to it? I guess another possibility is that I could use a FIFO file (named pipe) instead of the normal files I currently have implemented. But still that seems messy. -- John Comeau (john.comeau@conexant.com) 858-713-3593 (W) ------------------------------------------------------- Ich bin gespannt, wie die Ausfuhrung des Planes vonstatten gehen wird I'd love to know how the plan will be carried out ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From eugene at securityarchitects.com Fri Jun 9 18:00:51 2000 From: eugene at securityarchitects.com (Eugene Tsyrklevich) Date: Thu Aug 5 00:20:06 2004 Subject: opening pipe to process already running In-Reply-To: <200006091820.LAA02192@pirr.sd.conexant.com>; from comeaujr@sd.conexant.com on Fri, Jun 09, 2000 at 11:20:46AM -0700 References: <200006091820.LAA02192@pirr.sd.conexant.com> Message-ID: <20000609160051.Z9681@securityarchitects.com> ~sdpm~ On Fri, Jun 09, 2000 at 11:20:46AM -0700, John R. Comeau wrote: > ~sdpm~ > I'm running on SunOS5.5.1, and I'd like to be able to open a pipe to a > process that's already running. That is, suppose I have a 'daemon' > process that runs all the time. Then periodically another process > will run and communicate with the daemon process over a Unix pipe. I > don't even know if this is possible in Unix; all the Perl examples > I've seen deal with pipes between parent and child processes. > However, in my case the processes do not have a parent-child > relationship. > What I currently have implemented is that the daemon process looks for > special files created by the periodic processes. However, this is > messy since those files may be left over if one of the processes is > killed before it can delete them. > > I know that you can send a signal to a running process, but how do you > open a pipe to it? > > I guess another possibility is that I could use a FIFO file (named > pipe) instead of the normal files I currently have implemented. But > still that seems messy. if your processes are unrelated than you have to use FIFOs for your pipes IPC see http://www.perl.com/pub/doc/manual/html/pod/perlipc.html for more details my personal favorite is sockets.. another alternative (which is probably the messiest) is shared memory cheers, Eugene Tsyrklevich Security Architects, Inc. ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From rschlientz at yahoo.com Fri Jun 9 19:25:51 2000 From: rschlientz at yahoo.com (Rick Schlientz) Date: Thu Aug 5 00:20:06 2004 Subject: suid cgi? Message-ID: <000701bfd272$6e900460$b70b0a0a@mp3.com> ~sdpm~ What is the best way to allow a secure cgi the same permissions as the user logged into it? I have a perl cgi script running on a secure apache server, with users logged into to server to access the script. What is the best approach - creating a suid script to run with the effective uid of the logged in user, or making the script check the permissions itself. And does anyone have any code samples on how to go about this? Thanks! __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From cabney at cyberpass.net Fri Jun 9 19:57:49 2000 From: cabney at cyberpass.net (C. Abney) Date: Thu Aug 5 00:20:06 2004 Subject: opening pipe to process already running In-Reply-To: <200006091820.LAA02192@pirr.sd.conexant.com> Message-ID: ~sdpm~ On Fri, 9 Jun 2000, John R. Comeau wrote: > I know that you can send a signal to a running process, but how do you > open a pipe to it? > > I guess another possibility is that I could use a FIFO file (named > pipe) instead of the normal files I currently have implemented. But > still that seems messy. If you have source access to the daemon, a named pipe or put a socket on it... perldoc perlipc, and perldoc Socket. CA -- Einstein himself said that God doesn't roll dice. But he was wrong. And in fact, anyone who has played role-playing games knows that God probably had to roll quite a few dice to come up with a character like Einstein. -- Larry Wall C. Abney ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From cabney at cyberpass.net Fri Jun 9 20:01:25 2000 From: cabney at cyberpass.net (C. Abney) Date: Thu Aug 5 00:20:06 2004 Subject: suid cgi? In-Reply-To: <000701bfd272$6e900460$b70b0a0a@mp3.com> Message-ID: ~sdpm~ On Fri, 9 Jun 2000, Rick Schlientz wrote: > What is the best way to allow a secure cgi the same permissions as the user > logged into it? Some systems won't allow you to do suid scripts... they are considered too unsafe. But apache has a module that allows you to do directory based suid perms setting. It comes with the base distribution and is turned off by default: a compiler option. Details here: http://www.apache.org/docs/suexec.html CA -- Einstein himself said that God doesn't roll dice. But he was wrong. And in fact, anyone who has played role-playing games knows that God probably had to roll quite a few dice to come up with a character like Einstein. -- Larry Wall C. Abney ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From eugene at securityarchitects.com Fri Jun 9 20:13:11 2000 From: eugene at securityarchitects.com (Eugene Tsyrklevich) Date: Thu Aug 5 00:20:06 2004 Subject: suid cgi? In-Reply-To: <000701bfd272$6e900460$b70b0a0a@mp3.com>; from rschlientz@yahoo.com on Fri, Jun 09, 2000 at 05:25:51PM -0700 References: <000701bfd272$6e900460$b70b0a0a@mp3.com> Message-ID: <20000609181311.B9681@securityarchitects.com> ~sdpm~ http://www.unixtools.org/cgiwrap/ cheers, Eugene Tsyrklevich Security Architects, Inc. On Fri, Jun 09, 2000 at 05:25:51PM -0700, Rick Schlientz wrote: > ~sdpm~ > What is the best way to allow a secure cgi the same permissions as the user > logged into it? > > I have a perl cgi script running on a secure apache server, with users > logged into to server to access the script. What is the best approach - > creating a suid script to run with the effective uid of the logged in user, > or making the script check the permissions itself. > > And does anyone have any code samples on how to go about this? > > Thanks! ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From comeaujr at sd.conexant.com Sun Jun 11 16:39:20 2000 From: comeaujr at sd.conexant.com (John R. Comeau) Date: Thu Aug 5 00:20:06 2004 Subject: four-argument version of select Message-ID: <200006112139.OAA23160@pirr.sd.conexant.com> ~sdpm~ I'm trying to use the four-argument select function. I'm having trouble getting the timeout feature to work as I expected. For instance, I have the following code to read from a FIFO (named pipe): open FIFO, $fifo or die "can't read $fifo: $!"; my $rin = ''; vec ($rin, fileno (FIFO), 1) = 1; my $nfound = select ($rin, undef, undef, 1); I expected that it will wait for one second to see if the FIFO had data available to read and then timeout and continue execution. But it never times out. Instead of timing out, I see it wait at the select call until data is written to the fifo. For those of you with accounts on apsadmin (SDPM's) computer, I have the cases I've tried in the following files: prw-rw-rw- 1 comeau users 0 Jun 11 14:11 /home/comeau/fifo -rw-r--r-- 1 comeau users 6 Jun 10 17:57 /home/comeau/hello -rwxr-xr-x 1 comeau users 465 Jun 10 18:06 /home/comeau/select.pl -rwxr-xr-x 1 comeau users 465 Jun 10 18:06 /home/comeau/select2.pl -rwxr-xr-x 1 comeau users 52 Jun 11 14:14 /home/comeau/select3.pl What I did to test these out is ran select.pl (or select2.pl) in one shell, and in another shell, ran cat < hello > fifo I find that select2.pl waits for data to be written to fifo before continuing. I gave world write permissions to the file /home/comeau/fifo, so everyone should be able to duplicate my experiment. I've been unsuccessful with the FIFO with the following versions of Perl: version 5.005_03 built for PA-RISC1.1 version 5.005_02 built for sun4-solaris v5.6.0 built for sun4-solaris However I did get the simple case to timeout as expected: select undef, undef, undef, 4.75; This is equivalent to a sleep for 4.75 seconds and is done in select3.pl. -- John Comeau (john.comeau@conexant.com) 858-713-3593 (W) ------------------------------------------------------- Er hatte sich entschieden, ihre schmutzige Wasche in aller Offentlichkeit zu waschen He had decided to wash their dirty linen in public ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From cabney at cyberpass.net Mon Jun 12 12:39:58 2000 From: cabney at cyberpass.net (C. Abney) Date: Thu Aug 5 00:20:06 2004 Subject: four-argument version of select In-Reply-To: <200006112139.OAA23160@pirr.sd.conexant.com> Message-ID: ~sdpm~ On Sun, 11 Jun 2000, John R. Comeau wrote: > However I did get the simple case to timeout as > expected: > > select undef, undef, undef, 4.75; I'm going to make an assumption, so please flame me as an ass if I'm wrong. Are you sure you want to use 'vec' and 'select'??? That's a lot of junk just to read a hello, world pipe. Are you using vec because you thought it was related to a 4 argument select in some way? I don't really understand what they're doing: maybe you do. I get this from perlipc: Signal handling is also used for timeouts in Unix, While safely protected within an eval{} block, you set a signal handler to trap alarm signals and then schedule to have one delivered to you in some number of seconds. Then try your blocking operation, clearing the alarm when it's done but not before you've exited your eval{} block. If it goes off, you'll use die() to jump out of the block, much as you might using longjmp() or throw() in other languages. And a warning in perlfunc "alarm": If you want to use alarm() to time out a system call you need to use an eval()/die() pair. You can't rely on the alarm causing the system call to fail with $! set to EINTR because Perl sets up signal handlers to restart system calls on some systems. Yeah right, whatever. I got this code to do what (I think) you want: ->8------------------------------------------- #! /usr/bin/perl -w use strict; my ( $rin, $time ); $time = 4; eval { local $SIG{ALRM} = sub { die "no output from FIFO in $time seconds"; }; # I'm making another assumption, here: local $/ = 'asdfakjdfajhdflkajhdflkafhlakf;afja'; alarm $time; open FIFO, "< fifo" or die "ugh: $!"; $rin = ; close FIFO; alarm 0; }; if ($@ and $@ =~ /no output from FIFO/) { die } print STDOUT "Got:>>" . $rin . "<<\n"; ->8------------------------------------------- TEST1: tty1:$ ./select.plx tty0:$ cat hello milk tty0:$ cat hello > fifo (tty1) tty1:$ ./select.plx Got:>>milk << tty1:$ TEST2: tty1:$ ./select.plx no output from FIFO in 4 seconds at ./select.plx line 9. ...propagated at ./select.plx line 18 tty1:$ HTH, Take Care, CA -- Einstein himself said that God doesn't roll dice. But he was wrong. And in fact, anyone who has played role-playing games knows that God probably had to roll quite a few dice to come up with a character like Einstein. -- Larry Wall C. Abney ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From comeaujr at sd.conexant.com Sun Jun 11 20:06:02 2000 From: comeaujr at sd.conexant.com (John R. Comeau) Date: Thu Aug 5 00:20:06 2004 Subject: four-argument version of select In-Reply-To: (cabney@cyberpass.net) References: Message-ID: <200006120106.SAA27224@pirr.sd.conexant.com> ~sdpm~ >>>>> "C" == C Abney writes: C> Are you sure you want to use 'vec' and 'select'??? That's a C> lot of junk just to read a hello, world pipe. Are you using C> vec because you thought it was related to a 4 argument select C> in some way? It seemed like 'select' was a direct way of doing what I wanted. It says that it's use determine whether your file descriptors are ready for I/O. The reason I used 'vec' is just because that's what they do in the example in Camel. C> I got this code to do what (I think) you want: Yeah, I'd considered doing that eval/die thing. That has caused me some problems in the past though. One time I brought some code to the SDPM meeting that used eval/die. That code would consitently generate a segmentation fault. I can dig up that example if anyone's interested; a lot of new people have joined since I showed that example. Thanks for the sample code though, C. -- John Comeau (john.comeau@conexant.com) 858-713-3593 (W) ------------------------------------------------------- Nach dieser Enttusch wollte sie sich einen Rausch ansaufen. After this disappointment she wanted to get plastered. ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From cabney at cyberpass.net Mon Jun 12 15:36:02 2000 From: cabney at cyberpass.net (C. Abney) Date: Thu Aug 5 00:20:06 2004 Subject: four-argument version of select In-Reply-To: <200006120106.SAA27224@pirr.sd.conexant.com> Message-ID: ~sdpm~ On Sun, 11 Jun 2000, John R. Comeau wrote: > It seemed like 'select' was a direct way of doing what I wanted. It > says that it's use determine whether your file descriptors are ready > for I/O. The reason I used 'vec' is just because that's what they do > in the example in Camel. select in the example given (it looks like a similar one to what's in the perldocs -- I don't have the Camel book so I'm guessing) is bound to STDIN/STDOUT/STDERR, not to a descriptor opened with a system call. That's why no special structures are needed to catch a signal. select should work fine with your FIFO if you treat it as open was in that example I gave. just use: select (FIFO, undef, undef, 4.0). If you want to be more direct, use IO::Socket (it has a io_socket_timeout variable). Cheers, CA -- Einstein himself said that God doesn't roll dice. But he was wrong. And in fact, anyone who has played role-playing games knows that God probably had to roll quite a few dice to come up with a character like Einstein. -- Larry Wall C. Abney ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From cabney at cyberpass.net Mon Jun 12 18:26:08 2000 From: cabney at cyberpass.net (C. Abney) Date: Thu Aug 5 00:20:06 2004 Subject: (correction) Re: four-argument version of select In-Reply-To: Message-ID: ~sdpm~ On Mon, 12 Jun 2000, C. Abney wrote: > [eval block snipped] > } > if ($@ and $@ =~ /no output from FIFO/) { die } > > print STDOUT "Got:>>" . $rin . "<<\n"; er, that doesn't catch a failed open (and has some garbage...) better: [eval block snipped] } if ($@) { die } print "Got:>>$rin<<\n"; CA -- Einstein himself said that God doesn't roll dice. But he was wrong. And in fact, anyone who has played role-playing games knows that God probably had to roll quite a few dice to come up with a character like Einstein. -- Larry Wall C. Abney ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From canetguy at home.com Thu Jun 15 10:03:18 2000 From: canetguy at home.com (Garrett Casey) Date: Thu Aug 5 00:20:06 2004 Subject: Schedule Change Message-ID: <200006150803180907.17D0005F@mail> ~sdpm~ Everyone, For the last couple weeks I have been talking with MP3.com about our June meeting. It seems that because of a couple events going on next week (The Summit at UCSD and Usenix), few of their engineers will be able to attend/speak on June 21st. The folks at MP3.com have requested that we push the meeting back by one week. Rescheduling our meeting for June 28th, will allow more of the MP3.com engineers to attend and speak. I am sorry for this inconvenience and for all those who have RSVPed, please send me another message confirming your attendance on the new date, June 28th, 7:00pm. Again, our June meeting has been rescheduled for June 28th at 7:00pm at MP3.com. I was assured that there will be no further changes. I will be emailing the group in the next few days with information about exactly what will be discussed by MP3.com at the meeting along with detailed driving directions and any other vital information. -Garrett Casey 858 720 1789 http://SanDiego.pm.org ps. Here is a little more information about MP3.com: > > We use Intel based hardware systems that are custom built by a > > company in San Diego. They are dual processor 500Mhz (or better) > > with 512MB ram, 36GB scsi drive. > > > > We run Linux, kernel 2.2.12 or 2.2.14 and Solaris 2.6. > > > > MySQL is our primary database for all of the live site. We use > > Oracle and MS SQL in certain specific busines applications. > > > > We use Apache exclusively for serving all pages on our site and > > perl is the primary programming language and C is used for > > special purposes where high performance is required. Mod_perl is > > used for most cgi's. ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From comeaujr at sd.conexant.com Thu Jun 15 15:08:07 2000 From: comeaujr at sd.conexant.com (John R. Comeau) Date: Thu Aug 5 00:20:06 2004 Subject: nested alarm signals Message-ID: <200006152008.NAA10867@pirr.sd.conexant.com> ~sdpm~ I've been using an alarm signal in my large Perl project to spawn processes that I want to happen in the background. In the process of debugging this code, I found some unexpected behavior. It seems that, when a new process is launched within the alarm signal handler, the new process can't respond to an alarm signal itself. I wrote a simple test case consisting of two files. If you're on SanDieog.pm.org, they are located in my home directory: /home/comeau/alarm_die.pl /home/comeau/call_alarm_die.pl Here are the two files, alarm_die.pl followed by call_alarm_die.pl -------------------- cut here -------------------- #!/usr/bin/perl $SIG{ALRM} = sub {die 'ALARM'}; alarm 10; ; -------------------- cut here -------------------- #!/usr/bin/perl $SIG{ALRM} = sub {warn "calling alarm_die.pl\n"; `alarm_die.pl`}; # $SIG{ALRM}->(); alarm 10; ; -------------------- cut here -------------------- When I run alarm_die.pl by itself, I get the following results: $ alarm_die.pl ALARM at alarm_die.pl line 3. alarm_die.pl waits for STDIN but dies when the alarm occurs. But when I run call_alarm_die.pl, I get results I didn't expect: $ call_alarm_die.pl calling alarm_die.pl Neither alarm_die.pl nor call_alarm_die.pl because alarm_die.pl is waiting for STDIN. It somewhow does not respond to the alarm it sets (or doesn't successfully set the alarm). I've never heard of this behavior. Is there some kind of Unix rule that you can't have nested alarm signals? Even if there was such a rule for a single process, it seems odd to me that the child process for alarm_die.pl would be affected by the fact that it was run from within an alarm signal handler. When alarm_die.pl is spawned from outside a signal handler, by uncommenting line 5 of call_alarm_die.pl, alarm_die.pl runs as expected; it dies from the alarm. Sorry that this is more of a Unix question than Perl, but it is kind of Perl, isn't it? I spent several hours last night going crazy before I isolated this problem to these nested alarm signals. -- John Comeau (john.comeau@conexant.com) 858-713-3593 (W) ------------------------------------------------------- Jeder Fallschirmspringer muss der Gefahr ins Auge blicken. Every parchutist has to face the danger. ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From chaz at devastator.extern.ucsd.edu Thu Jun 15 16:55:35 2000 From: chaz at devastator.extern.ucsd.edu (The Chazman) Date: Thu Aug 5 00:20:06 2004 Subject: nested alarm signals (fwd) Message-ID: <200006152155.OAA06568@devastator.extern.ucsd.edu> ~sdpm~ > Is there some kind of Unix rule that you can't have nested alarm > signals? Yes, that's exactly the case. The signal being handled is always blocked while its signal handler is running. > Even if there was such a rule for a single process, it > seems odd to me that the child process for alarm_die.pl would be > affected by the fact that it was run from within an alarm signal > handler. There are a large number of system calls that are unsafe to make while inside a signal handler. Any attempt to call these may result in incorrect, undefined, or otherwise disastrous behavior. I was looking for a complete list, but failed to find one. However, I'm certain that among them are: fork, exec, read, and write. That means no spawning other processes, and no file or terminal I/O while in a signal handler. Frankly, I'm amazed your example executed as far as it did. Keep your signal handlers short and simple. > Sorry that this is more of a Unix question than Perl, but it is kind > of Perl, isn't it? Sorta. Sometimes Perl makes it hard to see exactly what system calls are happening when. In most cases, that contributes to its appeal, but now is definitely not one of those cases. Carl N Miller chaz@devastator.extern.ucsd.edu ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From comeaujr at sd.conexant.com Thu Jun 15 17:11:52 2000 From: comeaujr at sd.conexant.com (John R. Comeau) Date: Thu Aug 5 00:20:06 2004 Subject: nested alarm signals (fwd) In-Reply-To: <200006152155.OAA06568@devastator.extern.ucsd.edu> (message from The Chazman on Thu, 15 Jun 2000 14:55:35 -0700) References: <200006152155.OAA06568@devastator.extern.ucsd.edu> Message-ID: <200006152211.PAA11593@pirr.sd.conexant.com> ~sdpm~ Carl> There are a large number of system calls that are unsafe to Carl> make while inside a signal handler. Any attempt to call Carl> these may result in incorrect, undefined, or otherwise Carl> disastrous behavior. I was looking for a complete list, but Carl> failed to find one. However, I'm certain that among them Carl> are: fork, exec, read, and write. Carl> That means no spawning other processes, and no file or Carl> terminal I/O while in a signal handler. Frankly, I'm amazed This is really bad news for me. I have a pretty large application that's based on forking child processes from an alarm signal handler. It's working pretty well except for this issue of generating another alarm. Given that my example is able to spawn the new process, I wonder what it is about that spawned process that indicates that it can't respond to (or set?) its own alarm. That is, is there some way that one can look at the output of 'ps' to see that this spawned process is running in some kind of special state (e.g. it's running from a signal handler)? If one can't fork the child processes in a signal handler, how does one write a multi-threaded application? My approach was that I would spawn these child processes from the alarm signal handler so that they would be started even if the program was waiting for user input from STDIN. Like I said, it seems to be working fairly well. But I don't want to write something that won't work on a slightly different flavor of Unix or that might not work when the OS is in some slightly different state. I guess that I should spawn a single child process (outside of an signal handler) and then communicate with that child periodically. How is the idle callback handled in pTk? Wouldn't that be some kind of alarm? If so, do the same restrictions apply? -- John Comeau (john.comeau@conexant.com) 858-713-3593 (W) ------------------------------------------------------- Ihr neuer Verehrer liest ihr jeden Wunsch von den Augen ab. Her new admirer anticipates her every wish. ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From rkleeman at neta.com Thu Jun 15 17:39:26 2000 From: rkleeman at neta.com (Bobby Kleemann) Date: Thu Aug 5 00:20:06 2004 Subject: nested alarm signals (fwd) In-Reply-To: <200006152211.PAA11593@pirr.sd.conexant.com> Message-ID: ~sdpm~ On Thu, 15 Jun 2000, John R. Comeau wrote: > If one can't fork the child processes in a signal handler, how does > one write a multi-threaded application? A slight confusion here I should clear up: multi-threaded means that several "processes" are running in the same global memory space, but at different times. If you really want a threaded perl app, you should build perl with threads and use that interface. WHat you are doing here is a multi-process app that (I think) is trying to use signals as an IPC mechanism, which can be done better with pipes or shared memory. > My approach was that I would > spawn these child processes from the alarm signal handler so that they > would be started even if the program was waiting for user input from > STDIN. Why not spawn helper programs before you look for input? Or why not just set a flag in the sig handler and in whatever loop you have around the STDIN loop launch your alternate process. use vars qw($ALARM_SIGNALED); $SIG{ALRM} = sub { $ALARM_SIGNALED++ } while () { if ($ALARM_SIGNALED) { $ALARM_SIGNALED = 0; launch_other_proc(); } ... Continue processing STDIN. } Careful with this one though, because I'm not sure how the read of STDIN will react to being interrupted (you may loose your data on certain systems). > Like I said, it seems to be working fairly well. But I don't > want to write something that won't work on a slightly different flavor > of Unix or that might not work when the OS is in some slightly > different state. > > I guess that I should spawn a single child process (outside of an > signal handler) and then communicate with that child periodically. Yes, definitely spawn outside the signal handler. > How is the idle callback handled in pTk? Wouldn't that be some kind > of alarm? If so, do the same restrictions apply? Hopefully someone with pTk knowledge will know. _ _ _ Bobby Kleemann http://www.neta.com/~rkleeman/ ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From chaz at devastator.extern.ucsd.edu Thu Jun 15 18:19:53 2000 From: chaz at devastator.extern.ucsd.edu (The Chazman) Date: Thu Aug 5 00:20:06 2004 Subject: nested alarm signals (fwd) Message-ID: <200006152319.QAA06651@devastator.extern.ucsd.edu> ~sdpm~ > Carl> There are a large number of system calls that are unsafe to > Carl> make while inside a signal handler. Any attempt to call > Carl> these may result in incorrect, undefined, or otherwise > Carl> disastrous behavior. I was looking for a complete list, but > Carl> failed to find one. However, I'm certain that among them > Carl> are: fork, exec, read, and write. > > Carl> That means no spawning other processes, and no file or > Carl> terminal I/O while in a signal handler. Frankly, I'm amazed > > This is really bad news for me. I have a pretty large application > that's based on forking child processes from an alarm signal handler. > It's working pretty well except for this issue of generating another > alarm. Well, I hesitate to do this, but here's the quick and super-dirty, sweep-it-all-under-the-rug answer. Manually unblock SIGALRM in your handler right before you try to spawn another process. Hopefully that will allow the new process to receive new alarm signals. I'm guessing that it can't because SIGALRM is blocked while inside the handler, and processes inherit their parent's blocked signal mask when spawned. This is a VERY BAD IDEA because fork(), exec(), and many others are still not guaranteed to work from inside a signal handler. And while you may be getting lucky on one implementation of Unix, it may all fall to pieces on another. Even different revisions of the same flavor of Unix may differ in how they react to unsafe system calls inside signal handlers. There are just no guarantees, period. > Given that my example is able to spawn the new process, I wonder what > it is about that spawned process that indicates that it can't respond > to (or set?) its own alarm. That is, is there some way that one can > look at the output of 'ps' to see that this spawned process is running > in some kind of special state (e.g. it's running from a signal > handler)? I'm guessing it's blocked. BSD's and Linux's ps can tell you what the blocked signal mask of a process is. SysV-style ps can't. If you're running on a Linux box, "ps s". On BSD, "ps o sigmask". Interpreting what gets printed out is left as an exercise for the reader. :-) > If one can't fork the child processes in a signal handler, how does > one write a multi-threaded application? One typically doesn't do any thread manipulations from inside signal handlers. Spawn and terminate threads and processes from mainline code. > My approach was that I would > spawn these child processes from the alarm signal handler so that they > would be started even if the program was waiting for user input from > STDIN. Like I said, it seems to be working fairly well. But I don't > want to write something that won't work on a slightly different flavor > of Unix or that might not work when the OS is in some slightly > different state. If I got into this situation, I'd start using C instead of Perl. You're starting to need the fine-grained control that C forces on you. Here's what I'd do in C: 1) Register my SIGALRM handler such that interrupted system calls are not restarted. 2) Find all system calls (particularly ones that like to block like read()) in any part of code that might be running when a SIGALRM comes in, usually this means everywhere except things that only happen at startup and shutdown of the program. 3) Check all such system calls for failure, and in particular, failure with the EINTR error code. 4) When one fails with EINTR, check global variable flags that have presumably been set by the signal handler, and take whatever out-of-band action you had been taking in your old signal handler. After the out-of-band action (spawning off a new processs maybe) is complete, reissue the system call that got interrupted. I don't know how to do this in Perl. I'm not even sure it's possible to do in Perl (though it may be -- I'm not Perl guru enough to say either way). But the "right" (TM) way to do it, is take the steps I've outlined above, and have your actual signal handler functions just set global variable flags for the mainline code to interpret. > How is the idle callback handled in pTk? Wouldn't that be some kind > of alarm? If so, do the same restrictions apply? I'm not familiar with pTk; I couldn't say. Carl N Miller chaz@devastator.extern.ucsd.edu ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From chaz at devastator.extern.ucsd.edu Thu Jun 15 18:34:44 2000 From: chaz at devastator.extern.ucsd.edu (The Chazman) Date: Thu Aug 5 00:20:06 2004 Subject: nested alarm signals (fwd) Message-ID: <200006152334.QAA06665@devastator.extern.ucsd.edu> ~sdpm~ > Why not spawn helper programs before you look for input? Or why not just > set a flag in the sig handler and in whatever loop you have around the > STDIN loop launch your alternate process. That's the ticket. I highly recommend that approach. > use vars qw($ALARM_SIGNALED); > $SIG{ALRM} = sub { $ALARM_SIGNALED++ } > > while () { > if ($ALARM_SIGNALED) { > $ALARM_SIGNALED = 0; > launch_other_proc(); > } > ... Continue processing STDIN. > } This illustrates the basic idea. But as I said in my other post, you need to take care of a few little details that Perl hides from you. One is to make sure your alarm handler get registered so as not to restart an interrupted system call by itself. The other is to differentiate a failure of the read() in the while loop from reading a valid EOF condition. I'm not sure how to do this in Perl, but that's the key point that's missing. If it's a real EOF, you want to break out of the loop. If it's an error and the error is EINTR, you want to check the alarm signalled variable, launch_other_proc() and reset the variable if it was set, then drop back into the loop with another read from STDIN. (i.e. you really want a "next;" statement after the call to launch_other_proc(), inside the if-then) Carl N Miller chaz@devastator.extern.ucsd.edu ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From eugene at securityarchitects.com Thu Jun 15 21:52:06 2000 From: eugene at securityarchitects.com (Eugene Tsyrklevich) Date: Thu Aug 5 00:20:06 2004 Subject: nested alarm signals (fwd) In-Reply-To: <200006152155.OAA06568@devastator.extern.ucsd.edu>; from chaz@devastator.extern.ucsd.edu on Thu, Jun 15, 2000 at 02:55:35PM -0700 References: <200006152155.OAA06568@devastator.extern.ucsd.edu> Message-ID: <20000615195206.B26851@securityarchitects.com> ~sdpm~ > > Even if there was such a rule for a single process, it > > seems odd to me that the child process for alarm_die.pl would be > > affected by the fact that it was run from within an alarm signal > > handler. > > There are a large number of system calls that are unsafe to make while > inside a signal handler. Any attempt to call these may result in > incorrect, undefined, or otherwise disastrous behavior. I was looking > for a complete list, but failed to find one. However, I'm certain that > among them are: fork, exec, read, and write. POSIX.1 requires all of the above functions to be reentrant. Thus you can use them in your signal handlers. see 'Advanced Programming in the Unix Environment' page 278 Also check out http://www.perl.com/pub/doc/manual/html/pod/perlfunc/alarm.html cheers. ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From canetguy at home.com Mon Jun 26 16:53:52 2000 From: canetguy at home.com (Garrett Casey) Date: Thu Aug 5 00:20:06 2004 Subject: Perl Mongers Meeting Message-ID: <200006261453520692.34033C6F@mail> ~sdpm~ This is a copy of the message posted on Usenet: comp.lang.perl.misc If you are planning on attending the meeting on Wed, PLEASE RSVP NOW! Send your RSVP to canetguy@home.com or adms1@cts.com Open Invitation: MP3.com http://www.mp3.com will be hosting the San Diego Perl Mongers meeting being held on JUNE 28, 2000 at 7:00pm. Any Perl programmer in the San Diego area is welcome to attend. MP3.com is nearly a billion-dollar online corporation that uses Perl as it's primary programming language. Their site has hundreds of thousands of unique visitors a day. They use Intel based hardware systems with duel 500mhz (or better) processors, 512 megs of RAM, running Linux and Solaris. MySQL is their primary database for all the live sites. They use Oracle and MS SQL in certain specific business applications. MP3.com uses Apache exclusively for serving all pages on their site. Again, Perl is their primary programming language and C is used for very specialize purposes. Mod_perl is used for most CGI's. At the meeting, MP3.com engineers will be speaking and answering questions about how they use Perl, Mod_perl, Apache and MySQL in such a robust environment. It should be very enlightening. Food and drinks will be provided along with cool MP3.com prizes. If you would like to attend the meeting, please RSVP Garrett Casey at canetguy@home.com or adms1@cts.com The San Diego Perl Mongers http://SanDiego.pm.org is going strong with 60+ members. All Perl programmers in San Diego are welcome to join us. All members get free shell account on our server and have access to our FRIENDLY mailing list. -Garrett Casey canetguy@home.com adms1@cts.com ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From cabney at cyberpass.net Mon Jun 26 21:11:02 2000 From: cabney at cyberpass.net (C. Abney) Date: Thu Aug 5 00:20:06 2004 Subject: cold fusion vs. Perl (Tom never did this one ) In-Reply-To: <200006261453520692.34033C6F@mail> Message-ID: ~sdpm~ er, wierd question. I know someone that uses cold fusion at work and seems to've run up against a wall: he finds himself churning out scripts four plus times the length of the file he's rendering. He wants to know if there's a better way. He's pretty much constrained to NT + IIS. I try to explain Perl's concision, its idioms... any clues on how I might drive it home? I'm not a CF programmer, maybe one of you has more insight into how I might illustrate Perl's advantages over CF's embedded directives. -- Mighty Mouse is a cartoon. Superman is a real guy. No way a cartoon could beat up a real guy! -- Teddy C. Abney ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From joe at artlung.com Tue Jun 27 01:56:12 2000 From: joe at artlung.com (Joe Crawford) Date: Thu Aug 5 00:20:06 2004 Subject: Python vs. Perl Article Message-ID: <39584FFD.321DB2D9@artlung.com> ~sdpm~ Seems like a few weeks back someone was asking about Perl vs. Python comparisons. This article might be a good answer to that in the future. http://www.linuxprogramming.com/news/news_story.php3?ltsn=2000-06-26-001-03-UU-UU - Joe -- Joe Crawford | web designer + developer services-for-hire | http://joecrawford.com/ personal-site | http://www.artlung.com/ dev-mailing-list-for-san-diego-CA-USA | http://www.websandiego.org/ ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From canetguy at home.com Tue Jun 27 09:28:32 2000 From: canetguy at home.com (Garrett Casey) Date: Thu Aug 5 00:20:06 2004 Subject: No subject Message-ID: <200006270728320577.3791E0FC@mail> ~sdpm~ For those attending the MP3.com meeting tomorrow, directions have been added to our web site. http://SanDiego.pm.org -Garrett ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From jeff at planetoid.net Tue Jun 27 19:27:49 2000 From: jeff at planetoid.net (jeff) Date: Thu Aug 5 00:20:06 2004 Subject: mod perl book Message-ID: <39594684.A0A59DB@planetoid.net> ~sdpm~ Can anyone recommend a good book or web resources for learning mod_perl? -- Jeff Saenz jeff@planetoid.net ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From rkleeman at neta.com Tue Jun 27 19:44:10 2000 From: rkleeman at neta.com (Bobby Kleemann) Date: Thu Aug 5 00:20:06 2004 Subject: mod perl book In-Reply-To: <39594684.A0A59DB@planetoid.net> Message-ID: ~sdpm~ I've been using the OReilly Book "Writing Apache Modules with Perl and C" (the Eagle book) and have been relatively pleased with it. Add to that the documentation you can usually find laying all over the web, this group, and you should be in good shape. _ _ _ Bobby Kleemann http://www.neta.com/~rkleeman/ On Tue, 27 Jun 2000, jeff wrote: > ~sdpm~ > Can anyone recommend a good book or web resources for learning mod_perl? > > > > -- > Jeff Saenz > jeff@planetoid.net > > > ~sdpm~ > > The posting address is: san-diego-pm-list@hfb.pm.org > > List requests should be sent to: majordomo@hfb.pm.org > > If you ever want to remove yourself from this mailing list, > you can send mail to with the following > command in the body of your email message: > > unsubscribe san-diego-pm-list > > If you ever need to get in contact with the owner of the list, > (if you have trouble unsubscribing, or have questions about the > list itself) send email to . > This is the general rule for most mailing lists when you need > to contact a human. > ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From canetguy at home.com Wed Jun 28 17:47:36 2000 From: canetguy at home.com (Garrett Casey) Date: Thu Aug 5 00:20:06 2004 Subject: Directions to MP3.com Message-ID: <200006281547360141.3E812408@mail> ~sdpm~ A map and driving directions on at http://SanDiego.pm.org. We will be going into the 4790 building. The easiest way is to take the 805 to La Jolla Village Drive....it automatically puts you going West. Turn right at the first light...Towne Centre Drive. Take another right at the second light....Eastgate Mall. The address is 4790 Eastgate Mall You will see building 4780 from the street...the main building is behind that. Parking is free See you all there!! -Garrett ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. From canetguy at home.com Wed Jun 28 17:47:36 2000 From: canetguy at home.com (Garrett Casey) Date: Thu Aug 5 00:20:06 2004 Subject: Directions to MP3.com Message-ID: <200006281547360141.3E812408@mail> ~sdpm~ ~sdpm~ A map and driving directions on at http://SanDiego.pm.org. We will be going into the 4790 building. The easiest way is to take the 805 to La Jolla Village Drive....it automatically puts you going West. Turn right at the first light...Towne Centre Drive. Take another right at the second light....Eastgate Mall. The address is 4790 Eastgate Mall You will see building 4780 from the street...the main building is behind that. Parking is free See you all there!! -Garrett ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. ~sdpm~ The posting address is: san-diego-pm-list@hfb.pm.org List requests should be sent to: majordomo@hfb.pm.org If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe san-diego-pm-list If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human.