Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!rbj From: rbj@uunet.UU.NET (Root Boy Jim) Newsgroups: comp.lang.perl Subject: Re: Default actions for %SIG Message-ID: <124880@uunet.UU.NET> Date: 7 Mar 91 23:03:16 GMT References: <124822@uunet.UU.NET> <1991Mar07.220845.3888@convex.com> Distribution: comp Organization: UUNET Communications Services, Falls Church, VA Lines: 31 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