I'm primarily a C/C++ programmer, but I whack at Perl now and again.

In my job, I deal with lots of large files, and do my production work in C/C++ for the speed and memory efficiency. (Yeah, I know that line is overworked, but I'm packing stuff together and still approach memory limits!)

But what perl is *absolutely beautiful* for is answering the odd questions that come up. With the DBI, Spreadsheet, et. al. modules, I can often find exactly what I'm looking for in a short time, and send it onwards in a presentable fashion.

What initially 'hooked' me on perl was the DBI package and the regular expressions. What I tell my friends when I'm trying to convince them to give perl a try, I just tell 'em how much time I save by having it at my fingertips.

Once I help 'em out a few times with a quickie perl script, they start to get interested. Then it's a quick jump to http://www.cygwin.com.

...roboticus

I do mostly Perl and C programming. Besides pure Perl projects, I find Perl useful for:

• Processing data sets for use in developing/troubleshooting code.
• Automating bits of my build process that would be too tricky with only make and the shell.
• Quick little one-liners to translate crap I'm seeing in the debugger into useful information.
• Hacking together a quick prototype implementation of an algorithm.

Make sure you mention Inline::C and Inline::Java.

Convert::Binary::C is worth its weight in gold when I want to parse a memory dump. I also use it to build up ROM images.

Please fill in the ???

A lot of that depends on what platform you are writing your code for. I know that in my case I mostly deal with folks that are writing Java, JSP and other of that type of code for the Weblogic platform. I have shown some of the more receptive in that audience the beauty of writing stuff in Perl that doesn't depend on the overhead of the Java JRE to do back end maintenance for their applications. I've also show them how they can use Perl to detect patterns in application log files and send emails when those patterns are detected. Just a few of the items I've taught them.

God points. Could you elaborate a bit on the back end maintenance? What kind of things do you need to do there?

What kind of things do you need to do there?

So that I don't give away customer confidential information, let me instead enumerate some of the things I use Perl for to do back-end processing in some JSP/Servlet applications that I've created. Keep in mind there are ways to do this in Java as well, but in some cases I don't want the added overhead of the JVM/JRE.

• Cleaning out old records in database tabls and emailing the results
• Conversion of uploaded spreadsheets and/or CSV files to databsae rows
• Cleaning old temporary files the JSP application leaves behind.
• Backup of database to offsite system
That's just a short list of things I have Perl doing behind the scenes.

One of the items that I have Perl doing on one web application I maintain is Java is not allowed to send email directly. The capability exists, but there is no equivilant of Email::Valid to check for invalid email addreses. So the Java application queues up the email send request to a database table and a Perl script that awakens from cron checks the validity of the request, formats the email and sends it on its way.

---

Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg

Yes, szabgab needs to find out what

daily routine work beneficial only to themselves through helping others to automate small things

actually means.


holli, /regexed monk/

Exactly.

I need your help to learn what kind of such tasks Java and C* programmers might face.

I say you should emphasise CPAN. The strength of CPAN is that a lot of smart people have done a lot of smart thinking already.

When you get presented with a problem, the solution often seems simple or obvious -- who needs a whole module to parse text into sentences? Find the full stops, you're done!

But the more you think about it, the more edge cases and provisos and local variations you come across. A CPAN module is, or should be, the result of someone having thought of all the problems already, and leaving you some configurability for the ones they haven't.

But how can I convince them to take a look at Perl and to come to this short (half or one day long) training?

Anyonbe who attends gets free booze, cookies, ... ?

No really, I think you have to find out for what they use their primary language for and then you can show them how much easier it is to use Perl for these tasks.

If Perl is not the better language for what they are doing, then you are fighting a lost battle anyhow.

I'm not saying that what you are attempting is impossible; I think you have a great idea as long as you approach it as a teaser that is going to interest them enough to start spending those 5 minutes a day.

That said, I'll try coming up with some examples. Note that these will mostly be one-liners, because that's mostly what is useful on a day-to-day basis. Unfortunately, they use lots of magic command-line options, so they tend to make Perl seem even more magic and filled with special cases than it actually is.

• Grabbing out fields from a text file. Here's my standard /proc-based process memory monitor: while true; do perl -lne 'print $1 if /VmSize:\s*(\S.*)/' /proc/(pid)/status; sleep 5; done
• The print $1 if /.../ idiom is nice because you can select lines as well as the field you care about. Here's something that will print out the GET URLs from an Apache access_log file: perl -lne 'print $1 if /GET (\S+)/' access_log
• Summing up a bunch of numbers. This will sum up the sizes of all *.txt files in a directory: ls -l *.txt | perl -lane 'print $s += $F[4]' or with a nice output: ls -l *.txt | perl -lane '$s =+ $F[4]; END { print "Total size: $s" }'
• Note that the above can fail with longer usernames or groups. If that is a potential problem, then these would be more correct: ls -ln *.txt | perl -lane 'print $s += $F[4]' or perl -le 'print $s += (-s $_) foreach @ARGV' *.txt or even perl -le 'print $s += (-s $_) foreach glob("*.txt")'
• Ok, the previous example really isn't that good, since it can just be done with wc -c *.txt. Then again, maybe it's a good lead-in to a discussion of the usefulness of knowing how to use a hammer well.
• Here's one I used recently: we have directories containing C++ files. The usage pattern is supposed to be acyclic (if files in directory A include files in directory B, then nothing in B should directly or indirectly include files in A.) The first step was to dump out all of the include relationships: perl -lne 'print "$ARGV -> $1" while m!^#\s*include\s+["<](\w+)/!g' */*.cpp */*.h | sort -u (the includes look like #include "Ac/Insert.cpp"). Step 2 was to boil it down to just the directory usage lines; step 3 was to feed it to dot to display the graph nicely. (Actually, I had an intermediate step where I simplified the relationships to remove indirect links, but that was a much more involved program. We have a lot of packages.)
• I once wrote up a quick script to cross-verify Java API calls that were documented as deprecated but sometimes not marked as deprecated in the code. Or vice versa. I forget.
• Do a diff between two (possibly compressed) tarballs. Or rpms. (I have simple utility scripts I wrote for that, one 65 lines, the other 39. I think they'd both be understandable and maybe writable after a day with Perl.)
• Recursively add a directory tree to CVS.
• I could probably just look through my ~/bin directory for examples, but I think I'll stop now.