From andrew at sweger.net Mon May 2 12:33:12 2005 From: andrew at sweger.net (Andrew Sweger) Date: Mon May 2 12:33:23 2005 Subject: SPUG: The Bekman Incident, Seattle, August 2005 Message-ID: Can you all find a way to keep Stas busy and happy for three days from August 8th throught 10th? Otherwise he would only be here on Saturday the 6th for a couple hours. I know he'll be visiting one company for a few hours at least (a heavy user of mod_perl who will also be helping to cover his travel/accomodation expenses) and spending an evening giving a presentation to local user groups (primarily SPUG oriented, but public as usual). Note that this will not be the regular SPUG meeting which would still follow on the 16th. Are there any other heavy mod_perl shops that would like to have him visit and get personal with your team and code? (I can't believe no one is jumping on this). Would anyone like to coordinate a local hike? The weather should be fabulous and Stas is very interested in taking a closer look at the Puget Sound area. I'm sure there will be a lunch/dinner or two scheduled. I just need confirmation on whether three days of Stas in Seattle is: 1) not enough 2) just right 3) too much Speak up! -- Andrew B. Sweger -- The great thing about multitasking is that several things can go wrong at once. From andrew at sweger.net Mon May 2 22:50:34 2005 From: andrew at sweger.net (Andrew Sweger) Date: Mon May 2 22:50:48 2005 Subject: SPUG: Bekman, Seattle, August 2005 In-Reply-To: Message-ID: Make that August 6th though 8th. Tickets are being purchased now. -- Andrew B. Sweger -- The great thing about multitasking is that several things can go wrong at once. From jerry.gay at gmail.com Tue May 3 09:19:35 2005 From: jerry.gay at gmail.com (jerry gay) Date: Tue May 3 09:19:47 2005 Subject: SPUG: Bekman, Seattle, August 2005 In-Reply-To: References: Message-ID: <1d9a3f4005050309197758f71e@mail.gmail.com> that's great news, i'll be glad to learn more about mod_perl from a pro. are stas's costs fully covered, or should we be chipping in? On 5/2/05, Andrew Sweger wrote: > Make that August 6th though 8th. Tickets are being purchased now. > > -- > Andrew B. Sweger -- The great thing about multitasking is that several > things can go wrong at once. > > _____________________________________________________________ > Seattle Perl Users Group Mailing List > POST TO: spug-list@pm.org > SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list > MEETINGS: 3rd Tuesdays, Location: Amazon.com Pac-Med > WEB PAGE: http://seattleperl.org/ > From james at banshee.com Tue May 3 11:36:16 2005 From: james at banshee.com (James Moore) Date: Tue May 3 11:36:55 2005 Subject: SPUG: Is there a call that will break into the debugger? Message-ID: <200505031717.j43HHYrP008431@server2.banshee.com> Assuming that you've started your code under the debugger, is there a call it can make that will act as a breakpoint? - James From cmeyer at helvella.org Tue May 3 12:00:12 2005 From: cmeyer at helvella.org (Colin Meyer) Date: Tue May 3 12:00:24 2005 Subject: SPUG: Is there a call that will break into the debugger? In-Reply-To: <200505031717.j43HHYrP008431@server2.banshee.com> References: <200505031717.j43HHYrP008431@server2.banshee.com> Message-ID: <20050503190012.GI8032@funpox.helvella.org> On Tue, May 03, 2005 at 11:36:16AM -0700, James Moore wrote: > Assuming that you've started your code under the debugger, is there a call > it can make that will act as a breakpoint? You can set the special variable $DB::signal to a true value. -Colin. For example: > cat debug_test.pl #!/usr/local/bin/perl for (1..10) { $DB::signal = 1 if $_ == 3; print "$_\n"; } > perl -d debug_test.pl Loading DB routines from perl5db.pl version 1.28 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(debug_test.pl:3): for (1..10) { DB<1> r 1 2 main::(debug_test.pl:5): print "$_\n"; DB<1> n 3 main::(debug_test.pl:4): $DB::signal = 1 if $_ == 3; DB<1> n main::(debug_test.pl:5): print "$_\n"; DB<1> n 4 > > - James > > _____________________________________________________________ > Seattle Perl Users Group Mailing List > POST TO: spug-list@pm.org > SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list > MEETINGS: 3rd Tuesdays, Location: Amazon.com Pac-Med > WEB PAGE: http://seattleperl.org/ From bill at celestial.com Tue May 3 12:01:01 2005 From: bill at celestial.com (Bill Campbell) Date: Tue May 3 12:00:28 2005 Subject: SPUG: Is there a call that will break into the debugger? In-Reply-To: <200505031717.j43HHYrP008431@server2.banshee.com> References: <200505031717.j43HHYrP008431@server2.banshee.com> Message-ID: <20050503190101.GA8026@alexis.mi.celestial.com> On Tue, May 03, 2005, James Moore wrote: >Assuming that you've started your code under the debugger, is there a call >it can make that will act as a breakpoint? I've used ``ddd'', an X-windows debugger, with perl. It allows one to insert breakpoints, and is pretty easy to use. Bill -- INTERNET: bill@Celestial.COM Bill Campbell; Celestial Systems, Inc. UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ Suppose you were an idiot. And suppose you were a member of Congress. But I repeat myself. -- Mark Twain From michaelpalba at yahoo.com Tue May 3 15:27:33 2005 From: michaelpalba at yahoo.com (Mike Alba) Date: Tue May 3 15:27:44 2005 Subject: SPUG: Perl Question? Message-ID: <20050503222733.92179.qmail@web52710.mail.yahoo.com> Hi, I have a question regarding perl performance. I have batch file that executes the same perl program a few times but with different parameters. In other words there are different operations being performed, sql reports are generated from the database, files are moved around, files are emailled, etc. This batch runs every 15 minutes and occasionally there seems to be performance problems. The thinking was that maybe some of the perl calls are bumping into each other. For instance a database call may be taking longer then expected. Is there a way I can monitor this? When I have tried to duplicate this it seems that each perl call isnt made until the previous one finishes, from the batch file. Am I incorrect here and there might be other factors at play as far as why performance issues are occuring? Any tools available that I can use to monitor each running perl call? Also since it only happens intermittently I guess I am going to have to capture a lot of data? Thanks in advance for your help!!! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tallpeak at hotmail.com Tue May 3 16:10:03 2005 From: tallpeak at hotmail.com (Aaron W. West) Date: Tue May 3 16:10:20 2005 Subject: SPUG: Perl Question? In-Reply-To: <20050503222733.92179.qmail@web52710.mail.yahoo.com> Message-ID: This feels like about a dozen questions, many of them not asked directly. It's hard to know where to start. You didn't say what performance problems you were experiencing. I would say to begin with, in the design and testing phase, it would be good to get a better understanding of the behavior of your system through better unit testing. That is, try each script, determine how long it "typically" runs. But maybe the runs vary widely. However, at this point, you could log the start and stop times of each execution of each command, along with the start time of the batch file. You could use some sort of mutex or database-level lock or file locking to prevent the execution of two concurrent instances of the same script with the same arguments, if that is determined to be problematic. Intent locks (flock) may not work across a network share, I understand. Database locks might be the best. I suspect (but have no knowledge) that with database activity and email occurring, there is a good deal of time spent waiting for I/O. If the issue is one of latency, and CPU usage and memory consumption are low, there may be no problem with executing multiple perl interpreters concurrently, eg: script1 arg1 & script1 arg2 & script1 arg3 .. as long as these instances of the script don't have any big contention problems with a resource, and have no dependencies upon each other. However, if one of the three instances takes over 15 minutes and the other 2 take only a few seconds, this won't buy you much. You might try ODBC tracing or other means of identifying performance problems with any database calls you may be doing. Check the documentation for your database, DBI, and the drivers you are using (eg. DBD::ODBC, DBD::Sybase, DBD::Oracle, etc.) -----Original Message----- From: spug-list-bounces@pm.org [mailto:spug-list-bounces@pm.org] On Behalf Of Mike Alba Sent: Tuesday, May 03, 2005 3:28 PM To: spug-list@pm.org Subject: SPUG: Perl Question? Hi, I have a question regarding perl performance. I have batch file that executes the same perl program a few times but with different parameters. In other words there are different operations being performed, sql reports are generated from the database, files are moved around, files are emailled, etc. This batch runs every 15 minutes and occasionally there seems to be performance problems. The thinking was that maybe some of the perl calls are bumping into each other. For instance a database call may be taking longer then expected. Is there a way I can monitor this? When I have tried to duplicate this it seems that each perl call isnt made until the previous one finishes, from the batch file. Am I incorrect here and there might be other factors at play as far as why performance issues are occuring? Any tools available that I can use to monitor each running perl call? Also since it only happens intermittently I guess I am going to have to capture a lot of data? Thanks in advance for your help!!! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _____________________________________________________________ Seattle Perl Users Group Mailing List POST TO: spug-list@pm.org SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list MEETINGS: 3rd Tuesdays, Location: Amazon.com Pac-Med WEB PAGE: http://seattleperl.org/ From jobs-noreply at seattleperl.org Tue May 3 17:07:30 2005 From: jobs-noreply at seattleperl.org (SPUG Jobs) Date: Tue May 3 17:07:44 2005 Subject: SPUG: JOB: Six Apart, San Francisco Message-ID: ____________________________________________________________________ | This isn't exactly local, but I realize there are many folks on | this list who are not necessarily tied to Puget Sound. The Six | Apart folks are great people and seem to foster brilliance amongst | peers. Good people, not evil. | | -Andrew Sweger Six Apart, makers of weblog software and services for individuals, organizations and businesses, headquartered in San Francisco, is seeking several talented people to join their team. Six Apart is responsible for Movable Type (the premier weblog publishing platform for businesses, organizations, developers, and web designers), TypePad (a powerful, hosted weblogging service), and LiveJournal (one of the web's largest online communities, organized around personal journals). [1] - Software Engineer - LiveJournal [2] - Summer Interns [3] - Software Engineer [4] - and others... [1] - Software Engineer - LiveJournal ------------------------------- Terms: Salaried Employee with benefits (Medical, Vision, Dental and Vacation) Hours: Full Time Location: On site (San Francisco, CA) Department: Engineering Reports To: CTO Details: http://www.sixapart.com/about/jobs#software_engineer_-_livejournal Six Apart (http://www.sixapart.com/), the weblogging software and services company behind LiveJournal, Movable Type and TypePad, is looking for a skilled and motivated engineer to work with us in building the massive, high-performance, open-source LiveJournal service. You will have the chance to work on software that's used by millions, in one of the fastest growing industries, and with very sharp colleagues. On top of all that, we're located just blocks from the ball park in the SOMA neighborhood of San Francisco, close to Cal Train, Muni, and the freeways. The ideal candidate will have the following characteristics: - Ability to learn. Candidate must show they can adapt to the rapidly changing technology landscape. - Ability to communicate. Candidate must show that they can effectively express ideas and opinions. - Mature technical ability. Candidate must understand how the web works from a low to a high level. Candidate must also understand how quality software is designed and constructed. We want you to think as much as you code. - Initiative: Candidate must recognize that great ideas are only as good as the people who are willing to seize the day and transform concepts into realities. - Flexibility. Candidate must be comfortable with the pace of a small-sized company. Other required skills: - Four year degree or equivalent industry experience. - Previous experience developing web applications, preferably for a high volume web site based on open source technologies. - Understanding and experience with object-oriented design and coding. - Experience using Perl with Apache. - Understanding of relational database concepts and SQL, preferably with experience working with MySQL specifically. - Knowledge of basic Software Engineering concepts: development models, testing, and documentation. Pluses: - Knowledge of Six Apart's products and services. - Experience with weblogs and weblog software, especially Movable Type. - Expert Perl programming experience including: Perl web applications under Apache and mod_perl, Perl modules, Perl OOP extensions. - Other Languages: Python, Ruby, PHP, C, C++ - Experience in engineering content management systems. - Technologies: XML, Web Services and XML-RPC; SMS/MMS; - Internationalization; Search systems and concepts. Please apply with cover letter (plain text) and resume to jobs@sixapart.com. The subject line MUST include: "Job: Software Engineer - LiveJournal." Also include links to previous work, CPAN modules, contributions to open source projects, etc., as well as salary expectations. [2] - Summer Interns -------------------- Terms: Summer Interns Hours: Full Time Onsite: Yes (San Francisco, CA) Details: http://www.sixapart.com/about/jobs#summer_interns Six Apart (http://www.sixapart.com/), the company behind the Movable Type and TypePad weblogging systems/services is looking for a handful of talented summer Interns to work with us in building, designing and marketing the next generation of weblogging software. You will work on a global team to build software used by hundreds of thousands of individuals and businesses. 1 - 2 individuals with savvy web development skills. Candidates must have prior experience in Perl and be comfortable with knowledge of basic Software Engineering concepts: development models, testing, and documentation. The ideal candidates will have the following characteristics: - Ability to learn. Candidate must show they can adapt to the rapidly changing technology landscape. - Ability to communicate. Candidate must show that they can express ideas with elegance and flair. - Mature technical ability. Candidate must understand how the web works from a low to a high level. Candidate must also understand how quality software is designed and constructed. We want you to think as much as you code. - Flexibility. Candidate must be comfortable with the pace of a small-sized company. Please apply immediately with resume to jobs@sixapart.com. The subject line MUST include: "Job: Summer Intern." Live interviews will be conducted the week of May 9, 2005. [3] - Software Engineer ----------------------- Terms: Salaried Employee with benefits (Medical, Vision, Dental and Vacation) Hours: Full Time Onsite: Yes (San Francisco Bay Area, CA) Department: Engineering Reports To: CTO Details: http://www.sixapart.com/about/jobs#software_engineer Six Apart (http://www.sixapart.com/), the company behind the Movable Type and TypePad weblogging systems/services, is looking for some skilled engineers to work with us in building the next generation of weblogging software. You will work on a global team to build software used by hundreds of thousands of individuals and businesses. The ideal candidate will have the following characteristics: - Ability to learn. Candidate must show they can adapt to the rapidly changing technology landscape. - Ability to communicate. Candidate must show that they can express ideas with elegance and flair. - Mature technical ability. Candidate must understand how the web works from a low to a high level. Candidate must also understand how quality software is designed and constructed. We want you to think as much as you code. - Flexibility. Candidate must be comfortable with the pace of a small-sized company. Other required skills: - Four year degree or equivalent industry experience. - Previous experience developing web applications, preferably for a high volume web site. - Understanding and experience with object-oriented design and coding. - Experience using Perl with Apache. - Understanding of relational database concepts and SQL. - Knowledge of basic Software Engineering concepts: development models, testing, and documentation. Pluses: - Knowledge of Six Apart's products and services. - Experience with weblogs and weblog software, especially Movable Type. - Expert Perl programming experience including: Perl web applications under Apache and mod_perl, Perl modules, Perl OOP extensions - Other Languages: Python, Ruby, PHP, C, C++ - Experience in engineering content management systems. - Technologies: XML, Web Services and XML-RPC; SMS/MMS; - Internationalization; Search systems and concepts. Please apply with cover letter (plain text) and resume to jobs@sixapart.com. The subject line MUST include: "Job: Software Engineer." Also include links to previous work, CPAN modules, contributions to open source projects, etc. as well as salary expectations. [4] - and others... ------------------- Details: http://www.sixapart.com/about/jobs From rick.croote at philips.com Tue May 3 17:31:02 2005 From: rick.croote at philips.com (Rick Croote) Date: Tue May 3 17:32:13 2005 Subject: SPUG: Perl Question? In-Reply-To: <20050503222733.92179.qmail@web52710.mail.yahoo.com> Message-ID: I agree with Aaron response, but I would make a very simple statement and solution. Repeatedly running things at 15 minute intervals, when that may extend past 15 minutes just isn't a good idea. Simply modify the batch file with a simple locking mechanism that says if a flagfile exist, do not start, and if it doesn't exist, create the flagfile and continue with your process, and finally remove the flagfile at the end. In this way you will never fall into at least the quicksand, I'm sure others are waiting though. This will automatically push emailed reports to be every 30 minutes, or longer, if the 15 minute interval is too short. Then, if you are not getting your reports often enough, you can then at least look into why that is, but at least your 15 minute cycle will not be part of the problem. --- Rick Croote Software Engineer Environment and Tools Team Philips Medical Systems Bothell, WA Rick.Croote@Philips.com Phone: 425-487-7834 Mike Alba Sent by: spug-list-bounces@pm.org 05/03/2005 03:27 PM To: spug-list@pm.org cc: (bcc: Rick Croote/ATL-BTL/MS/PHILIPS) Subject: SPUG: Perl Question? Classification: Hi, I have a question regarding perl performance. I have batch file that executes the same perl program a few times but with different parameters. In other words there are different operations being performed, sql reports are generated from the database, files are moved around, files are emailled, etc. This batch runs every 15 minutes and occasionally there seems to be performance problems. The thinking was that maybe some of the perl calls are bumping into each other. For instance a database call may be taking longer then expected. Is there a way I can monitor this? When I have tried to duplicate this it seems that each perl call isnt made until the previous one finishes, from the batch file. Am I incorrect here and there might be other factors at play as far as why performance issues are occuring? Any tools available that I can use to monitor each running perl call? Also since it only happens intermittently I guess I am going to have to capture a lot of data? Thanks in advance for your help!!! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _____________________________________________________________ Seattle Perl Users Group Mailing List POST TO: spug-list@pm.org SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list MEETINGS: 3rd Tuesdays, Location: Amazon.com Pac-Med WEB PAGE: http://seattleperl.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/spug-list/attachments/20050503/03cbbe46/attachment.htm From andrew at sweger.net Wed May 4 08:54:50 2005 From: andrew at sweger.net (Andrew Sweger) Date: Wed May 4 08:55:12 2005 Subject: SPUG: Stas Bekman, Seattle, August 2005 Message-ID: The Seattle Perl Users Group is pleased to announce[0] that Stas Bekman[1] of mod_perl[2] fame will be visiting Seattle from 6 August to 8 August. He will be giving a public presentation on mod_perl the evening of 8 August. There will be opportunities for folks to meet Stas and talk to him during several activities planned throughout the weekend. Hitting the ball out of the park for us is WhitePages.com[3], your single best source for finding and managing contact information on the Internet and the leading independent provider of online directory assistance services has graciously offered to help cover the cost of Stas' visit. WhitePages.com handles nearly nine million page views per day by utilizing mod_perl, the persistent Perl engine inside Apache. A warm Thank You from all SPUGgers to WhitePages.com Inc. for helping us make this happen. Further announcements, including details of specific events, will be made in July. Information will be added to a web page[4] as it becomes available. [0] - standard disclaimers apply, entropy happens [1] - http://stason.org/ [2] - http://perl.apache.org/ [3] - http://whitepages.com/ (I'll bet you guessed that one) [4] - http://seattleperl.org/event/20050808_stas_bekman.html From kevin-spug at fink.com Wed May 4 09:10:53 2005 From: kevin-spug at fink.com (Kevin Fink) Date: Wed May 4 09:11:32 2005 Subject: SPUG: Is there a call that will break into the debugger? In-Reply-To: <20050503190012.GI8032@funpox.helvella.org> References: <200505031717.j43HHYrP008431@server2.banshee.com> <20050503190012.GI8032@funpox.helvella.org> Message-ID: I always use $DB::single rather than $DB::signal, but both seem to work. Does anyone know what the differences between the two are? The man page is a bit ambiguous on the issue... Kevin On Tue, 3 May 2005, Colin Meyer wrote: > On Tue, May 03, 2005 at 11:36:16AM -0700, James Moore wrote: >> Assuming that you've started your code under the debugger, is there a call >> it can make that will act as a breakpoint? > > You can set the special variable $DB::signal to a true value. From dleonard at dleonard.net Wed May 4 09:36:17 2005 From: dleonard at dleonard.net (dleonard@dleonard.net) Date: Wed May 4 09:36:37 2005 Subject: SPUG: Perl Question? In-Reply-To: Message-ID: As someone who has been rewriting code that uses lockfiles to determine whether it should launch I have to say this it definitely not an optimal way of doing things. If a mount becomes unavailable, the filesystem becomes read-only, or a user or other process modifies the filesystem, this design breaks down. I would recommend instead querying the process table for other processes running as $0. -- On Tue, 3 May 2005, Rick Croote wrote: > I agree with Aaron response, but I would make a very simple statement and > solution. Repeatedly running things at 15 minute intervals, when that may > extend past 15 minutes just isn't a good idea. Simply modify the batch > file with a simple locking mechanism that says if a flagfile exist, do not > start, and if it doesn't exist, create the flagfile and continue with your > process, and finally remove the flagfile at the end. In this way you will > never fall into at least the quicksand, I'm sure others are waiting > though. This will automatically push emailed reports to be every 30 > minutes, or longer, if the 15 minute interval is too short. Then, if you > are not getting your reports often enough, you can then at least look into > why that is, but at least your 15 minute cycle will not be part of the > problem. > > --- > Rick Croote > Software Engineer > Environment and Tools Team > Philips Medical Systems > Bothell, WA > Rick.Croote@Philips.com > Phone: 425-487-7834 > > > > > > > > > > > Mike Alba > Sent by: > spug-list-bounces@pm.org > 05/03/2005 03:27 PM > > To: spug-list@pm.org > cc: (bcc: Rick Croote/ATL-BTL/MS/PHILIPS) > Subject: SPUG: Perl Question? > Classification: > > > > > Hi, > > I have a question regarding perl performance. > I have batch file that executes the same perl > program a few times but with different parameters. > In other words there are different operations > being performed, sql reports are generated from > the database, files are moved around, files are > emailled, etc. This batch runs every 15 minutes > and occasionally there seems to be performance > problems. The thinking was that maybe some of the > perl calls are bumping into each other. For instance > a database call may be taking longer then expected. > Is there a way I can monitor this? When I have > tried to duplicate this it seems that each perl > call isnt made until the previous one finishes, > from the batch file. Am I incorrect here and > there might be other factors at play as far as > why performance issues are occuring? Any tools > available that I can use to monitor each running > perl call? Also since it only happens intermittently > I guess I am going to have to capture a lot of data? > > Thanks in advance for your help!!! > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _____________________________________________________________ > Seattle Perl Users Group Mailing List > POST TO: spug-list@pm.org > SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list > MEETINGS: 3rd Tuesdays, Location: Amazon.com Pac-Med > WEB PAGE: http://seattleperl.org/ > > From andrew at sweger.net Wed May 4 09:44:54 2005 From: andrew at sweger.net (Andrew Sweger) Date: Wed May 4 09:45:06 2005 Subject: SPUG: Calling all Amazon.com employees Message-ID: I need an Amazon.com employee (preferably working out of the HQ) to volunteer to act as SPUG's liaison (schedule the meeting room, notify security, escort guests to the conference room on meeting nights, make sure we don't trash the place, escort everyone out, etc.). Fame, glory, and maybe even a free cookie or two can be yours. Please contact me immediately. Thanks. -- Andrew B. Sweger -- The great thing about multitasking is that several things can go wrong at once. From cmeyer at helvella.org Wed May 4 10:23:12 2005 From: cmeyer at helvella.org (Colin Meyer) Date: Wed May 4 10:23:38 2005 Subject: SPUG: Is there a call that will break into the debugger? In-Reply-To: References: <200505031717.j43HHYrP008431@server2.banshee.com> <20050503190012.GI8032@funpox.helvella.org> Message-ID: <20050504172312.GC15855@funpox.helvella.org> On Wed, May 04, 2005 at 09:10:53AM -0700, Kevin Fink wrote: > I always use $DB::single rather than $DB::signal, but both seem to work. > Does anyone know what the differences between the two are? The man page > is a bit ambiguous on the issue... Yeah, ambiguous to be sure. From 'perldoc DB': $DB::single Single-step flag. Will be true if the API will stop at the next statement. $DB::signal Signal flag. Will be set to a true value if a signal was caught. Clients may check for this flag to abort time-consum- ing operations. This is written for the perspective of programmers of "clients", which are debugging frontends. It seems like setting $DB::single may be more appropriate. Debugging front ends would expect $DB::signal to be set after ^C is pressed, or a signal is sent to the program via some other mechanism. -Colin. From jerry.gay at gmail.com Wed May 4 10:50:00 2005 From: jerry.gay at gmail.com (jerry gay) Date: Wed May 4 10:50:16 2005 Subject: SPUG: Perl Question? In-Reply-To: References: Message-ID: <1d9a3f40050504105028e70c4e@mail.gmail.com> you might instead consider one of my favorite locking hacks: #!/usr/bin/perl ... ## ensure only one instance of this script is running INIT { flock DATA => LOCK_EX | LOCK_NB or exit 1 } ...