-Scott

A quick CPAN search finds, for example, Filesys::SMBClient

  use POSIX;
  use Filesys::SmbClient;
  
  my $smb = new Filesys::SmbClient(username  => "luser",
                                   password  => "password",
                                   workgroup => "BILLING");
  
  # Read a file
  my $fd = $smb->open("smb://target/sharename/file.csv", '0666');
[download]

Hmmm ... if you could get a linux box in there, you could use smbmount and just treat it as a normal file.

Or you could use mount_smbfs from FreeBSD:

mount_smbfs //user@server/share /mountpoint

(See /usr/share/examples/smbfs/dot.nsmbrc for setting up passwords and such.) Or you could use samba to download the file:

smbclient //server/share -U user%pass -c 'cd "dir"; get "file"'

Or you could use Filesys::SmbClient to access it as a perl filehandle without mounting anything. (Though you'll have to install libsmbclient first.)

The connection to VMS was made using ftp. Because the code was written nine years ago, the ftp was managed by a custom module rather than the CPAN Ftp module.

The files from the SMSC were left initially in VMS format on unix, complete with the ';' and version number, but any binary files were decoded with a C program before being processed logically with perl (the system had to deal with a variety of traffic types).

This may not be a direct answer to your question, but I hope it sheds some light on how an existing mobile usage filter written in perl was laid out - and one which has been successful for a long time.

Why does the user need to FTP the files to the UNIX box? Can't your script just attach using Net::FTP and issue an ls, parsing the results?

I'm suggesting something like this (psuedo):

my @CSV_list = parse_csv_file('stupid_file.csv');

if (@CSV_list) {
    my $ftp = connect_and_login('remote.site.tld');
    my @listing = parse_dir($ftp->ls('.'));

    compare_contrast(\@CSV_list, \@listing);
}
[download]

At what point do any files need to be sent to the FTP server?

Why does the user need to FTP the files to the UNIX box?

I'm not sure how that parse_csv_file sub is implemented, but I bet it'd appreciate actually having something to parse. :)

Perhaps I misunderstood the OP, but it sounds to me like there is a CSV file in one location (local) and it must be compared with a directory structure on a remote machine.

Even if I misunderstood that, I can't see where files are being sent (that is, pushed). Run the script wherever the CSV files exist, and use Net::FTP to deal with the listing. I still see no need for file transfer, here. Thus the request for clarification.

<-radiant.matrix->
Larry Wall is Yoda: there is no try{} (ok, except in Perl6; way to ruin a joke, Larry! ;P)
The Code that can be seen is not the true Code
"In any sufficiently large group of people, most are idiots" - Kaa's Law

Thanks to all for your replies!

I've managed to download a file from the command line, but I don't appear to be able to use wild cards... which is an issue. This may be because of security configurations on the windows box as I can't ls beyond the base directory, either.

The file names have a base of CE_AMA_SMSC_ followed by YYYYMMDD then eight digits that I can't seem to rhyme or reason of and then the extension. If I could use a wildcard, I'd be fine, but they are giving me fits.

Anyone have an idea why the following is failing?

[reports@clarkkent]/home/reports/reconcile(154): smbclient //oh-youn-f
+2.dobson.net/engineering -U dobson\\jbabcock%XXXXX -c 'cd "Common\AMA
+_Reconcile\AMA_Transferred\";mget "CE_AMA_report_SMSC_200508220*"'
added interface ip=10.32.16.38 bcast=10.32.16.255 nmask=255.255.255.0
session request to OH-YOUN-F2.DOBS failed (Called name not present)
Domain=[DOBSON] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]
code 0 listing \Common\AMA_Reconcile\AMA_Transferred\CE_AMA_report_SMS
+C_200508220*
[reports@clarkkent]/home/reports/reconcile(155):
[download]

Thanks

Jimbus