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