BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX

[KDOSS_PERL]

Greetings to PERL Programmers:

I've been an Unix System Administrator writing crude shell scripts for
the past 15 years. I never got into writing sophisticated scripting
with multiple looks for my jobs. I would like to use Perl scripts and
was wondering if there are any recommendations for a guy with my kind
of back ground. Any input from your guys would be most appreciated.

Thanks in advance.

Regards,
-Kennedy

 

[John Bokma]

Greetings to PERL Programmers:

I've been an Unix System Administrator writing crude shell scripts for
the past 15 years.

Must have been a case insensitive Unix system then...

 

[Ric]

Greetings to PERL Programmers:

I've been an Unix System Administrator writing crude shell scripts for
the past 15 years. I never got into writing sophisticated scripting
with multiple looks for my jobs. I would like to use Perl scripts and
was wondering if there are any recommendations for a guy with my kind
of back ground. Any input from your guys would be most appreciated.

You probably want to use some beginners book, Perl in 21 days or
Learning Perl O'Reilly

Perl is fairly easy and usually you don't program sophisticated large
scale applications with perl, so it should be fairly easy for you to get
into it.

 

[grocery_stocker]

You probably want to use some beginners book, Perl in 21 days or
Learning Perl O'Reilly

Perl is fairly easy and usually you don't program sophisticated large
scale applications with perl, so it should be fairly easy for you to get
into it.

Yes, basic Perl s fairly easy. However, the funky Perl is about as
enjoyable as wearing pantyhose to work when it's like 90 degrees
outside. Seriously, let's try to break this down....

1)Objects in Perl. This can sort of blow monkey's butt if you've never
really done OOP or dealt with pointers in C.

2)regular expressions. I liken this to a bad hangover.

3)Pipes in Perl. This only really starts to make sense if you've
written pipes on Linux, BSD, or any other kind of half baked,
delinquent descent of the UNIX Operating system.

4)Back to Objects in Perl. Somewhere in the 10,000 pages of internal
Perl documents, there is a section on how Perl has no kind of privacy
thingy. It goes on to say that one way to enforce privacy in Objects is
to use closures. I'm sure closures make sense if you are computer
science major.

5)Fork() and pseudo tty's. Just the thought alone inspires fear and
awe.

And of course, I've dealt with this all for writing small/dirty scripts
on my OS. For anything else, there is either C, Java (ughhh...), or
FORTRAN (leet).

Chad

 

[Randal L. Schwartz]

grocery> Yes, basic Perl s fairly easy. However, the funky Perl is about as
grocery> enjoyable as wearing pantyhose to work when it's like 90 degrees
grocery> outside. Seriously, let's try to break this down....

A guy named "Chad" knows about this. Hmm.

grocery> 1)Objects in Perl. This can sort of blow monkey's butt if you've
grocery> never really done OOP or dealt with pointers in C.

Yeah, Objects *require* references, and the average docs on references and
objects suggest that you know objects and pointers from other languages.

grocery> 2)regular expressions. I liken this to a bad hangover.

The important thing to keep in mind is that they're an entirely separate part
of the language, unlike anything else in Perl, but luckily like lots of other
tools.

grocery> 3)Pipes in Perl. This only really starts to make sense if you've
grocery> written pipes on Linux, BSD, or any other kind of half baked,
grocery> delinquent descent of the UNIX Operating system.

Perl has no native "pipes". Not sure what you're saying here.

grocery> 4)Back to Objects in Perl. Somewhere in the 10,000 pages of internal
grocery> Perl documents, there is a section on how Perl has no kind of privacy
grocery> thingy. It goes on to say that one way to enforce privacy in Objects
grocery> is to use closures. I'm sure closures make sense if you are computer
grocery> science major.

Or use one of the many "Inside Out Objects" modules on the CPAN, where most of
the magic is hidden for you.

grocery> 5)Fork() and pseudo tty's. Just the thought alone inspires fear and
grocery> awe.

Fork is standard Unix Fork. Pseudo TTYs ditto. Perl doesn't have anything
weird to contribute here.

print "Just another Perl hacker,"; # the original (# 0 ?)

 

[Tad McClellan]

Subject: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX

The one that suggests that you do not SHOUT AT PEOPLE.

I would like to use Perl scripts and
was wondering if there are any recommendations for a guy with my kind
of back ground.

