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. -- Adam Atkinson (ghira@mistral.co.uk) Do not look into laser with remaining eye.