FAQ
Scripts->Perl->Distribution("with less effort");

I think we have waited too long for some tar ball concept to wrap up sets of
files.

In fact, all we need is something to wrap a small set of text files.

That is what Perl does best -- text processing.

How about an extract / insert script which self-extracts as a perl program.

By default it would self-extract the insert perl program which builds the
self-extracting files.

extract.pl extract.pl --> produces insert.pl

So a download of this script gives you the insert

Then we are back to distributing only scripts in the spirit of scripts, only
text so there is no difficult handling. Any script can be self-extracting
immediately for everyone to use.

It took a few minutes to write but it works. It could be extended by others
efforts if they need to extract and do something with each file.

Sincerely,

David

David Scott
Project Leader, BioInformatics
Digital Gene Technologies, INC.
(858) 552-1400 x229
www.dgt.com < http://www.dgt.com/ <http://www.dgt.com/> >
dscott@dgt.com

Search Discussions

  • John Nolan at Mar 7, 2000 at 3:09 am

    I think we have waited too long for some tar ball concept to wrap up sets of
    files. I agree.
    In fact, all we need is something to wrap a small set of text files.
    Your idea kind of sounds like a shell archive.

    It's not a bad idea, but I still think a better idea is to
    just retrofit the existing CPAN mechanism for module tarballs
    for use with script tarballs. How hard can this be?

    --
    #-------------------------
    # John Nolan
    # jpnolan sonic net
    #-------------------------
  • David Scott at Mar 7, 2000 at 8:51 pm
    John,

    It took about 30 minutes to write but quite a few hours to debug and test
    to check out the many variations of such an archive. It is a
    self-extracting,
    script which wraps extraction and insertion of text files of which they
    themselves may be extracted scripts.

    It is documented in POD and represents a way to load into our current script
    archive any combination of text files as a self-extracting script. The
    self-
    extraction portion is only 35 lines which I left as clear un-obfuscated
    code.

    perl extract.pl -- extracts insert.pl and test.pl
    perl test.pl -- tests extraction and insertion
    perl insert.pl myTextBall *.doc *.pl *.pm -- inserts all text into a
    self-extracting
    text...ball

    I think it would encourage the scripters to submit more because they will
    not be
    limited to one all-inclusive-script.

    Since it is just text, perldoc reads all the pod right out of the archive.

    Sincerely,

    David
    -----Original Message-----
    From: John Nolan
    Sent: Monday, March 06, 2000 7:10 PM
    To: scripts@perl.org
    Subject: Re: Extract / Insert text files

    I think we have waited too long for some tar ball concept
    to wrap up sets of
    files. I agree.
    In fact, all we need is something to wrap a small set of text files.
    Your idea kind of sounds like a shell archive.

    It's not a bad idea, but I still think a better idea is to
    just retrofit the existing CPAN mechanism for module tarballs
    for use with script tarballs. How hard can this be?

    --
    #-------------------------
    # John Nolan
    # jpnolan sonic net
    #-------------------------
  • John Nolan at Mar 7, 2000 at 10:19 pm

    It took about 30 minutes to write but quite a few hours to debug and test
    to check out the many variations of such an archive. It is a
    self-extracting,
    script which wraps extraction and insertion of text files of which they
    themselves may be extracted scripts.

    Without having seen it, I think it sounds like a useful tool,
    and I think you ought to upload this script and make it available
    to others (if you haven't already). Thank you for writing it.

    That being said, however, I do not think it's the right way to
    implement tarballs for the CPAN script archive.

    I think this would be an appropriate time for the mailing list
    maintainer and/or the CPAN script archive maintainer to weigh in
    with an opinion.

    --
    #-------------------------
    # John Nolan
    # jpnolan sonic net
    #-------------------------
  • John Porter at Mar 7, 2000 at 10:27 pm

    John Nolan wrote:

    That being said, however, I do not think it's the right way to
    implement tarballs for the CPAN script archive.

    I think this would be an appropriate time for the mailing list
    maintainer and/or the CPAN script archive maintainer to weigh in
    with an opinion.
    I am neither, but I'll weigh in anyway. :-)

    MO: shar is the right paradigm. The downside is that shar is not
    portable. Perl is, of course; so it makes sense to make a perl
    equivalent of the shar utility. And it, and the scripts it
    generates, should not depend on anything other than a standard
    distribution of perl.

    Perl has uu*code built in, so that should take care of any
    binaries. Apart from that, a more-or-less straight port of
    shar to perl would be the way to go... IMHO.

    OTOH, MakeMaker is certainly capable of handling the installation
    and configuration of scripts, as much as of modules. The downside
    is that not all machines have a compatible make.

    --
    John Porter

    Papa! Es un gringo en la calle con su coche!
  • Rich Bowen at Mar 8, 2000 at 7:51 pm

    John Nolan wrote: ...
    I think this would be an appropriate time for the mailing list
    maintainer and/or the CPAN script archive maintainer to weigh in
    with an opinion.
    I, also, am neither.

    A little while ago (at the Perl conference in Monterrey) I spoke with
    Kurt about what needed to be done to get tarballs working for the
    Scripts section. As a result of that, I wrote a module called
    File::Archive, which can read certain information out of an archive
    file, whatever format that file was in (tar, tar.gz, .gz, and maybe some
    others - I forget). This was to be the basis of some work to make it
    possible to upload .tar.gz files to the Scripts section of CPAN, and
    have them work as desired.

    My impression has been since then that Kurt is, as we say in Kentucky,
    busier than a one-armed wall-paper-hanger (or a one-legged man in a
    butt-kicking contest, depending on what county you're from ...) and has
    simply not had the time to get to it.

    While the proposed tool certainly is pretty cool, I think that it would
    be cooler to be able to upload stuff to CPAN in a standard, common, and
    familiar format, rather than a new one cooked up for the purpose.

    Just my humble opinion.

    Perhaps a more valuable thing to do would be to ask Kurt what he has in
    mind, and what we can do to help move that along.

    Rich
  • Kurt D. Starsinic at Mar 9, 2000 at 11:16 pm

    On Wed, Mar 08, 2000 at 02:11:56PM -0500, Rich Bowen wrote:
    John Nolan wrote:
    ...
    I think this would be an appropriate time for the mailing list
    maintainer and/or the CPAN script archive maintainer to weigh in
    with an opinion.
    I, also, am neither.

    A little while ago (at the Perl conference in Monterrey) I spoke with
    Kurt about what needed to be done to get tarballs working for the
    Scripts section. As a result of that, I wrote a module called
    File::Archive, which can read certain information out of an archive
    file, whatever format that file was in (tar, tar.gz, .gz, and maybe some
    others - I forget). This was to be the basis of some work to make it
    possible to upload .tar.gz files to the Scripts section of CPAN, and
    have them work as desired.
    And thanks for that work, Rich. The module is useful even on its own.
    My impression has been since then that Kurt is, as we say in Kentucky,
    busier than a one-armed wall-paper-hanger (or a one-legged man in a
    butt-kicking contest, depending on what county you're from ...) and has
    simply not had the time to get to it.
    Yup, I've been [ insert comparison to anatomically-challenged laborer
    or athlete here ], and I haven't finished integrating File::Archive into
    the scripts-processing system (I started, I found a bug, Rich fixed it,
    then somebody moved all my tuits).

    This project has sat too long, though. Tonight, I'll finish adding
    support for scripts in tarballs (with and without compression). Watch
    this space for further details.
    While the proposed tool certainly is pretty cool, I think that it would
    be cooler to be able to upload stuff to CPAN in a standard, common, and
    familiar format, rather than a new one cooked up for the purpose.

    Just my humble opinion.
    I agree on this point. PAUSE has done very well so far with
    tarballs. They're easy to parse, construct, and deconstruct.
    What new capabilities do shar files make available to us?
    Perhaps a more valuable thing to do would be to ask Kurt what he has in
    mind, and what we can do to help move that along.
    You could complain like it matters. Oh wait, you just did. ;^)

    Peace,
    * Kurt Starsinic (kstar@orientation.com) ---------- Senior Network Engineer *
    `The rate at which a person can mature is directly proportional |
    to the embarrassment he can tolerate.' --- Douglas Engelbart |
  • Rich Bowen at Mar 15, 2000 at 3:09 pm

    On Thu, 9 Mar 2000 , "Kurt D. Starsinic" wrote: ...
    This project has sat too long, though. Tonight, I'll finish adding
    support for scripts in tarballs (with and without compression). Watch
    this space for further details.
    ...

    Don't mean to be impatient, but did you get this done? Is there anything
    that we can help with?

    Rich
  • Kurt D. Starsinic at Mar 15, 2000 at 5:06 pm

    On Wed, Mar 15, 2000 at 10:08:54AM -0500, Rich Bowen wrote:
    On Thu, 9 Mar 2000 , "Kurt D. Starsinic" wrote: ...
    This project has sat too long, though. Tonight, I'll finish adding
    support for scripts in tarballs (with and without compression). Watch
    this space for further details.
    ...

    Don't mean to be impatient, but did you get this done? Is there anything
    that we can help with?
    No, thanks to . . . interesting . . . features . . . of my latest
    Debian upgrade, I've been mostly offline since Saturday. I just got
    back on ten minutes ago. I've finished the changes on my trusty
    laptop, and I'll be uploading them tonight. Finally.

    Peace,
    * Kurt Starsinic (kstar@orientation.com) ---------- Senior Network Engineer *
    `People keep pretending they can make things deeply |
    hierarchical, categorizable and sequential when they can't. |
    Everything is deeply intertwingled.' -- Ted Nelson |
  • David Scott at Mar 8, 2000 at 12:14 am
    John,

    The shar paradigm is a great one. It offers self-extraction. It allows
    mixed mode of text and binary. It can compress. It supports uuencoding.
    It comes with documentation. But it is not written in Perl, is not portable
    and is far more than 35 lines of code to write.

    I propose I upload this simple self-extracting script as a first pass so
    that we can have it evaluated as a group. How about the utility category
    used in CPAN?

    Archiving-Compression-Conversion

    It is where you find Convert::UU for uuencoding/uudecoding, LZO or Zip
    compression and other similar utilities.

    I'd really like to see scripts come with testing similar to CPAN modules and
    a multi-file format would lend itself to including the test.pl along with
    the script.

    Sincerely,

    David
    -----Original Message-----
    From: John Porter
    Sent: Tuesday, March 07, 2000 2:27 PM
    To: scripts@perl.org
    Subject: Re: Extract / Insert text files


    John Nolan wrote:
    That being said, however, I do not think it's the right way to
    implement tarballs for the CPAN script archive.

    I think this would be an appropriate time for the mailing list
    maintainer and/or the CPAN script archive maintainer to weigh in
    with an opinion.
    I am neither, but I'll weigh in anyway. :-)

    MO: shar is the right paradigm. The downside is that shar is not
    portable. Perl is, of course; so it makes sense to make a perl
    equivalent of the shar utility. And it, and the scripts it
    generates, should not depend on anything other than a standard
    distribution of perl.

    Perl has uu*code built in, so that should take care of any
    binaries. Apart from that, a more-or-less straight port of
    shar to perl would be the way to go... IMHO.

    OTOH, MakeMaker is certainly capable of handling the installation
    and configuration of scripts, as much as of modules. The downside
    is that not all machines have a compatible make.

    --
    John Porter

    Papa! Es un gringo en la calle con su coche!
  • John Nolan at Mar 8, 2000 at 12:56 am
    Well, I'm not opposed to using your script.

    My only question is this: Why can't the existing CPAN utilities
    for processing module tarballs be retrofitted for script tarballs?
    The work required for making this happen has got to be exceedingly small.
    Or am I missing something? I've never understood what the obstacle
    actually is.

    I'm not clear on why we would abandon tar. What's wrong with tar?
    Everyone already uses tar. No one has complained about it,
    as far as I know.

    But I'm not opposed to abandoning tar either, if there is
    some sensible reason for it. Why is a self-extracting Perl
    script better than a tarball? The only advantage I can see is
    that you can implement it without waiting for the CPAN maintainers
    to make any changes. But I think fixing CPAN is a better idea.

    My apologies if I've misunderstood some part of your idea.

    I propose I upload this simple self-extracting script as a first pass so
    that we can have it evaluated as a group. How about the utility category
    used in CPAN?

    Archiving-Compression-Conversion

    It is where you find Convert::UU for uuencoding/uudecoding, LZO or Zip
    compression and other similar utilities.

    I'd really like to see scripts come with testing similar to CPAN modules and
    a multi-file format would lend itself to including the test.pl along with
    the script.


    --
    #-------------------------
    # John Nolan
    # jpnolan sonic net
    #-------------------------
  • Johan Vromans at Mar 8, 2000 at 11:27 am

    John Nolan writes:

    My only question is this: Why can't the existing CPAN utilities
    for processing module tarballs be retrofitted for script tarballs?
    The work required for making this happen has got to be exceedingly small.
    Or am I missing something? I've never understood what the obstacle
    actually is.
    Neither did I.

    While we think that a script is just a plain (Perl) file, its
    distribution involves just a little bit more. For example, a script
    needs to be installed and, at least, the leading #! line needs to be
    adjusted to the local Perl installation. The script can contain the
    documentation in POD, but an acompanying README would be mandatory
    since that is the first document you read to decide whether you are
    going to use, even download, the kit.

    Also, some kind of verification that the script actually runs and
    produces the correct results should be included. By this time, we have
    exactly what the modules tarballs have, or should have ;-).

    Whether we use tarballs or self-extracting Perl scripts, its the
    contents that matters. The packing format is less important, although
    tarballs have proven to be widely accepted. Zip would be a useful
    alternative. Text-based archives (shar, Perl) seem attractive since
    you can easily extract the POD docs, but once you add uuencoding and
    compression this advantage is lost.

    So what are we waiting for?

    1. A simple document that describes what need to be done to turn a
    useful script into a distribution kit (i.e. directory structure,
    sample files, Makefile.PL, etc.).
    2. A convention on the information that must be added to the README
    so external tools can extract data about requirements, platforms
    and so on.
    3. The tools mentioned in point 2.
    4. A simple document that describes how to install the kit if you do
    not have a decent 'make' program.
    Why is a self-extracting Perl script better than a tarball? The only
    advantage I can see is that you can implement it without waiting for
    the CPAN maintainers to make any changes. But I think fixing CPAN is
    a better idea.
    Can someone recap what fixes are required?

    -- Johan
  • John Porter at Mar 8, 2000 at 2:14 pm

    Johan Vromans wrote:

    tarballs have proven to be widely accepted. Zip would be a useful
    alternative.
    Even that's not necessary, since the popular Zip programs for Windows
    all know how to read .tar and .gz files. Tar.gz is a de facto
    cross-platform standard.

    Text-based archives (shar, Perl) seem attractive since
    you can easily extract the POD docs, but once you add uuencoding and
    compression this advantage is lost.
    Well, as in .tar.gz, you typically compress the whole archive file,
    and that means you can have an uncompressed archive file, if you
    just want to be able to extract the pod out of it.

    Also, a tar file that contains ascii files (like perl scripts)
    can be read without extraction, meaning pod2* can work directly
    on the tar file.

    So, IMHO, the only downside to using tar, instead of some self-
    extraction scheme, is that it relies on an external utility.
    This might not be bad, since everyone in the world has a program
    which can extract tar files.


    --
    John Porter

    Papa! Es un gringo en la calle con su coche!
  • Randy Kobes at Mar 8, 2000 at 6:16 pm

    On 8 Mar 2000, Johan Vromans wrote:

    John Nolan <jpnolan@sonic.net> writes:
    My only question is this: Why can't the existing CPAN utilities
    for processing module tarballs be retrofitted for script tarballs?
    The work required for making this happen has got to be exceedingly small.
    Or am I missing something? I've never understood what the obstacle
    actually is.
    Neither did I.

    While we think that a script is just a plain (Perl) file, its
    distribution involves just a little bit more. For example, a script
    needs to be installed and, at least, the leading #! line needs to be
    adjusted to the local Perl installation. The script can contain the
    documentation in POD, but an acompanying README would be mandatory
    since that is the first document you read to decide whether you are
    going to use, even download, the kit.

    Also, some kind of verification that the script actually runs and
    produces the correct results should be included. By this time, we have
    exactly what the modules tarballs have, or should have ;-).
    [snip]

    Hi,
    I have a script, sdist, under the CPAN category of the scripts
    archive, that does some of the stuff that h2xs does for creating
    module distribution templates - it creates skeleton README, MANIFEST,
    INSTALL, and Makefile.PL files, as well as a template with
    various pod headings for the script itself. A t/ subdirectory
    is also created for which test scripts can be included.
    This can then be used to create a distribution (via 'make dist'
    or 'make zipdist'), which one can use to install scripts via
    the same procedure as for modules - this puts scripts in the
    usual place, adjusts #! for the local configuration, etc. This
    though addresses the user end of things - the software processing
    these on CPAN won't recognize them as script distributions yet.

    best regards,
    randy kobes

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupscripts @
categoriesperl
postedMar 7, '00 at 12:37a
activeMar 15, '00 at 5:06p
posts14
users7
websiteperl.org

People

Translate

site design / logo © 2021 Grokbase