So what was once intended to be a one-off script gets a life of its own without my intent. Then I have to go back and start making it a more real critter.

Six months later, someone will come up and ask for a slight modification. Then, when there's two times you want to run it, make it a generic mini-application.

Once is a one-off ... twice is a mini-app ... three times is a solution. :-)

I agree. It might get "reused" in that having done that before I can write another similar one real quick. Or, if it's very similar, I can dig up the script and edit it, changing the names and such. Just because it's specialized doesn't mean it has to be bad code. So source and dest names, etc. can be noted as constants at the top of the script, and assumptions can be documented as comments.

—John

Software of all sizes has bugs. For one-offs it is very important to have a backup of whatever you are working on. If you get it wrong, just make another copy and try again until you are happy.

Just the confidence of knowing that you can try again makes a world of difference...

What I try to do is write a one-shot that does what they want, but is open enough so that I can then use it as a base for a complete program that will be ready when they realize that they needed it more then once.

I find that this approach works well because it keeps the requesting lead happy, helps make maintaining the code easier, and it allows each lead to use it.

The only time that I don't write code that I can easly translate into a full program is when it will only be used as a one-liner called from a shell script with perl -e.

-xPhase

I do from time to time code one-shot programs. Perl is the perfect language for this, as it gives me powerful functions to do what I need (whether it's changing a few lines, calculate a string transformation or extract useful lines).

As others noted, the problem is in how will these tools evolve over time... But you get to solve your present problem now. If you discover it's a larger problem, you can always go back to the keyboard and start to think about a more general purpose program.

For example, here is a one-shot done this afternoon in a quick session, that is aimed to extract lines from a special text export of FireWall-1 logs... The only goal was to be a little faster than the FireWall-1 log tool for problem investigation. And to use simple (and regular) expressions to match lines.

#!/usr/bin/perl -w
use strict;

# the various fields
my @field = qw/id date time if fw type action service src dst proto ru
+le sport reason/;
my $i = 0; my %field = map { ($_, $i++) } @field;

# create the filter
my %filtre = (@ARGV); my @filtre;
while(my ($k, $v) = each %filtre) { # better use a while than a for lo
+op
    push @filtre, '$data['.$field{$k}."]=~m/$v/i";
}
my $filtre = join ' && ', @filtre;

# open the file
my $file = "fw01.log";
open F, $file || die "Error: $file $!\n";
$\= "\n";
print join"--\t--", @field;
while(<F>) {
    my @data = (/"(.*?)"/g);
    print join"\t",@data if eval $filtre;
}
[download]

It has -w and use strict;, but the filename is hardcoded and the file is not closed! I translated the comments from French, but they were here from the start. And the most important ones are missing... because the filter creation process was clear to me!

This ugly script allows for nice combinations, like: match.pl src 10.1.1.5 action drop service "^23|telnet" which will show all telnet connections to 10.1.1.5 that were dropped by the firewall.

If I had to write a bigger and more general purpose script, I'd probably use closures to create filter subroutines...

Update: Quick and dirty scripts can be very ugly... This one for example had a bug that prevents you to use several conditions... each should not be used in a for, but in a while loop.

Similarly, we sometimes run programs for days on end, only to discover a small bug in output. We'll fix the bugs, no question, but we don't want to lose the CPU time. If a small script can fix the output, we want it! (However, as tilly points out above, you can only do this if you've a backup; perl -pi.bk -e ... is invaluable here). The "patch" code will never run again, as the bugs in the program have been fixed -- it only exists to correct a single output file!

This is bioinformatics: some of our files are >1GB in size, so text editors are not an option; it's either sed, awk or Perl.

In both cases, you want to write code iteratively (the first 5 versions never work), run it once, and throw it away.

Of course, I always hide away a copy of the script in my home directory; I never know when I'll want to steal some stuff from an old script.

I think there could be an intermediate form, or something for "one line programmers in training". That is, a small editor window or a button on your general editor to say "run it NOW" without having to make up a file name and save it, but still be able to easily edit and retry.

Perhaps a perl script that when run from the command shell, pops up this window and saves the stuff in a temp file implicitly; output when 'run' goes to the same shell window (and context) that you started from. Run it again and you get a window that remembers the contents from last time, so you can alter and try again. Maybe I'll play around with that and post it if I come up with something worth keeping.

—John