I've no idea what that does and I've been coding Perl for some time now. That's one of the problems of Perl... probably the reason why it will succumb

Ah! So, according to you, Perl will "succumb" because you don't understand something, and can't be bothered to work it out. That's not "one of the problems with Perl"; it's one of the problems with some of the people that program in Perl.

Let me see if I can't break it down for you. Not the code; your resistance to understanding it.

perl -e"open $fh[$_],'>','split.'.$_ for 0..9"
-nle"print {$fh[substr $_,3,1]} $_" big.log
[download]

I'm going to assume that you've used perl one-liners before--say perl -le" print for 1 .. 10 "? (If not see perlrun.)

Well this command consists of 2 -e"..." arguments. They are executed in turn in the order you see them:

1. The first -e"open $fh[$_],'>','split.'.$_ for 0..9"

   Opens 10 files, called split.0 through split.9, for output, and stores their handles in global array @fh.

2. The second -nle"print {$fh[substr $_,3,1]} $_" big.log
   • uses the -n switch to ask perl to read the file big.log one line at a time

     and call the code between the "...", with $_ set to each line in turn.

   • And the bit in quotes print {$fh[substr $_,3,1]} $_

     prints each line ($_) to one of the files opened above.

   • Which file gets which lines is decided by extracting one character from the line: substr $_,3,1,

     which will be a digit in '0' .. '9',

   • And using that to index into the array of filehandles we opened { $fh[ ... ] }.

     And the reason the $fh{ ... ] is in curlies, is because otherwise perl would not recognise the array element as a target filehandle and would instead print its value (and the line) to STDOUT.

There's nothing magical nor complicated nor obscure about any of that. It's all well documented and quite intuative once you've read & understood it. And it is exactly why so many sysadmins use Perl. Because it allows them to do off-the-cuff tasks--like splitting up a log file for easier handling--right there at the terminal without even breaking their main train of thought.

If they had to use C, or assembler or Java or C++, they'd have to start an editor, lookup apis, compile, debug, test, iterate. And by the time they'd finshed and got back to what they were doing, they've forgotten why they needed to do it in the first place.

With just a little reading and a little practice, they type that one-liner and run it, without losing their train of thought, so intuative and well thought through are Perl(5)'s features.

But that didn't happen by accident. It is the result of

• the experience of what is wrong (and right) with other "scripting tools" by the designer;
• an iterative design & development process over many cycles;
• (perhaps) a designer who has an inate feel for when something isn't quite right and the balls to stick it out until it is;