Rick Stevens wrote:
It is not a bug and it is a "won't fix" because it ain't broken. You're trying to use a tool that clearly isn't intended to be used the way you're using it, and that's why ncftp* stuff was written--to provide scriptable and batchable FTP operations. I don't mean to chiding you, but you really should research other things first. If you had done a "makewhatis" on your system, then done a "man -k ftp", you would've found it.
OK... I was just looking for some open discussion..... no offense taken nor meant.
I do use ncftp* now,and have opened an unrelated bug against it (Ref https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200954 )
I am just of the school that return codes (exit codes) from programs should always try to convey some meaning to the caller. (The caller may no be a human reading output to stderr). The caller can always choose to ignore the return code if it is not important (to the caller in the given context). A non-zero return code from an ftp client when the requested function fails seems very desirable to me. The fact the error is reported by the server is moot to me.... the exit code (to me) in this case is for the"process". I want to know the success/failure of the "process".... closer examination of details can then determine which side of the connection the error was detected at.
In this case, ftp even returns zero when it can't connect.....is that a client error or a server error? Maybe neither, it could be a misconfigured firewall in between. Who cares? It can't connect. There's a problem somewhere.
As for using tools in ways they were not intended... um, well... I've never subscribed to that theory as an excuse not to fix (or enhance) something. (with n limits of course.... expecting an ftp client to do something not related to the ftp protocol is a stretch)
I don't know what the programmers of 'ftp' envisioned, but they must have thought some form of scripting would be done... they support macros from the .netrc file. A special macro called init will run upon connection and happily carry out all the commands within that "script", and then, regardless of what happened, exit with 0. To me, that is a "bug" a small one, really RFE.... but worthy of correction.
My opinion.... I've had my say, I've read other peoples opinions, I thank them for them.... That's all fine, we can agree to disagree... and I've had the opportunity to say all I want on the subject.
I'm willing to conform and move on.. :-) Thanks. :-)
