Bug 5137 - spamd options - order seems to be important
Summary: spamd options - order seems to be important
Status: RESOLVED WORKSFORME
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: 3.1.4
Hardware: Other Solaris
: P4 minor
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-19 04:42 UTC by Paul McIlfatrick
Modified: 2022-04-29 03:48 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Paul McIlfatrick 2006-10-19 04:42:31 UTC 
Tried to get spamd to create a pid file.

The following order of options did NOT work:

/usr/perl5/bin/spamd -u mail -d -r /etc/exim/spamd.pid --syslog-socket=inet &

Experimented and found that the following worked:

/usr/perl5/bin/spamd -u mail -r /etc/exim/spamd.pid -d --syslog-socket=inet &


Surely the order of options should not matter?
Comment 1 Theo Van Dinter 2006-12-05 12:24:37 UTC 
Hrm.  The order shouldn't matter for options.  SA just calls
Getopt::Long::GetOptions() to deal with the commandline though, so I don't think
there's anything from a SA perspective here if there's misparsing going on.  If
this is still occurring, I'd try upgrading the Getopt::Long module, and then if
that didn't change anything, go debugging in spamd to see if the module is
parsing correctly.
Comment 2 Sidney Markowitz 2022-04-29 03:48:44 UTC 
close old bug that was never confirmed