On Wed, 2006-08-09 at 14:36 -0700, Don Russell wrote: > I created a bugzilla report against the ftp client in FC5 and after a > couple of rounds of reopening (NOTABUG), it's been closed as "WONTFIX". > > Ref. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196141 > > It has to do with the ftp client always ending with an exit code of > zero, regardless of what happened during the actual ftp session. > > 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 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. > > 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... > > The only reason I'm pursuing this any further is because I feel "it is > the right thing to do". 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. > > I may re-open it again and provide a diff file.... but it certainly > doesn't appear that would be well received... You might also consider trying lftp, which is designed to be scripted and can parse ~/.netrc... Paul.
