On 10-01-13 17:51, Kevin A. McGrail wrote: > On 1/10/2013 11:26 AM, Martin Gregorie wrote: >> On Thu, 2013-01-10 at 15:59 +0100, Tom Hendrikx wrote: >> >>> Since EX_TOOBIG is not really a temporary condition, I'm not sure if >>> that condition and the semantics of -X from the patch actually helps. >>> >>> I'm thinking that it might be better to have a switch with the semantics >>> 'Change all temporary errors to EX_TEMPFAIL' which would change most of >>> the named exit codes in the man page into EX_TEMPFAIL, except when the >>> message should be simply passed through (effectively only EX_TOOBIG). >>> >>> This would do for integration as documented in the bug: >>> - spamc without special switch: exitcode indicates succes (0) or >>> failure (1) >>> - spamc -<new>: exitcode indicates succes (0), failure (1) or retry (75) >>> - spamc -x: always raw exitcode >>> >>> But I guess it depends largely on the setup and the sysadmins opinion >>> whether 'addressee unknown' is a temporary condition, so there is >>> another exception to be handled... >>> >> It seems to me that the set of replies as currently linked to spamc >> options would do a near-prefect job with two minor tweaks: >> >> (1) remove the EX_TOOBIG kludge from --no-safe-fallback so it does >> what it says on ythe tin >> >> (2) use the --exitcode behavior as the default in place of >> --no-safe-fallback >> >> The manpage needs to say that --no-safe-fallback should be used during >> testing and explain that, although it catches more errors, it should >> not be used for production because it treats EX_TOOBIG as an error >> rather than a warning. >> >> Personal opinion: the best approach would be to stick with >> --no-safe-fallback after removing the EX_TOOBIG kludge and for the >> calling script/code to make more detailed exit code checks. However, I >> also realise this change would break a lot of installations, which is >> why I'm suggesting making --exitcode the default in place of >> --no-safe-fallback. > Ignore breaking things because with a major version like 3.4.0, if this > is the "right" thing to do, it's completely feasible and best to do > right now with no delay. > > Overall, what we almost need is "Usage scenarios" and appropriate > parameters. Then we can identify scenarios with missing parameters to > support. > > Or perhaps spamc needs a configuration file to set any and all of the > possible exit levels which would alleviate the need for all these > switches perhaps?
The reason why I proposed a new blanket option was because there are already too many exit code switches to my liking, so I'd rather not introduce a new single use option: my proposal would fit most implementations and would be extensible when new errors should be added (but I did not spend hours to get all usage scenarios imagined). I know see that I already missed the default 'always exit with EX_OK' scenario... Since I wrap spamc with a different programming language, I have all the tools available to handle any error condition: detecting EX_TOOBIG is however not possible. For a short term solution I added my own kludge to fix the existing EX_TOOBIG kludge in spamc: I added '-l' to my spamc arguments, and apply regexp on stderr to catch the 'size exceeded' condition now. This is my usage scenario: if someone wants all error conditions, give him the tools without kludges (and the ability to shoot himself in the foot if he screws up :>). -- Tom
