meissner@osf.org (Michael Meissner) (01/11/91)
In article <10980@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: | It would seem that your compiler or run-time system is hosed. The | statement in fatal() in util.c is | | statusvalue >>= 8; /* is an unsigned short */ | exit((int)(errno?errno:(statusvalue?statusvalue:255))); | | How can that return a 0, I ask you? Errno could possibly be 256 (or some multiple thereof). Under OSF/1, we are up to 125 (though there are some holes). -- 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?
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/11/91)
In article <10980@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: > It would seem that your compiler or run-time system is hosed. The > statement in fatal() in util.c is > statusvalue >>= 8; /* is an unsigned short */ > exit((int)(errno?errno:(statusvalue?statusvalue:255))); > How can that return a 0, I ask you? Well, since you ask, it can return 0 on most machines if errno is a nonzero multiple of 256, or if errno is 0 and statusvalue is a nonzero multiple of 256. ---Dan
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/11/91)
As quoted from <10980@jpl-devvax.JPL.NASA.GOV> by lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall): +--------------- | In article <3000@yarra-glen.aaii.oz.au> pem@yarra-glen.aaii.oz.au (Paul E. Maisano) writes: | : % perl -de 0 | : DB<1> "1" =~ /(.)/ | : DB<2> p $1 | : $1 | : DB<3> print $1 | : | : DB<4> | | That's a toughie. Lemme think about it a bit. Perhaps by embedding all | pattern matches in perldb.pl in a sub-block... +--------------- GNU Emacs has (match-data) to save the pattern match information and (store-match-data) to restore it. This is in some ways more flexible than simply using blocks: you can "thread" match runs together (not that that is readable, but sometimes it's the easiest way to do some things). You probably don't want to advertize the contents of the saved match data, however, unless Randal wants to use it in a JAPH really bad.... ;-) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (01/11/91)
In article <20541:Jan1017:37:5091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: : In article <10980@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: : > It would seem that your compiler or run-time system is hosed. The : > statement in fatal() in util.c is : > statusvalue >>= 8; /* is an unsigned short */ : > exit((int)(errno?errno:(statusvalue?statusvalue:255))); : > How can that return a 0, I ask you? : : Well, since you ask, it can return 0 on most machines if errno is a : nonzero multiple of 256, or if errno is 0 and statusvalue is a nonzero : multiple of 256. Hmm, yes, but I don't think that's what's going on here. On any machine with 16-bit shorts, statusvalue can't be a nonzero multiple of 256 because of the preceding shift, and I don't know of any machines with errno's greater than 255. It's vaguely possible that we have a garbaged errno, but I think it's more likely that we're seeing an endian problem. There's an alternate fatal() function with a similar exit(), but without the cast to (int). Since statusvalue is a short, it might be going into the wrong half of the int argument to exit. I'll replace both exit statements with: exit((int)((errno&255)?errno:((statusvalue&255)?statusvalue:255))); That should fix it, one way or the other. Larry
rm55+@andrew.cmu.edu (Rudolph T. Maceyko) (01/27/91)
From the man page: die(LIST) die LIST Outside of an eval, prints the value of LIST to STDERR and exits with the current value of $! (errno). If $! is 0, exits with the value of ($? >> 8) (`command` status). If ($? >> 8) is 0, exits with 255. Inside an eval, the error message is stuffed into $@ and the eval is terminated with the undefined value. Well, apparently, lists aren't my best datatype in PERL ;-> because I can't get die to Do The Right Thing with a list. A string works fine, so I can just concatenate everything if I wanted to.... However, die doesn't work as advertised. die 'prog: ', $$, ': invalid process', "\n"; >> Died at ./x line 3. die('prog: ', $$, ': invalid process', "\n"); >> Died at ./x line 3. die ('prog: ', $$, ': invalid process', "\n"); >> Died at ./x line 3. die +('prog: ', $$, ': invalid process', "\n"); >> Died at ./x line 3. @LIST = 'prog: ', $$, ': invalid process', "\n"; die @LIST; >> prog: at ./x line 4. @LIST = ('prog: ', $$, ': invalid process', "\n"); eval "die \@LIST"; print $@; >> Died at (eval) line 1. This is perl, version 3.0 $Header: perly.c,v 3.0.1.9 90/11/10 01:53:26 lwall Locked $ Patch level: 41 Copyright (c) 1989, 1990, Larry Wall Perl may be copied only under the terms of the GNU General Public License, a copy of which can be found with the Perl 3.0 distribution kit. Thanks for your help, Rudy +---------+ : +-----+ : Rudy Maceyko : : +-+ : : rm55+@andrew.cmu.edu : : : +-+ : rtmst@cis.pitt.edu +-+ +-+-+-+
composer@chem.bu.edu (Jeff Kellem) (01/27/91)
In article <IbcRGpq00VpJ0Bs0RX@andrew.cmu.edu> rm55+@andrew.cmu.edu (Rudolph T. Maceyko) writes: > Date: 26 Jan 91 19:12:53 GMT > > From the man page: > > die(LIST) [..man page partial quote deleted..] > Well, apparently, lists aren't my best datatype in PERL ;-> because I > can't get die to Do The Right Thing with a list. A string works fine, > so I can just concatenate everything if I wanted to.... However, die > doesn't work as advertised. I suspect that the man page is incorrect, it should probably say die EXPR die (EXPR) die instead of having LIST as its argument. There is a single mention of EXPR as the arg later in the man page under that same section, when mentioning that "If the value of EXPR does not end in a newline, the current script line number and input line number (if any) are also printed, and a newline is supplied." I haven't glanced at that particular code, but I suspect that man page is in error on this case (definitely an easier fix.. ;-). Larry? So, to do what you want.. just do.. die "prog: $$: invalid process\n"; Cheers... -jeff Jeff Kellem Internet: composer@chem.bu.edu
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (01/29/91)
In article <IbcRGpq00VpJ0Bs0RX@andrew.cmu.edu> rm55+@andrew.cmu.edu (Rudolph T. Maceyko) writes:
:
: Well, apparently, lists aren't my best datatype in PERL ;-> because I
: can't get die to Do The Right Thing with a list. A string works fine,
: so I can just concatenate everything if I wanted to.... However, die
: doesn't work as advertised.
Fixed in 4.0.
Larry