Bug 196141 - ftp client always ends with return code 0
ftp client always ends with return code 0
Product: Fedora
Classification: Fedora
Component: ftp (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Ben Levenson
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-06-21 10:48 EDT by Don Russell
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-09 02:31:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Don Russell 2006-06-21 10:48:28 EDT
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):

How reproducible:

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 $?
Actual results:

Expected results:
500 (perhaps in this case)

Additional info:
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....
Comment 1 Marcela Mašláňová 2006-07-25 09:44:35 EDT
Thanks for bug report. 
Could you say me how did you configure server for using .netrc? I have still
problem. Do you use vsftpd?
Comment 2 Don Russell 2006-07-25 11:39:31 EDT
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:
login username
password sesame

Comment 3 Marcela Mašláňová 2006-07-26 04:23:18 EDT
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
Comment 4 Don Russell 2006-07-26 11:36:10 EDT
(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
> connection. 

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:
login ...
password ...
macdef init
get billy.bob

Then, at the command line:
$ ftp; 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.
Comment 5 Don Russell 2006-07-27 01:41:46 EDT
I meant to reopen this "bug".. see comment #4 above...

Comment 6 Marcela Mašláňová 2006-08-04 08:11:36 EDT
Connected to ...
get billy.bob
local: billy.bob remote: billy.bob
227 Entering Passive Mode (...)
550 Failed to open file.
221 Goodbye.

I think error codes are readeble this way, so I closed the bug.
Comment 7 Don Russell 2006-08-04 09:29:02 EDT
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
appreciated. :-)


Note You need to log in before you can comment on or make changes to this bug.