[19801] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 1996 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Oct 24 06:10:27 2001

Date: Wed, 24 Oct 2001 03:10:12 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <1003918211-v10-i1996@ruby.oce.orst.edu>
Content-Type: text

Perl-Users Digest           Wed, 24 Oct 2001     Volume: 10 Number: 1996

Today's topics:
        Strange behavior w/ SIGALRM and POSIX::sigaction- was ( <joe+usenet@sunstarsys.com>
    Re: Style: error/exception handling? <please@no.spam>
    Re: Tool to help understand unknown Perl source code (Per Strömgren)
    Re: Tool to help understand unknown Perl source code <bart.lateur@skynet.be>
    Re: Using a remote file with a Perl script <Tassilo.Parseval@post.rwth-aachen.de>
    Re: Using a remote file with a Perl script <hafner@augusta.de>
    Re: Webpage Passwords <dha@panix.com>
    Re: What the **** is WRONG with this!? <dha@panix.com>
    Re: What the **** is WRONG with this!? <hafner@augusta.de>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: 24 Oct 2001 04:00:12 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Strange behavior w/ SIGALRM and POSIX::sigaction- was (Re: alarm and put a timeout on a perl program an its shell childs ?)
Message-Id: <m3r8rt5uyb.fsf_-_@mumonkan.sunstarsys.com>

garry@ifr.zvolve.net (Garry Williams) writes:

> Unfortunately, the perlvar manual page seems to be in error on the
> solution.  The code given there to avoid setting SA_RESTART will not
> execute properly.  An error message is printed when the signal is
> delivered because the POSIX::SigAction interface cannot find the
> signal handler subroutine.  The POSIX manual page clears up the
> problem by mentioning the POSIX::SigAction expects the fully-qualified
> name of a sub which is a signal-handler.  The perlvar manual page
> suggestion passes POSIX::SigAction a code reference instead.  
> 

I have a related question that I haven't been able to solve.
The following code does hostname lookups via gethostbyname()
which is wrapped in a 2 second alarm:

  % cat try.pl
  #!/usr/bin/perl -wln
  use POSIX qw/:signal_h/;

  sub alrm {die "timeout"}

  eval { 
    sigaction(SIGALRM, POSIX::SigAction->new("main::alrm"));   
    alarm 2; 
    $addr = gethostbyname $_; 
    alarm 0;
  };

  if ($@) { print "$_ => $@" }
  else {
    $addr = $addr ? join '.', unpack('C4', $addr) : "BZZT"; 
    print "$_ => $addr";
  }
  __END__

Now the problem is that once the alarm is triggered, 
*all* subsequent gethostbyname lookups are failing.  
Here's a linux stack trace for the first few timeouts
("www.rgee.com" is the first one here):

  % cat data
  www.microsoft.com
  www.aol.com
  www.rgee.com
  www.aol.com
  www.microsoft.com

  % ./try.pl data
  www.microsoft.com => 207.46.230.220
  www.aol.com => 64.12.149.24
  www.rgee.com => timeout at /tmp/try.pl line 4, <> line 3.

  www.aol.com => timeout at /tmp/try.pl line 4, <> line 4.

  www.microsoft.com => timeout at /tmp/try.pl line 4, <> line 5.

  % strace ./try.pl data
  ...
  send(5, "<\233\1\0\0\1\0\0\0\0\0\0\3www\4rgee\3com\0\0\1\0\1", 30, 0) = 30
  gettimeofday({1003909154, 795857}, NULL) = 0
  poll([{fd=5, events=POLLIN}], 1, 5000)  = -1 EINTR (Interrupted system call)
  --- SIGALRM (Alarm clock) ---
  rt_sigprocmask(SIG_SETMASK, [RT_0], NULL, 8) = 0
  write(1, "www.rgee.com => timeout at /tmp/"...,) = 58
  write(1, "\n", 1
  )                       = 1
  rt_sigaction(SIGALRM, {0x40065f70, [], SA_RESTART|0x4000000}, 
                        {0x40065f70, [], 0x4000000}, 8) = 0
  rt_sigaction(SIGALRM, {0x40065f70, [], 0x4000000}, NULL, 8) = 0
  alarm(2)                                = 0
  rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
  rt_sigsuspend([] <unfinished ...>
  --- SIGALRM (Alarm clock) ---
  <... rt_sigsuspend resumed> )           = -1 EINTR (Interrupted system call)
  rt_sigprocmask(SIG_SETMASK, [RT_0], NULL, 8) = 0
  write(1, "www.aol.com => timeout at /tmp/t"...,) = 57
  write(1, "\n", 1
  )                       = 1
  rt_sigaction(SIGALRM, {0x40065f70, [], SA_RESTART|0x4000000}, 
                        {0x40065f70, [], 0x4000000}, 8) = 0
  rt_sigaction(SIGALRM, {0x40065f70, [], 0x4000000}, NULL, 8) = 0
  alarm(2)                                = 0
  rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
  rt_sigsuspend([] <unfinished ...>
  --- SIGALRM (Alarm clock) ---
  ...


Does somebody understand what is going on here?

-- 
Joe Schaefer    "Language is a city to the building of which every human being
                                      brought a stone."
                                               --Mark Twain



------------------------------

Date: Wed, 24 Oct 2001 09:58:36 GMT
From: Andrew Cady <please@no.spam>
Subject: Re: Style: error/exception handling?
Message-Id: <87y9m12wg6.fsf@homer.cghm>

Dave Carmean <dlc-usenet@halibut.com> writes:

[...]

> 1: Take the BOFH route and not report in such detail,

Fine, if you don't need it, but then if you don't need it why ask the
question?

> 2: Use a global "nonabortive failure message" thingy like
>     *NA_Failure and have the calling code deal with it if the
>     function returns a null, but die/croak right in the function if
>     the error is "really bad". (Glob is because I can see uses for a
>     string, an array, or even a hash where the equivalent of ERRNO
>     is the key and the value is a severity level.)

That's fine.  A similar (IMO better) approach to avoid the use of
globals is to rename your functions, not_valid_rfc_..., return false
for valid, and return a string indicating error type for invalid.
That's what I'd do.  However, the global is almost as good, and
certainly acceptable.  (Infinitely better than dieing).

die($err)       if ($err = not_valid($someurl));  # very clean, IMO
return($err)    if ($err = not_valid($someurl));

> 3: Don't bother with the bare return on error: just throw
>     an exception on just about every error and count on having to
>     call it in an eval {} for all but very simple hacks.  But then
>     this requires me to do a match on $@ to see if it's one I know
>     how to handle; I worry about scaleability of this.

No.  Errors that can be handled locally should be handled locally.
It's debatable whether this is even an error (rather, this *isn't* an
error).  You don't need to break the control flow here, you just need
to return multiple pieces of data (i.e. a boolean value, and an error
type value).  And really, nothing is less idiomatic than never
returning false from a boolean function.  Use exceptions to mean
"false" and your code will not be worth using to anyone but you.

> 4: Always return a list, with the first element being an
>     error code.  Kind of breaks the "function or die" paradigm, and
>     kind of makes prototyping useless since they don't behave like
>     built-ins any longer.

You wouldn't *have* to do that with a list.  You could do something
vaguely C-like:

(($err = check_rfc23902309($someurl)) == RFCOK) or die($err);
(($err = check_rfc23902309($someurl)) == RFCOK) or return($err);

Which is ugly, but it's still better than eval.

> 5: Find some kind of module that allows me to throw "typed"
>     exceptions. (Which I think I understand, but remember, I'm not
>     really a programmer; I'm also trying to minimize use of
>     non-perl-dist modules.)

I don't understand, why do you need typed exceptions?  Why can't you
just die("rfc230923 error: error category: specific error")?  Anyway
don't use exceptions here.  A false return from a boolean function is
not exceptional.


------------------------------

Date: Wed, 24 Oct 2001 08:06:12 GMT
From: Per.Stromgren@ein.obliterate.ericsson.se (Per Strömgren)
Subject: Re: Tool to help understand unknown Perl source code
Message-Id: <9r5rh5$86s$1@newstoo.ericsson.se>


Me:

>> Do you know of any program of this sort or have other ideas how to
>> solve the problem with the non-existent documentation? I suppose this
>> does not happen in your company, but perhaps you know anyway.

miko@idocs.com (Miko O'Sullivan) answers:

>I've found the Perltidy tool invaluable in working with other people's
>messy code.  It reworks the code into a consistent and neat format.  I
>find that clean formatting solves at least half the problem of reading
>messy code.

Thanks, Miko, but I do use perltidy. My main main problem is some
rather spaghetti-like coding habits i see. I could perhaps just whip
something up with perl, would I? Like looking for procedure
definitions and calls and just list them. Any volunteers?

>You can get Perltidy at http://perltidy.sourceforge.net/

>-miko



Per Stromgren
Managing Web Editor
Ericsson Infotech AB



------------------------------

Date: Wed, 24 Oct 2001 09:59:11 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: Tool to help understand unknown Perl source code
Message-Id: <fv2dtt82j0jii04dm75i7uls3l53tpufd4@4ax.com>

Per Strömgren wrote:

>My main main problem is some
>rather spaghetti-like coding habits i see. I could perhaps just whip
>something up with perl, would I? Like looking for procedure
>definitions and calls and just list them. Any volunteers?

Get the help of Perl's own parser. Look into B::Xref, part of the
standard distribution. Use it on your script from the command line like:

	perl -MO=Xref yourscript.pl

For postprocessing, I think the -r option is best, you'll get a spaces
delimited table (not exactly fixed column widths, but close).

	perl -MO=Xref,-r yourscript.pl
	

It looks to me like there's a big bug in it. This is the version that
came with 5.6.1. For example, for a sub with name "usage" that is
defined on lines 1174-1220 of the script, and used on line 99, I can
only see entries in the output for "subdef" and "subused", both on line
99. It smells like only one hash entry has been used per sub. I should
check this out.

-- 
	Bart.


------------------------------

Date: Wed, 24 Oct 2001 08:12:23 +0200
From: Tassilo von Parseval <Tassilo.Parseval@post.rwth-aachen.de>
Subject: Re: Using a remote file with a Perl script
Message-Id: <3BD65BC7.10202@post.rwth-aachen.de>

Marc Bissonnette wrote:

[...]

>>>Specifically, I was thinking of writing a CGI running on a client's
>>>server 
>>>
>>A CGI running on a client's server? I don't quite understand that.
>>
> 
> A client as in a customer, or as in a server other than my own :)
> 
> I am just curious to know if this is a viable option; ideally:
> 
> Write CGI that performs X on server A. This CGI would make a call to remote 
> server B for a subroutine that performs Y and returns a result to server A.


You are probably looking for something like SOAP::Lite, well, SOAP in 
general. But be aware that SOAP itself is a client-server-architecture, 
that means that there must be a SOAP-server running on the other side 
that sort of exports tunctions via this protocol.


Tassilo


-- 
$a=[(74,116)];$b=[($a->[1]-1,$a->[1]++,0x20)];$c=[(97,110)];$d=[($c->
[1]+1,$b->[1],"her")];for(@{[$a,$b,$c,$d]}){for(@{$_}){$_=~/\d+/?print
(chr($_)):print;}}$c=sub{$l=shift;[(0x20+$l-1,0x50,0x65,0x73-0x01,108
),(0x20,0x68,0x61,)]};print(map{chr($_)}@{($c->(1))});$h={a=>33*3,b=>
10**2+7,c=>"1"."0"."1",d=>0162};@h=sort(keys(%$h));for(@h){print(chr(
ord(chr($h->{$_}))))};



------------------------------

Date: 24 Oct 2001 09:22:01 +0200
From: Walter Hafner <hafner@augusta.de>
Subject: Re: Using a remote file with a Perl script
Message-Id: <qdfn12ha4fa.fsf@www.ibexnet.de>

dragnet@internalysis.com (Marc Bissonnette) writes:

> I am just curious to know if this is a viable option; ideally:
> 
> Write CGI that performs X on server A. This CGI would make a call to remote 
> server B for a subroutine that performs Y and returns a result to server A.

For simple code snippets i do the following:

NFS mount the "shared" directory with your files from all the "client"
machines. Or, if NFS isn't an option or not desired, distribute the
"shared" directory via "rsync" to all "client" machines every few
minutes ("rsync" has very low overhead!).

For more complex tasks i wrote a TCP daemon using a very simple
protocol:

1) submit your query in a single line in the format <TASK>,<ARGUMENTS>
2) listen on the port for the answer.

