On 11-01-13 19:45, Kevin A. McGrail wrote: > On 1/11/2013 1:10 PM, John Hardin wrote: >> On Fri, 11 Jan 2013, Kevin A. McGrail wrote: >> >>> On 1/10/2013 8:46 PM, jdow wrote: >>>> I'd suggest an option similar to the header option. >>>> >>>> pass_errors 5,18,21,2,6 >>>> ignore_errors 23,3,19 >>> >>> Spamc currently has no options file currently so this is a big change >>> that someone will need to open a bug and likely spearhead with some >>> draft patches. Otherwise, I haven't yet seen the value of this overhaul. >> >> how about: >> >> spamc --pass_errors "5,18,21,2,6" -ignore_errors "23,3,19" ... >> >> ? >> >> > Perhaps but shouldn't it tie into EX_TOOBIG and not a number? > > I think this has merit especially if we can say: > > used to use -x? Use --pass_errors="EX_.., EX_..." and give examples of > old to new.
While this allows for maximum flexibility (great), I'd still nitpick on the fact that anyone technically advanced enough to know which errors can be safely configured to be passed to the caller (and handle them there), would also be capable to write a simple shell wrapper doing the same. Ergo, a simple option that passes everything would do the same. Risking the option I'm sounding a bit like a broken record, I'm just trying to advocate the KISS principle here: all the extra options look like feature creep to me when a clean -x implementation is available. I started on a patch for trunk yesterday, but it's not working yet. As my C skills are not very good, adding something like the --pass-errors= would be out of my league. -- Tom
