wishlist: current line number variable
Steve Harris
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
Larry Wall
: 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
Tom Neff
>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 tn...@bfmny0.BFM.COM
Larry Wall
: In article <88...@jpl-devvax.JPL.NASA.GOV> lw...@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
lw...@jpl-devvax.jpl.nasa.gov
Tom Fitzgerald
> 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 fi...@wang.com
1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
:-), of course.
Larry Wall
: lw...@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
lw...@jpl-devvax.jpl.nasa.gov
Tom Neff
>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%bfm...@UUNET.UU.NET
Larry Wall
: >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.
Tom Neff
>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 )\) tn...@bfmny0.BFM.COM
Dominic Dunlop
(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