This works really well. I use it e.g. to verify ZIP codes and telephone
area codes in Web forms, to check valid web accounts etc.

The code to access the daemon is distributed by "rsync", btw :-)

With this approach it's easy to access all the tasks language
independent: I use the same interface to the daemon from PHP and a Java
servlet, too. :-)

-Walter


------------------------------

Date: 24 Oct 2001 04:53:58 GMT
From: "David H. Adler" <dha@panix.com>
Subject: Re: Webpage Passwords
Message-Id: <slrn9tcib6.hou.dha@panix2.panix.com>

In article <9r4ge5$25ss$1@salmon.maths.tcd.ie>, Brian Foley wrote:
> 
> But dont trust me, Im just a random bloke on a newsgroup.

Which, of course, is probably the best advice one can take from a random
bloke on a newsgroup.  :-)

dha

-- 
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
It's not important how many people I've killed.  What's important is
how I get along with those who are still alive.
    - Jimmy "The Tulip" Tedeschi


------------------------------

Date: 24 Oct 2001 04:56:46 GMT
From: "David H. Adler" <dha@panix.com>
Subject: Re: What the **** is WRONG with this!?
Message-Id: <slrn9tcige.hou.dha@panix2.panix.com>

In article <Xns9143D27FBA15615497002270367234@24.2.10.79>, Graham W.
Boyes wrote:

