Red Hat Bugzilla – Bug 196141
ftp client always ends with return code 0
Last modified: 2007-11-30 17:11:35 EST
Description of problem:
The ftp program always exits with a return code of zero, even if there were
login or transmission problems.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create a .netrc paragraph with an incorrect password
2. start the ftp client so the new .netrc paragraph runs
3. i.e. ftp ftp.example.com; echo $?
500 (perhaps in this case)
What is needed is a way for a program/script invoking ftp to be able to tell if
the ftp session was succesful by checking the return code of the ftp program.
The ftp client should exit with the return code set to the maximum return code
it received from the ftp server.
For example, perhaps the ftp server closes the control channel upon connecting
and sends back a return code of 421 (service not available). A non-interactive
ftp session will think the ftp session was successful based on the zero return code.
Perhaps a command line option could be specified to pass the highest server
response code back as the ftp client return code.
Or rather than a new option, make this the implied behavior when the client ends
and verbose is in effect, or when quitting from a macro....
Thanks for bug report.
Could you say me how did you configure server for using .netrc? I have still
problem. Do you use vsftpd?
The ~/.netrc file is not used by the server.
It is used only by the ftp client.
Yes, I do use vsftpd, but that is not related to this bug report.
The problem is with the ftp CLIENT.
Use the "man netrc" commmand to see the requirements for the ~/.netrc file.
Here is a sample:
thanks for comments.
Ftp couldn't return something else than zero, because it's the last command.
For non-interactive behaviour could work scipts with Perl modules for ftp
(In reply to comment #3)
> Ftp couldn't return something else than zero, because it's the last command.
Not true. FTP should exit with a code indicating the highest return code it
received from the server. If that code is in the 200-299 range, then exit with
zero is acceptable.
> For non-interactive behaviour could work scipts with Perl modules for ftp
New Perl code should not be required to handle something that FTP can already
do. I want my processes to be simpler, not increasingly complicated.
Consider the following ~/.netrc file:
Then, at the command line:
$ ftp 127.0.0.1; echo $?
The result should be 550 (the return code from "get" failing because the file
was not found on the server)
Instead FTP always exists with zero....
If FTP returns meaningful codes, it may be used within bash scripts etc without
having to write Perl code (as you suggest) to accomplish the same thing.
I meant to reopen this "bug".. see comment #4 above...
Connected to ...
local: billy.bob remote: billy.bob
227 Entering Passive Mode (...)
550 Failed to open file.
I think error codes are readeble this way, so I closed the bug.
I agree the error cdes are readable that way by people, when used at the command
line, but not so by machine when invoked from a script.
For example, I want to use an "init" macro in .netrc to mput *.* to some remote
site. The macro changes to the correct remote and local directories, issues an
mput *.* command, and a quit command.
What return code results? Always zero, even if there was a problem.
But OK... you're the package maintainer.... it's your perogative, but to be
fair, I really think you should flag this bug report as "WONTFIX" rather than,
I'm already exercising my perogative with respect to this package now...
WONTUSE, or perhaps CANTUSE.
A program that COULD exit with a meangingful retrun code, but always exists with
zero.... that's a bug.... return codes are useful. :-)
I won't pester you any more on this, but some form of acknowlegement would be