On Wed, 2006-08-09 at 14:36 -0700, Don Russell wrote: > Is it unreasonable to expect that ftp exits with a non-zero exit code > when something goes wrong? (I was asking that it return the highest code > it received from the server... well-documented error codes specific to > the ftp protocol; return zero if the actual code is in the 2xx range > would be acceptable) I'm not sure its unreasonable, but it is not clear to me that a working client should report anything that it's counterpart server does as its own error. Exit codes normally relate to the program itself. > I wanted to use the .netrc mechanism to provide a little script to ftp > the contents of a directory to a site. The ftp command is invoked by > another process (i.e. not a human using cli reading the text responses), > but that's useless when ftp always ends with zero. If you control both ends, just use rsync over ssh or scp or something where failure is implied by the completion of the command you issued. Ftp was designed to be interactive with success/failure reported per operation not overall. > Yes, I can write some Perl code to do this, and not use the ftp > command.... but the ftp command is already available, the .netrc > mechanism suits my purpose in this application... You can do it in perl code with Net::FTP, responding to the server errors as you see fit. > The only reason I'm pursuing this any further is because I feel "it is > the right thing to do". I'm not convinced that a server error has much relationship to a client error. For example the client clearly hasn't failed if you ask for a file that doesn't exist. > I've since found another solution to my problem > because ftp, as it is now, is of now use to me, except as a cli tool. That's what it is for. If you want to script it and know about the server-side responses you'd need something like expect to parse its output - and there are better approaches. -- Les Mikesell lesmikesell@xxxxxxxxx
