bugzilla escalation process (is there one) ?

[Don Russell]

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. :-)