vsh@etnibsd.UUCP (Steve Harris) (07/18/90)
When the "warn" or "die" function is executed, a message is written to STDERR which includes the current line number of the perl script. Is there any way to access this number -- i.e., is there a special perl variable (or compile-time hook) which evaluates to the current line number of the perl script? Such a feature would be useful for writing one's own warn or die subroutines. -- Steve Harris - Eaton Corp. - Beverly, MA - uunet!etnibsd!vsh
tneff@bfmny0.BFM.COM (Tom Neff) (07/20/90)
In article <8812@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >Oh, now that I think of it, I guess you could always use -P and get the >C preprocessor to translate __LINE__ and __FILE__ for you. But I'll >add __LINE__ and __FILE__ to the Perl tokener. This is definitely a nice idea, and the right way to do it too. A lot of us could use this feature. While you're at it, could you make __STDPERL__ evaluate to constant 1? :-) -- "We plan absentee ownership. I'll stick to `o' Tom Neff building ships." -- George Steinbrenner, 1973 o"o tneff@bfmny0.BFM.COM
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (07/20/90)
In article <1131@etnibsd.UUCP> vsh@etnibsd.UUCP (Steve Harris) writes:
: When the "warn" or "die" function is executed, a message is written to
: STDERR which includes the current line number of the perl script. Is
: there any way to access this number -- i.e., is there a special perl
: variable (or compile-time hook) which evaluates to the current line
: number of the perl script?
:
: Such a feature would be useful for writing one's own warn or die
: subroutines.
There's no way to do that currently that I know of, short of a massive
kludge. (As in, pipe your STDERR through a forked process that hands
the line number back to you. Blech.)
I've wanted it myself for the purpose of translating the error line
number in an eval to the line number of the enclosing script. Ordinary
magic variables won't cut it--the magic happens when the value is taken,
and a magic $__LINE__ would give you the current line number in the subroutine,
not the line number in the subroutine call. Do you really always want to
have to force evaluation?
&my_die($__LINE__ + 0);
Hmm, I can just kludge it in the tokener to translate it to the literal
line number. Then it would even be eligible for constant folding. Likewise
for $__FILE__.
Or maybe it should just be __LINE__, without the $. I think so, since
it's not a variable.
Or should I make the tokens "line" and "file" and blow everyone's loop
labels? :-)
Oh, now that I think of it, I guess you could always use -P and get the
C preprocessor to translate __LINE__ and __FILE__ for you. But I'll
add __LINE__ and __FILE__ to the Perl tokener. In fact, $__LINE__ wouldn't
have worked if you DID use -P, so it won't have the $.
Larry
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (07/21/90)
In article <15690@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: : In article <8812@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: : >Oh, now that I think of it, I guess you could always use -P and get the : >C preprocessor to translate __LINE__ and __FILE__ for you. But I'll : >add __LINE__ and __FILE__ to the Perl tokener. : : This is definitely a nice idea, and the right way to do it too. A lot : of us could use this feature. It's already in. : While you're at it, could you make __STDPERL__ evaluate to constant 1? :-) Well, I don't think so. However, after the next patch you'll be able to run this article through perl -x and it will print out "howdy". #!/usr/bin/perl $_ = <STDIN>; print; __END__ howdy Think a little about the possible implications of that. Larry Wall lwall@jpl-devvax.jpl.nasa.gov
fitz@wang.com (Tom Fitzgerald) (07/24/90)
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: > However, after the next patch you'll be able to > run this article through perl -x and it will print out "howdy". > #!/usr/bin/perl > $_ = <STDIN>; > print; > __END__ > howdy > Think a little about the possible implications of that. Great! This'll save ten lines out of my BASIC to PERL translator! --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz :-), of course.
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (07/25/90)
In article <aq9sk3.kc9@wang.com> fitz@wang.com (Tom Fitzgerald) writes: : lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: : > However, after the next patch you'll be able to : > run this article through perl -x and it will print out "howdy". : : > #!/usr/bin/perl : > $_ = <STDIN>; : > print; : > __END__ : > howdy : : > Think a little about the possible implications of that. : : Great! This'll save ten lines out of my BASIC to PERL translator! Heh. Well. That's an idea, at that. Actually, I wasn't aiming quite so high. I was just thinking about obsoleting sharchives. You could unpack easily on any machine that had Perl and could feed the article to STDIN. The unpacker would be up at the front for easy verification of security concerns--no embedded code way down in the archive would be necessary. Very easy access to transmogrification for BITNET proofing. You could easily automate the security checking of known secure unpackers since the script is all at the front. Since most of what you need is built in, you can do a chroot for additional security without carrying along most of /bin with you. The only disadvantage I see is that it would force everyone to get Perl. Horrors. :-) Actually, since the rest of the archive would be in a standard form, you could probably write your own program to unpack easily it if you didn't have Perl. But if you did have Perl, it would be more or less self-unpacking. And Perl is available on more architectures that sh. I think sharchives are gonna get obsolete real quick. 'course, I gotta get this next patch out sometime... Larry Wall lwall@jpl-devvax.jpl.nasa.gov
tneff@bfmny0.BFM.COM (Tom Neff) (07/25/90)
In article <8854@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >Actually, I wasn't aiming quite so high. I was just thinking about >obsoleting sharchives. ... >But if you did have Perl, it would be more or less >self-unpacking. And Perl is available on more architectures that sh. >I think sharchives are gonna get obsolete real quick. *Sigh* Perl may be able to run on more *kinds* of machines than /bin/sh, but it's actually installed on a lot fewer boxes than /bin/sh, I'll lay odds. In fact the domain of comparison equals boxes with Bourne *PLUS* boxes with working 'unshar' extractor programs other than /bin/sh; these have been written for Bourne-unfriendly environments. And of the subset that do have Perl, what fraction will have the NEWEST VERSION necessary to support the extractor? None now; some presently; more eventually; all nearly never. The ones with old Perls will try and fail to extract, and we'll get problem reports. Shar isn't broken, and Perl shouldn't try to fix it IMHO. -- US out of North America, NOW!! /: Tom Neff -- Richard O'Rourke :/ tneff%bfmny0@UUNET.UU.NET
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (07/26/90)
In article <15698@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: : In article <8854@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: : >Actually, I wasn't aiming quite so high. I was just thinking about : >obsoleting sharchives. : ... : >But if you did have Perl, it would be more or less : >self-unpacking. And Perl is available on more architectures that sh. : >I think sharchives are gonna get obsolete real quick. : : *Sigh* : : Perl may be able to run on more *kinds* of machines than /bin/sh, but : it's actually installed on a lot fewer boxes than /bin/sh, I'll lay : odds. In fact the domain of comparison equals boxes with Bourne *PLUS* : boxes with working 'unshar' extractor programs other than /bin/sh; these : have been written for Bourne-unfriendly environments. True 'nuff. But all the unshars break whenever someone needs to do something new in their shar. There's not really a shar standard yet, and as soon as there is one, someone will find a valid reason to break it. And lots of invalid ones, but the point is that they will break it, continually. Or are self-unpacking formats only good enough for Unix machines? : And of the subset that do have Perl, what fraction will have the NEWEST : VERSION necessary to support the extractor? None now; some presently; : more eventually; all nearly never. The ones with old Perls will try and : fail to extract, and we'll get problem reports. Almost everyone will feel necessary to get the version documented in the book, I expect. It's not like they have to buy an upgrade license... And most of what they need is there already, should they feel the need to emulate -x and __END__ with a script of their own. : Shar isn't broken, and Perl shouldn't try to fix it IMHO. I agree with almost all the points you've been making in comp.sources.d, and I agree for the most part that shar isn't broken, but we can do better, methinks. As a transitional form, we could, f'rinstance, send out a shar script that has a Perl unshar prefix to unpack the shar where sh isn't available. That's a big plus in exchange for maybe ten lines of Perl code at the front (depending on the fanciness of your shar). Might run faster too. On the other hand, it doesn't force people to get Perl like it should... :-) Me, a Hidden Agenda? Naaah... Larry P.S. An embedded Perl unshar might look something like this, depending on the shar format you've selected (but since you know the format, you don't have to support everyone's format): #!/usr/bin/perl close STDOUT; while (<STDIN>) { s/^X// && (print(), next); s/echo "(.*)"/warn "$1\n"/; s/^sed[^>]*(>.*)/open(STDOUT,\$1)/; s/^SHAR_EOF$/close STDOUT/; s/chmod (\d+) (\S+)/chmod("0$1", \$2)/; eval; } __END__ #!/bin/sh ... Season to taste.
tneff@bfmny0.BFM.COM (Tom Neff) (07/27/90)
In article <8873@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: ... >There's not really a shar standard yet, and as soon >as there is one, someone will find a valid reason to break it. And lots >of invalid ones, but the point is that they will break it, continually. >Or are self-unpacking formats only good enough for Unix machines? I see this point, but I worry about (a) the necessity of dragging in a third party utility in order for a new standard shar to work, versus (b) Perl-dom striking out in its own incompatible direction rather than applying energies to try and actually GET a new standard in place. Neither is really acceptable. What this discussion makes me realize, though, is that it would be nice for a new shar standard to ALLOW bundled self extraction. We should remember that. Is there anyone working on this, seriously? I would be happy to contribute. >: And of the subset that do have Perl, what fraction will have the NEWEST >: VERSION necessary to support the extractor? None now; some presently; >: more eventually; all nearly never. The ones with old Perls will try and >: fail to extract, and we'll get problem reports. > >Almost everyone will feel necessary to get the version documented in the >book, I expect. It's not like they have to buy an upgrade license... >And most of what they need is there already, should they feel the need >to emulate -x and __END__ with a script of their own. What I mean to get at, but fumbled, was: the alien environments where people have moved mountains to port Perl successfully, are also the slowest to assimilate new versions. How long will it take for patchlevel 19 of MS-DOS or Atari or RTU Perl to trickle out to the ends of the earth? Yet those are the people who would supposedly benefit from having a portable unshar that doesn't need Bourne and Unix tools. >#!/usr/bin/perl >close STDOUT; >while (<STDIN>) { > s/^X// && (print(), next); > s/echo "(.*)"/warn "$1\n"/; > s/^sed[^>]*(>.*)/open(STDOUT,\$1)/; > s/^SHAR_EOF$/close STDOUT/; > s/chmod (\d+) (\S+)/chmod("0$1", \$2)/; > eval; >} >__END__ >#!/bin/sh >... Probably want to add s/^mkdir (.*)/mkdir("$1",0755)/; in there... -- To have a horror of the bourgeois (\( Tom Neff is bourgeois. -- Jules Renard )\) tneff@bfmny0.BFM.COM
domo@tsa.co.uk (Dominic Dunlop) (07/28/90)
In article <8873@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes (apropos of using perl to implement self-unpacking archives despite there being far fewer copies of perl in the world than of sh): >True 'nuff. But all the unshars break whenever someone needs to do something >new in their shar. There's not really a shar standard yet, and as soon >as there is one, someone will find a valid reason to break it. Boring standards note: the IEEE P1003.2a Shell and Tools User Portability Extension folks got close to putting shar into the standard, but yanked it from the draft earlier this year on the grounds of insufficient existing practise, insufficient consensus between implementations, insufficient interest, and so on. While this may may cause the jaws of readers in netland to drop, there is some truth in this rationale: shar (IMHO) is widely used in the Usenet community, but little used elsewhere -- and ``elsewhere'' constitutes most of the market for POSIX-conforming systems. So, for better or worse, nobody need worry about standards for shar for a while yet... -- Dominic Dunlop