Some of my colleagues appear to think that things like perl are
so arcane that only I can do them. I have offered to do a _really_
basic introduction to perl (and unix shell stuff) tailored to
what my colleagues might possibly use it for, and several people
have expressed an interest.
It has to be admitted that I only use quite basic features of perl
myself, but my own experience has been that it's possible to do
genuinely useful things knowing only tiny bits of it. (My experience
with C has been otherwise, at least for the sorts of things I find
myself wanting to do.)
My intention is to try to get the message across using real-world
examples which achieve something clearly useful, without using many
features of the language. Preferably examples where doing it entirely
by hand (or with a spreadsheet or editor) would be awkward enough
that learning 3 things about perl and writing a script seems
faster and/or more appealing.
I would, for example, only (or initially?) use examples that use
standard input and output, since you can achieve plenty that way. And
no modules until/unless people are sold on the basic idea. And, to
keep the scripts looking as undaunting as possible, no "die"
statements, no checking of input, etc. (I know how daunting I find
"simple" programs 3 pages long)
Four examples which seem good to me would be:
(i) going through Apache logs and listing the IP addresses from which
Nimda attacks came. (via grep | cut | sort | uniq, and/or with perl)
(ii) removing mysterious binary characters in otherwise clean log
files (since this has actually happened to us) using tr
(iii) reversing netmasks, so that lines of the form "120.1.0.0
255.255.128.0" can be turned into,say, "access-list 142 permit ip
any 120.1.0.0 0.0.127.255"
(iv) Using cron and expect to log in to a router periodically and do
something to it. (to be concrete, get data from it and feed it to mrtg)
Taking (iii) as a concrete example: I have upon occasion been given
200+ networks I needed to do this to, and it strikes me as a perfect
applicaction for a perl script that uses only stdin and stdout for
this audience, though not as a first example. It's a realistic task,
and doing it by hand for 200 networks would be annoying.
What are some other ways of doing (iii)? One person I asked said "load
it into Excel and do search/replaces on the network masks until you've
covered all those used". This isn't bad, it has to be said. I watched
someone spend hours doing (ii) with Word, which doesn't feel right at
all.
To what extent do people feel that "casual grade" unix or Perl
knowledge to this sort of level is useful in network operations?
Even if experts are available, I wouldn't like to think it's necessary
to disturb them for this sort of thing.
Is it reasonable, when trying to sell some non-programmers on the idea
that basic scripting is useful and possible, to deliberately omit -w,
use strict, die, syslog and similar? In a 3-6 line script, that kind
of stuff would take up more space than the actual "meat" and risk
going against my "this isn't so hard, really" message.
If forced to do (i)-(iv) without using scripting of any kind, I'd
become quite annoyed. To be fair, (iv) clearly has to be scripted.
Are there other reasonable non-scripting methods of doing (i)-(iii)?
NB I'm not planning on claiming perl is uniquely wondrous. I just
don't know enough tcl, python, ruby or rexx to show anyone how to do
anything with them - and my own experience has been that you can use
expect without knowing any tcl except some "lindex" stuff to read
command-line parameters in.
Does what I propose seem more useful or dangerous? I think my main
aim is to show useful non-artificial examples as quickly as possible.
Talking about loop structures, scalars vs arrays vs hashes etc. seems
like exactly the wrong way to do.
It seems to me that
while (<>) {
(stuff)
}
can be used as the basis of useful stuff. (Also, one of the main
messages would be that the most important skill is taking an existing
script and tweaking it, even if you don't know how some of it works.)
Of course, I'd tell people that knowing other features as well might
allow more to be done, but I wouldn't want to push people into using
modules, objects, references, etc.
A nice Macallan (older than me), or even a