> Aren't newsgroups great? If you need a computer hardware question or
> networking question answered, feel free to visit
> 24hoursupport.helpdesk.

And, *boy*, don't we wish there was such a hierarchy for us to send
people to!  :-)

dha

-- 
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
It didn't bother me before there was a for modifier, and now that
there is one, it still doesn't bother me.  I'm just not very easy to
bother.       - Larry Wall


------------------------------

Date: 24 Oct 2001 09:00:26 +0200
From: Walter Hafner <hafner@augusta.de>
Subject: Re: What the **** is WRONG with this!?
Message-Id: <qdfr8rta5f9.fsf@www.ibexnet.de>

usenet@jasonkohles.com (Jason Kohles) writes:

> On Tue, 23 Oct 2001 14:59:00 GMT, Graham W. Boyes wrote:
> >I swear I did this and it worked yesterday.  I'm using a CGI script to make 
> >a new directory inside the directory that's inside the directory the script 
> >is in.
> >
> >system("mkd /home/XXXX/data/forum/data/test");
> >
> >I am new to Linux (as you will probably guess before you fall out of your 
> >chair laughing) so please tell me where I have gone wrong.
> >Thanks
> >
> 'mkd' is a dos command, you may have an alias that maps 'mkd' to 'mkdir', but
> those aliases are not accessible when you use system().  I think you meant
> 'mkdir'.

Try to use Perls 'mkdir'. I didn't look whether 'mkdir' creates
intermediate, nonexisting directories for you. Check that
beforehand. Linux' "mkdir" _doesn't_ create those directories by
default. If you insist in using system(), use "mkdir -p".

-Walter



------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc.  For subscription or unsubscription requests, send
the single line:

	subscribe perl-users
or:
	unsubscribe perl-users

to almanac@ruby.oce.orst.edu.  

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.

For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V10 Issue 1996
***************************************


home help back first fref pref prev next nref lref last post