Re: help with grep looking for cats and dogs


----- Original Message -----
From: "Bill Vermillion" <bv@xxxxxxx>

> [...]
> Actually perl is still in the base system. What was changed were
> the perl scripts needed to install and/or compile and install
> a system.
>
> The only reason was to get the ever changing and always larger
> Perl out of the install process system so that it would be far easier
> to put in such small dedicated appliance like devices.. It took them
> quite
> [...]
> It elminted such problems encounted from moving from 3.x to 4.x
> by building sources [as opposed to a binary upgrade].
>
> That required a define -DNOPERL and then building world, then
> building and installing a kernel, then going back and build install
> and reboot a couple of more times.

Interesting.
But that's another reason I avoid perl when possible. I hate to rely on such
a large and complex system being in working order if it's possible to only
require a single binary. Of course all the various standard tools add up to
a small collection not a single bin, but still seems simpler and more robust
to me.

But I also don't know how much of perls functionality resides in the binary.
Maybe it's still at least as functional as the traditional toolkit even if
the lib/perl5 directory tree is gone.

Maybe I just feel that using perl to replace the various standalone tools
throws away one of the best facets of the unix enviroment.
For example, I'm sure perl has a command that does what, say "wc" does, but
I don't like the idea of having to use perl just to have it run that one
command, which I would have to if perl didn't also have it's own version of
the other things in the script or pipeline.

It's funny how even the same people can have different ideas about what
progress is in different contexts.
It seems to be generally seen as progress that kernels are modular instead
of monolithic.
Yet the same people all love perl, which to me seems to be taking the
already modular tool kit and making it into a monolithic all singing all
dancing tool.
otoh, I know perl is supposedly modular itself. perl modules are not as
portable as stand alone binaries, but maybe no less so than kernel
modules...
Maybe I am not done thinking about this yet.

Brian K. White -- brian@xxxxxxxxx -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

.

Relevant Pages

  • Re: attempt to build 64 bit on Solaris fails
    ... > libraries needed to link with a 64-bit Tk. ... We were running a 32-bit version of Perl ... > Each section below is a summary of the commands used to install it. ...
    (comp.lang.perl.tk)
  • Re: attempt to build 64 bit on Solaris fails
    ... libraries needed to link with a 64-bit Tk. ... We were running a 32-bit version of Perl ... Each section below is a summary of the commands used to install it. ...
    (comp.lang.perl.tk)
  • Perl on Linux and SQL Server 2000 on Windows
    ... There was a time when I did a lot of searching on ways to use Perl ... sitting on Linux to connect SQL Server 2000 sitting on Windows. ... cpan> install DBI ... Install FreeTDS ...
    (comp.os.linux.misc)
  • RE: Please Help !!! Unable to install DBD-Oracle ( I am using perl 5.6 on solaris 8)
    ... Ron, I could be way off here, but the OP mayalready have Perl ... think the original issue was that he tried to use *PPM* to install ... I don't have any Solaris ... you are not the intended recipient, please notify the sender at Wipro ...
    (perl.dbi.users)
  • Re: Installing DBD::File via CPAN
    ... Do you use 'UNINST=1' in the build options for CPAN? ... >> Did you build Perl from source, or install via a RPM or binary distro? ... >>> sender of the delivery error by replying to this message, or notify us ...
    (perl.dbi.users)