[comp.lang.perl] Default actions for %SIG

victor@irt.watson.ibm.com (Victor Miller) (03/05/91)

Where is there a list of the default actions for %SIG?  I couldn't
find it either in "Programming Perl" or in the man page.
			Victor
--
			Victor S. Miller
			Vnet and Bitnet:  VICTOR at WATSON
			Internet: victor@ibm.com
			IBM, TJ Watson Research Center

lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (03/06/91)

In article <VICTOR.91Mar4155214@irt.watson.ibm.com> victor@ibm.com writes:
: Where is there a list of the default actions for %SIG?  I couldn't
: find it either in "Programming Perl" or in the man page.

That's somewhat OS dependent.  Try "man 2 signal", or maybe "man 3 signal".

Larry

rbj@uunet.UU.NET (Root Boy Jim) (03/07/91)

lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
?In article <VICTOR.91Mar4155214@irt.watson.ibm.com> victor@ibm.com writes:
?: Where is there a list of the default actions for %SIG?  I couldn't
?: find it either in "Programming Perl" or in the man page.
?
?That's somewhat OS dependent.  Try "man 2 signal", or maybe "man 3 signal".

Yes, but we need more signal support. I would like to block
signals, set masks, etc. Either POSIX or 4.3 interface would be fine.
Actually, it should probably be POSIX. At least say "someday".
-- 
		[rbj@uunet 1] stty sane
		unknown mode: sane

tchrist@convex.COM (Tom Christiansen) (03/07/91)

From the keyboard of rbj@uunet.UU.NET (Root Boy Jim):
:Yes, but we need more signal support. I would like to block
:signals, set masks, etc. Either POSIX or 4.3 interface would be fine.
:Actually, it should probably be POSIX. At least say "someday".

Probably so.  On systems with the facilities you describe,
won't syscall get you there?  What does dot-1 say on syscall?
I know -- it's just a hack.  

--tom
--
	I get so tired of utilities with arbitrary, undocumented,
	compiled-in limits.  Don't you?

Tom Christiansen		tchrist@convex.com	convex!tchrist

meissner@osf.org (Michael Meissner) (03/07/91)

In article <1991Mar06.213823.17347@convex.com> tchrist@convex.COM (Tom
Christiansen) writes:

| Probably so.  On systems with the facilities you describe,
| won't syscall get you there?  What does dot-1 say on syscall?
| I know -- it's just a hack.  

I don't think dot.1 has syscall, but that's not the real problem.  The
real problem is the size of the signal mask is implementation
dependent (ie, it's not just a long anymore).  On DG/UX on the 88k,
signal masks were 64 bits.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?

rbj@uunet.UU.NET (Root Boy Jim) (03/07/91)

In article <MEISSNER.91Mar6212812@curley.osf.org> meissner@osf.org (Michael Meissner) writes:
?In article <1991Mar06.213823.17347@convex.com> tchrist@convex.COM (Tom
?Christiansen) writes:
?
?| Probably so.  On systems with the facilities you describe,
?| won't syscall get you there?  What does dot-1 say on syscall?
?| I know -- it's just a hack.  
?
?I don't think dot.1 has syscall, but that's not the real problem.  The
?real problem is the size of the signal mask is implementation
?dependent (ie, it's not just a long anymore).  On DG/UX on the 88k,
?signal masks were 64 bits.

Well, that's just one of many system dependent things. Pyramid's
sgtty struct is differently sized, so I had to use a different
format string to pack/unpack.

So I do: format = system(`pyr`) ? 'CCCCS' : 'SSCCSa20';
Similar techniques can be used elsewhere.
-- 
		[rbj@uunet 1] stty sane
		unknown mode: sane

victor@arnor.UUCP (Victor Miller) (03/07/91)

>>>>> On 6 Mar 91 21:27:21 GMT, rbj@uunet.UU.NET (Root Boy Jim) said:

rbj> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
rbj> ?In article <VICTOR.91Mar4155214@irt.watson.ibm.com> victor@ibm.com writes:
rbj> ?: Where is there a list of the default actions for %SIG?  I couldn't
rbj> ?: find it either in "Programming Perl" or in the man page.
rbj> ?
rbj> ?That's somewhat OS dependent.  Try "man 2 signal", or maybe "man 3 signal".

rbj> Yes, but we need more signal support. I would like to block
rbj> signals, set masks, etc. Either POSIX or 4.3 interface would be fine.
rbj> Actually, it should probably be POSIX. At least say "someday".
rbj> -- 
rbj> 		[rbj@uunet 1] stty sane
rbj> 		unknown mode: sane

I agree.  As an addition is it at all possible (I suspect it's hard)
to have signals give some kind of indication of what line in the perl
program they interrupted.  For some internal signals (such as PIPE)
this might be possible.  For example, I had done something stupid so
when I tried to write to a filehandle which was a pipe to a
non-existent program, the perl script just quit silently (actually not
completely -- there was some sort of mysterious status code set).
When I set up a @SIG{'PIPE'} handler, all it could do is report that
there was a PIPE error, but couldn't tell me where.
--
			Victor S. Miller
			Vnet and Bitnet:  VICTOR at WATSON
			Internet: victor@ibm.com
			IBM, TJ Watson Research Center

tchrist@convex.COM (Tom Christiansen) (03/08/91)

From the keyboard of victor@ibm.com:
:When I set up a @SIG{'PIPE'} handler, all it could do is report that
:there was a PIPE error, but couldn't tell me where.

You mean a _$SIG{'HANDLER'}.  The caller seems set up to do nearly this,
but unfortunately it doesn't work in signal handlers as it does in 
other functions.

The way I set up my pipe handlers, it hasn't ever been ambiguous
what was going on.  Could you show an example of this?

Maybe it's time to repost my "how to handle pipes to/from programs that
might now be there" stuff.

--tom
--
	I get so tired of utilities with arbitrary, undocumented,
	compiled-in limits.  Don't you?

Tom Christiansen		tchrist@convex.com	convex!tchrist

rbj@uunet.UU.NET (Root Boy Jim) (03/08/91)

In article <1991Mar07.220845.3888@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
>From the keyboard of victor@ibm.com:
>:When I set up a @SIG{'PIPE'} handler, all it could do is report that
>:there was a PIPE error, but couldn't tell me where.
>
>The way I set up my pipe handlers, it hasn't ever been ambiguous
>what was going on.  Could you show an example of this?

I think SIGPIPE is one of the worst wastes of a signal.
I always ignore it and process it synchronously.

Besides, before you do a write or a print you can always say:
"$sigpipe = __LINE__", and reference the variable from the handler.

>Maybe it's time to repost my "how to handle pipes to/from programs that
>might now be there" stuff.

Well, I don't remember seeing it.

>--tom
>--
>	I get so tired of utilities with arbitrary, undocumented,
>	compiled-in limits.  Don't you?

Most definitely. I believe that all arbitrary limits should be
documented and enforced at runtime. Then it's a feature!

>Tom Christiansen		tchrist@convex.com	convex!tchrist
-- 
		[rbj@uunet 1] stty sane
		unknown mode: sane