Any of the tutorials mentioned in the Perl FAQ.

perldoc -q book

...

Tutorials
Beginning Perl
by James Lee
ISBN 1â€59059â€391â€X [2nd edition August 2004]
http://apress.com/book/bookDisplay.html?bID=344

Elements of Programming with Perl
by Andrew L. Johnson
ISBN 1â€884777â€80â€5 [1st edition October 1999]
http://www.manning.com/Johnson/

Learning Perl
by Randal L. Schwartz, Tom Phoenix, and brian d foy
ISBN 0â€596â€10105â€8 [4th edition July 2005]
http://www.oreilly.com/catalog/learnperl4/

Learning Perl Objects, References, and Modules
by Randal L. Schwartz, with Tom Phoenix (foreword by Damian Conway)
ISBN 0â€596â€00478â€8 [1st edition June 2003]
http://www.oreilly.com/catalog/lrnperlorm/

 

[Tad McClellan]

You probably want to use some beginners book, Perl in 21 days or
Learning Perl O'Reilly

One of those books is horrid, one of them is good...

Perl is fairly easy and usually you don't program sophisticated large ^^^
scale applications with perl,

Of course he doesn't, because he doesn't even know _any_ Perl yet!

If your "you" was the general "you", then that's a lot of hooey.

I've written several Perl projects that were sophisticated large
scale applications (5-10k lines of code each).

 

[grocery_stocker]

grocery> Yes, basic Perl s fairly easy. However, the funky Perl is about as
grocery> enjoyable as wearing pantyhose to work when it's like 90 degrees
grocery> outside. Seriously, let's try to break this down....

A guy named "Chad" knows about this. Hmm.

Calm down.

grocery> 1)Objects in Perl. This can sort of blow monkey's butt if you've
grocery> never really done OOP or dealt with pointers in C.

Yeah, Objects *require* references, and the average docs on references and
objects suggest that you know objects and pointers from other languages.

grocery> 2)regular expressions. I liken this to a bad hangover.

The important thing to keep in mind is that they're an entirely separate part
of the language, unlike anything else in Perl, but luckily like lots of other
tools.

grocery> 3)Pipes in Perl. This only really starts to make sense if you've
grocery> written pipes on Linux, BSD, or any other kind of half baked,
grocery> delinquent descent of the UNIX Operating system.

Perl has no native "pipes". Not sure what you're saying here.

I was thinking something like the following. Please note the script had
been slightly modified to protect th person from who I duped the core
code from.

#!/usr/bin/perl
use strict;
use warnings;

my @months = ("sep", "oct", "nov");
my $value = scalar (@months);
my $count = 0;

my $test = "oct";
my $bbs = "/usr/local/bin/bbs $test";

open my $out, '|-', $bbs
or die "cannot open pipe to bbsread: $!";


print $out "find gay | wc -l \n";

close $out
or die "cannot close pipe to bbsread: $!";


Let's pretend the bbs program runs on a Windows machine. Wouldn't
Windows mimic the Unix pipe() functions in the above script? If that is
the case, then wouldn't the behavior of the pipe() functions be similar
the behavior of the Unix pipe() functions?

grocery> 4)Back to Objects in Perl. Somewhere in the 10,000 pages of internal
grocery> Perl documents, there is a section on how Perl has no kind of privacy
grocery> thingy. It goes on to say that one way to enforce privacy in Objects
grocery> is to use closures. I'm sure closures make sense if you are computer
grocery> science major.

Or use one of the many "Inside Out Objects" modules on the CPAN, where most of
the magic is hidden for you.

grocery> 5)Fork() and pseudo tty's. Just the thought alone inspires fear and
grocery> awe.

Fork is standard Unix Fork. Pseudo TTYs ditto. Perl doesn't have anything
weird to contribute here.

Chad

 

[grocery_stocker]

I was thinking something like the following. Please note the script had

been slightly modified to protect th person from who I duped the core
code from.

Going slightly off topic. I really need to learn to proof read before I
post.

 

[Peter Scott]

I've been an Unix System Administrator writing crude shell scripts for
the past 15 years. I never got into writing sophisticated scripting
with multiple looks for my jobs. I would like to use Perl scripts and
was wondering if there are any recommendations for a guy with my kind
of back ground. Any input from your guys would be most appreciated.

