Shell Programming and Scripting

Instead of just grep, include another grep.

ftp_ctr=`echo "$ftpresults" |grep "226" | grep -v "byte" | wc -l`

This should take care of the "bytes transfered".

As far as VMS / UNIX file sizes, you would have to do some math but you could do it. (unfortunately, I don't quite remember what the VMS defaults are...too many UNIX commands to remember).

Hi
The whole issue is to do with the usual ftp that we use, i have had this problem before of automating the session coz my ftping process nearly takes 2 to 3 hours, so the monitoring process and consequently the restarting of the whole process if the ftping fails does become tedious and time consuming so even the above mentioned return code will not prove useful to me, the process needs to be completed without any active external intervention which only then become a complete automated process.

I used an ftp software called ncftp which actually returns the status of the connection.
These are the status codes that it returns
0. Success.
1- Could not connect to remote host.
2- Could not connect to remote host - timed out.
3- Transfer failed.
4- Transfer failed - timed out.
5- Directory change failed.
6- Directory change failed - timed out.
7- Malformed URL.
8- Usage error.
9- Error in login configuration file.
10- Library initialization failed.
11- Session initialization failed.

This will solve the problem.
I can include the code that i used,if required..

hi
some modifications are required believe me it works , ihave tested
the code u are using is same as i am using instead of greping it from standard output
try to put all the response from the server in a file and use fgrep instead of grep
fgrep will return the string if it find one and instead of taking 226 u can use
"221 GoodBye" which is returned when the connection is closed properly
i have personly used this and it is working fine

I can't understand why anybody insists in automating ftp. To use ftp for batch transmission of files is just using a tool out of its specification. Yes, it is possible to use it out of its specification a bit better, but why bother?

For automatic transmission of files use the r-commands, like rcp (for single files), rsnyc (for bulk transmissions) or the kerberized pendants - or even the s-versions (scp, etc.) if you must. Save for scp (which, like ssh, isn't all too well suited for scripting) they can easily be impemented in scripts, have reliable commandline interfaces, meaningful returncodes - what else do you want? And why do you want ftp to deliver it?

bakunin

We have service providers who deliver data to us. The only technique they support is FTP to their site. We have 6 of these and we need the data file each business day. We also provide data and our perferred method is via http. A few clients demand ftp service and we aren't going to turn them away. We also would use sftp where we can, but only one client has gone for that. sftp is not any eaisier to script. We would turn away business before we open the r-commands to the internet.

I am dismayed to learn that my scripts may be in violation of the ftp standards. What specification forbids automated ftp? I musta missed that as I read the rfc's...

Sorry, if i was a little harsh yesterday (haven't had the best of days), but the main point remains: ftp is a program built for interactive transmission of files. There are other programs built for batch transmission of files, which are a lot easier (and more reliable) to script and are overall better suited for the task.

Nobody and nothing "forbids" using a tool for something it was not designed for (this was what I meant by "outside its specification"), only judgement and common sense. Since you like RFCs here's a quote from RFC1925: "With sufficient thrust pigs fly just fine. However, this is not necessarily a good idea." With sufficient effort nearly any tool can be brought to do anything - the question is not so much one of being possible, but one of being feasible.

If you use http to transmit files you could use http-get to automate the process. I don't have too much experience with this tool and hence wouldn't recommend it, but from what i know it should do the job.

If you do not like the r-commands (what I can understand, btw., security isn't an issue with them and setting up a kerberos-domain for their k-ized variants is still no fun in 2005) then maybe scp is a solution for you. It is implemented with little effort, works more ore less the same like rcp from outside, with a secure transmission engine inside and the only thing you have to do is to make sure you've got a valid ticket.

Sorry again if i have stepped on anybodies toes with my last point and a special apology to Perderabo whose posts i always enjoy to read.

bakunin