Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: wishlist: current line number variable
Message-ID: <8873@jpl-devvax.JPL.NASA.GOV>
Date: 25 Jul 90 23:10:37 GMT
References: <8815@jpl-devvax.JPL.NASA.GOV> <aq9sk3.kc9@wang.com> <8854@jpl-devvax.JPL.NASA.GOV> <15698@bfmny0.BFM.COM>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 68

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.