topic ftp script in Operating System - HP-UX

ftp script

Anthony khan — Fri, 04 Jan 2002 20:48:55 GMT

Hi Folks,

I am running a script in cron which check the dir, if the directory is empty the script exit otherwise start ftp, when the ftp done it will mv the files to done dir. Now what i want is that if the ftp connect drop by any reason it won't mv the files. But when the ftp session starts, I kill the session from the other service to check if its mv the files, and the script doing so, any suggestion.

Here's my script:

#!/bin/sh
cd /home/akhan/testdir
file=`find . -type f -print |wc -l`
if [ $file -eq 0 ]
then
exit 1
else
ftp -inv transrva <user user passwd
bin
lcd /home/akhan
cd /home/akhan/ftp.sh
mput *
bye
EndFTP
fi
error_code=$?
if [ $error_code -eq 0 ]
then
filename=" "
for filename in `ls`
do
sleep 20
mv $filename /home/akhan/done$filename `date +%Y.%m.%d`
fi

Thanxs

Re: ftp script

Mark Greene_1 — Fri, 04 Jan 2002 20:55:04 GMT

the exit code from ftp just tells you if ftp started and stopped ok, not if there were any errors during the connection. You have to route standard error from the ftp process to a log file and grep for the error numbers and key phrases (not all the errors are displayed with their numbers) to determine if the file were sent ok or not.

I posted a solution for this about a month ago. I the search function is cooperating today, I will try to dig-up the link to it and post it for you.

mark

Re: ftp script

A. Clay Stephenson — Fri, 04 Jan 2002 21:02:31 GMT

Hi Anthony:

Hi Adam:

In the past, I used to do this stuff in the shell but now I NEVER do because I have found a much cleaner way to do it that makes error trapping duck soup. Do this stuff in Perl using the Net::FTP module which is available from http://www.cpan.org .

Here's how simple it can be:

#!/usr/bin/perl -w

use Net::FTP;
use strict;

my $ftp = Net::FTP->new("remotehost",Debug => 0);
$ftp->login("cstephen","top_secret");
$ftp->cwd("/tmp");
$ftp->get("myfile");
my $stat = $ftp->status;
my $full_stat = $ftp->code;
# $stat contains the first digit; usually all
# that you need to do is test if it is equal
# to 2. $full_stat contains the full 3-digit
# value but is seldom needed
printf("Status: %d Full Status: %d\n",$stat,$full_stat);
# Sample Test
if ($stat == 2)
{
print "Get was good\n";
}
else
{
print "Get was bad\n";
}
$ftp->quit;

I think if you start using this module you will never go back to shell scripting FTP. Moreover, these same scripts will run in the NT world.

Notice that this method easily handles the error checking. If you like, you can use the shell for most of your script and simply use a bit a perl for the actual FTP transfers. In that case add the statement exit($stat) to the perl script and then your shell script does have a valid status indication.

Now, if it were me I would do it all in Perl but that's just my blind and simple approach.

Food for thought, Clay

Re: ftp script

harry d brown jr — Fri, 04 Jan 2002 21:06:59 GMT

I've been fighting this kind of backwards thinking for many years. it's been my opinion that when a file is ready to be retreived, that the process that created the file is the process that should be SENDING the file. It's such a waste of resources to spin on retreiving a file, when the remote process that created the file knows that it is ready to be sent.

live free or die
harry

Re: ftp script

Chris Vail — Fri, 04 Jan 2002 21:24:00 GMT

For applications like this I use rcp rather than ftp. It is a lot easier to script, it uses less bandwidth on your network and uses fewer clock cycles on both ends. It also means that you don't have to hardcode the password into the script.

Also, once having copied the file, use sum -r to do a checksum, and compare it with the checksum on the source. This ensures that your file arrived intact--regardless of how long it took to copy or how many errors were encountered along the way.

Chris

Re: ftp script

Wodisch — Sat, 05 Jan 2002 02:08:00 GMT

Hello Anthony,

you could use "scp" instead of "ftp" or "rcp" to be on the save side...

But for your "ftp" scripting, why not do this on the client side:

Move that "mv" command into your list of "ftp" commands using the "!" (bang) notation - if your "ftp" is broken, htat "mv" will NOT be executed!

HTH,
Wodisch

Re: ftp script

Anthony khan — Mon, 07 Jan 2002 14:13:09 GMT

Hi Harry,
I agree with you, but the thing is that we getting the file from differen banks to process, so banks are ftp the files in ftp server.

Anyway thanxs guys for ur help

Re: ftp script

Steven Sim Kok Leong — Thu, 24 Jan 2002 02:47:28 GMT

Hi,

Banks are using FTP?! *faint on the spot* This forum is not for the faint-hearted.

Which bank is that? I won't want to deposit money in such a bank :P

FTP transmits data in the clear and is vulnerable to spoofing, hijacking and data sniffing attacks to name just a few.

Why are you still using FTP?

Hope this helps. Regards.

Steven Sim Kok Leong

Re: ftp script

harry d brown jr — Thu, 24 Jan 2002 03:24:12 GMT

Anthony,

I was a developer for a bank and then a banking software company (specializing in ATM's, ACH, EDI, Teller Terminals, Check Sorters, data file transmissions, and yes, unix) for almost 10 years, and that's where I TAUGHT other banks, the IRS, state agencies, and other vendors HOW data was to be transmitted.

Steven, What Anthony is using is a semi-secure private network within the financial community, probably something I'll be using soon. The network really isn't BankA sending data directly to BankB, what happens is that BankA sends their data to a REPOSITORY (some call it a mail box), where then BankB can go get it. Only BankA can see BankA's "private" network, and the same is true for everyone else. Now I agree that if you have not encrypted your data, that you run the risk of hijacking, and if I was the developer, I'd be slapping people into shape that, yes the data would be encrypted. But, hell, a few years ago, I could have created an ACH tape, and sent it to almost any bank and it would have been processed. Fortunately, things have changed, and security in banks is getting better, but I'm sure I could empty most ATM's with very little work: wire cutters, a PC, some extra wire, and a lot of stupidity (it's a federal crime!).

live free or die
harry