There is a new book that I reviewed in the latest _Perl Review_ that is
explicitly targeted at your niche. I suggest you look at it:
http://www.amazon.com/Minimal-Perl-UNIX-Linux-People/dp/1932394508

 

[Ric]

One of those books is horrid, one of them is good...




Of course he doesn't, because he doesn't even know _any_ Perl yet!

If your "you" was the general "you", then that's a lot of hooey.

Sure perl programmers tend to think that they know about software
engineering

I've written several Perl projects that were sophisticated large
scale applications (5-10k lines of code each).

5-10k lines, you call that a large scale app?

Dude I don't know where you work at, but large scale apps start at
around 100k lines of code. I have written several apps in C++ that have
about 50k loc and I wouldn't consider them as large scale apps.

 

[Mark Clements]

5-10k lines, you call that a large scale app?

Dude I don't know where you work at, but large scale apps start at
around 100k lines of code. I have written several apps in C++ that have
about 50k loc and I wouldn't consider them as large scale apps.

People still measure application size in terms of lines of code?

Mark

 

[Ric]

Oh, lets not start that war! I once had 2 COBOL programs that were 60K
lines *each* just to price invoices. Perhaps what is done in 50k of C++
can be done in 10k of Perl code?????

Perhaps some things are done in C++ you can't do at all in Perl, so
don't even try.

 

[John Bokma]

Perhaps some things are done in C++ you can't do at all in Perl, so
don't even try.

Ah, the pissing contest! Remember Ric, you are not the language.

Not understanding that a language like Perl has a place makes your
software engineering skills doubtful, to say the least.

 

[Jürgen Exner]

Perhaps some things are done in C++ you can't do at all in Perl,

Hardly. Both languages are Turing complete, therefore there is no difference
between what you can do in each.

so don't even try.

If Perl makes it more difficult to shoot yourself in the foot then I
actually welcome those limitations.

jue

 

[Ric]

Ah, the pissing contest! Remember Ric, you are not the language.

Not understanding that a language like Perl has a place makes your
software engineering skills doubtful, to say the least.

If you comment on someones thread then first read the whole discussion,
you obviously didn't read it.

I started with the note, that perl is not designed to be used for large
scale apps. Some folks didn't agree, that's their problem.

Show me a large scale app like apache, mysql, word etc. that is written
in perl and I will shut up

 

[Ric]

Hardly. Both languages are Turing complete, therefore there is no difference
between what you can do in each.

If we talk about functional requirements, then you may be right, but
what about non funtional requirements.
For example a high speed 3d engine or a maintainable gui application
like openoffice

If you can do everything in perl, why does everyone design and write
large apps in C++, C# Java

If Perl makes it more difficult to shoot yourself in the foot then I
actually welcome those limitations.

Yeah right!

I do lots of perl programming and I have done lots of writing in C/C++
and C#, buts that's the silliest argument I've heard so far.

 

[Jürgen Exner]

If you can do everything in perl, why does everyone design and write
large apps in C++, C# Java

I don't know everyone, therefore I don't know if this claim is true.
However many people probably write certain applications in other languages
because they don't know about Perl, because of personal preference, because
of corporate mandates, or even because that other language is better suited
for that application.

Non of this percludes that the application could not be written in Perl if
you would want to.

Yeah right!

I do lots of perl programming and I have done lots of writing in C/C++
and C#, buts that's the silliest argument I've heard so far.

If you like convoluted pointer arithmetic, doing garbage collection
manually, and not having any operators on any compound data types, then that
is certainly your choice. I for my part prefer programming languages that
support my way of thinking, not hinder it with technical nonsense.

jue

 

[Puckdropper]

[email protected]:

People still measure application size in terms of lines of code?

Mark

Sure, what other metric is common to programs that's easily measured?

It's bad, but it's the best they've got. I had probably 1000 LOC in a
recent class project and probably wrote only 100 myself. Everything else
was done by a GUI builder or by the UML tool I used. (It was Java, not
Perl, but I constantly wished it was Perl. Does that count as on topic
here? ;-))

Puckdropper

 

[John Bokma]

Show me a large scale app like apache, mysql, word etc. that is written
in perl and I will shut up

Slashdot. But I am sure that you're going to tell "us" that Slashdot is
not an application and more yada yada. Like I already said, pissing
contest.