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): ftp-0.17-32.1.2 How reproducible: Always 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: 0 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....
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: machine 127.0.0.1 login username password sesame
Hello, 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 connection.
(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: machine 127.0.0.1 login ... password ... macdef init status get billy.bob quit 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... Thanks
status Connected to ... ... Macros: init get billy.bob local: billy.bob remote: billy.bob 227 Entering Passive Mode (...) 550 Failed to open file. quit 221 Goodbye. 0 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, "NOTABUG". 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. :-) Cheers, Don