http://bugzilla.spamassassin.org/show_bug.cgi?id=3077
Summary: RFE: have spamassassin accept -p /dev/null without
complaint
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P5
Component: spamassassin
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
While testing 'spamassassin -d', I found that I could make it go faster by
specifying a null config directory and an empty user_prefs (though this would
necessarily lose SA's ability to rewrite headers that it had previously
modified based upon user header tag directives):
spamassassin -d -L -C empty -p prefs
(where 'empty' is an empty directory and 'prefs' is an empty plain file).
Since it is inconvenient to create an empty directory and an empty file,
I also tried this:
spamaassassin -d -L -C /dev/null -p /dev/null
which happens to work for -C because /dev/null is not a directory, but
leads to this message for -p:
Cannot write to /dev/null
This occurs because of the following logic:
1471 if (!-f $fname)
1472 {
1473 # Pass on the value of $userdir for virtual users in vpopmail
1474 # otherwise it is empty and the user's normal homedir is used
1475 $self->get_and_create_userstate_dir();
1476
1477 # copy in the default one for later editing
1478 my $defprefs = $self->first_existing_path
(@Mail::SpamAssassin:: default_prefs_path);
1479
1480 if (open (IN, "<$defprefs")) {
At line 20 the test is for plain file (-f) rather than exists (-e).
Since the within the body of 'if' is to create the user_prefs file,
I think that the code should use -e instead.
For both the -C and -p switches, it might be clearer if they accepted
"" as meaning <none>, rather than using the /dev/null artifice however.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
