I think that the stucture of this script is excellent! Adding command line argument support should be a breeze now (hint! hint!). However, i would change the name of the subroutine Main to something more descriptive like fetch_message or just fetch. (and lower case is nicer!)

Off topic, i advise against re-using variables like you do with this snippet:

my $url  = "ftp://$id:$pw\@$dom/logs/";
$url     = new URI::URL("$url/$logweb");
[download]

my $site = "ftp://$id:$pw\@$dom/logs";
my $url  = new URI::URL("$site/$logweb");
[download]

sub Yesterday {
  # sidetrack: following golf just a thought ...
  my($yy, $ym, $yd) = Add_Delta_Days(Today(), -1);
  return sprintf "%04d-%02d-%02d", $yy, $ym, $yd;
}
[download]

Other than those nit-picks, i say nice work ybiC...

UPDATE
...but also heed chromatic's wisdom!

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

The reason to avoid globals is to prevent action at a distance. You have two control branches and a handful of error checks. There's no reason to have subroutines, either. Let glue code be glue code.

I'm a big believer in putting off unnecessary complexity. Your code as it is is simpler without these hoops. If you decide to turn it into a module someday, you won't have too much work to do to generalize it. (It looks awfully specific for that, though.)

Very nice, you've got them all scoped as lexicals. None of the following is criticism, you've chosen a style which is very good for maintainance.

There are a few things you could do to limit scopes further. The simplest and least obtrusive would be a bare block around my $yesterday' and my @msg; like this:

use LWP::UserAgent;
{
    print "\n  Fetching log...\n\n";
    my $yesterday = Yesterday();
    my @msg = Main(
      'joe@modem.com',           # remote domain
      'yosef',                   # remote id
      'secret',                  # remote password
      "access.log.$yesterday",   # remote logfile input
      'c:/logs',                 # local dir to write to
      'access.log',              # local logfile output
    );
    print "$_\n" for(@msg);
}
[download]

My own inclination is to do away with named variables as much as is consistent with maintainability and readability, so I might have written that as:

{
    local $\="\n";
    print "\n  Fetching log...\n";
    print for Main(
              'joe@modem.com',           # remote domain
              'yosef',                   # remote id
              'secret',                  # remote password
              "access.log.".Yesterday(), # remote logfile input
              'c:/logs',                 # local dir to write to
              'access.log',              # local logfile output
              );
}
[download]

sub Yesterday {
    sprintf "%04d-%02d-%02d", Add_Delta_Days(Today(),-1);
}
[download]

After Compline,
Zaxo

"I've had several 'trivial' scripts grow well beyond thier original intent."

I continually find myself fending off the implicit patina of triviality assigned to Perl by users, evoked by the word 'script' (further bolstered by the impression, however accurate, that Perl is to UNIX what Visual Basic (et al) is to Windows).

Nearly all the so-called 'one-off's I've ever written have somehow wound up either running in Production, or at least used on a regular basis ('soft' production, as it were). It has reached the point where I no longer use the word 'script' to refer to them when speaking to users, instead using the more substantive, 'program.'

Toward that end I try ALWAYS to write my scripts/programs, however trivial, as though they are full-fledged applications (or soon will be). Which is to say I eschew globals, at the expense of passing values to subroutines more than perhaps efficiency would dictate.

dmm

If you GIVE a man a fish you feed him for a day
But, TEACH him to fish and you feed him for a lifetime

There are very few reasons to not do things the right way. If it's no skin off your back, then don't cut corners. "Shortcuts make for long journeys."

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

I think that the use of globals increases as the program increases in size and complexity - it becomes simpler and sometimes clearer to pass half a dozen variables througha global hash than directly to the subroutine.

Perl gives us alot of power for quick hacks, simple tools, fast fixes. For example, returning the last thing evaluated, providing a default variable ( $_ ) for just about everything means I can construct, say, a script which changes every url in a couple of HTML files, in about five minutes. But most of those features are inappropriate for a program of any size where your spending days working on it anyway, the twenty minute time gain of using them isn't worth in terms of a lost of readability and reuse.

I think that the use of globals increases as the program increases in size and complexity - it becomes simpler and sometimes clearer to pass half a dozen variables through a global hash than directly to the subroutine.

GYAH! No, don't do that. It'll be clearer for the first week or so, then you'll need extra comments to figure out where that hash is coming from. Then you'll make a few changes, and forget to update the comments. (Trust me, you will forget.) Then you'll want to process many widgets instead of just one, so your hash will become an array of hashrefs, and you're totally screwed.

Globals are good for things like program options (i.e. don't pass around the args hash you got back from Getopt). Globals are good for collecting the data you're operating on: if you're modelling TCP connections, then a global array of connection objects is perfectly reasonable. Globals are sometimes reasonable for the outermost scope of your problem space. If you're writing a state machine, for instance, and you know somehow that you'll never want to model more than one state machine, then it's sometimes okay to put your state in the global namespace rather than packaging it up into a class (or even a hash) and accessing it opaquely.

Most of the time, though, the little time you save by making stuff global rather than packaging it up just a little bit is completely overwhelmed by the time it takes you to refactor your code when your problem expands, even if you're just prototyping something. Slinging around globals is false laziness.

(Anyone else want the soapbox? :-)

--
:wq