1834009 Members
4278 Online
110063 Solutions
New Discussion

Re: ftp script

 
SOLVED
Go to solution
Anthony khan
Frequent Advisor

ftp script

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

8 REPLIES 8
Mark Greene_1
Honored Contributor
Solution

Re: ftp script

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
the future will be a lot like now, only later
A. Clay Stephenson
Acclaimed Contributor

Re: ftp script

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
If it ain't broke, I can fix that.
harry d brown jr
Honored Contributor

Re: ftp script

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
Live Free or Die
Chris Vail
Honored Contributor

Re: ftp script

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
Wodisch
Honored Contributor

Re: ftp script

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
Anthony khan
Frequent Advisor

Re: ftp script

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
Steven Sim Kok Leong
Honored Contributor

Re: ftp script

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
harry d brown jr
Honored Contributor

Re: ftp script

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
Live Free or Die