X-PMC-CI-e-mail-id: 8738
A few months ago, I reported a problem of
majordomo not accepting "newconfig list password" anymore.
I had not used that feature for several months then
and so was not quite sure what went wrong.
I even checked the perl versions and re-ran the
configuration checker to no avail.
The returned error message was something like the following.
>>>> newconfig sample foobar
The new config file for sample was NOT accepted because:
close at line 384 is not a valid value.
Valid values are: open;closed;auto;open+confirm;closed+confirm;auto+confirm
*BUT* there was *NO* `close' (note misspelling) or whatever in the new
config contents I tried sending back to majordomo account.
Well, now I am on summer vacation and guess what.
I used my first day
to track down the problem and found there seems to be
a problem in config_parse.pl.
After adding a more context information such as the $key value
to the error message,
I found that it was choking on
`subscribe_policy' line.
This was way off the line reported by majordomo.
And again, I had not used
`close'on this line!
Then after looling at the code in grab_enum routine in config_parse,
I noticed that there is a strange eval() code.
So I checked the setting of subscribe_policy key:
'subscribe_policy', "open\001closed\001auto\001open+confirm\001closed+confirm\001auto+confirm\001#!\$default_subscribe_policy ? \$default_subscribe_policy : 'open'",
Ok, so majordomo tries to eval
$default_subscribe_policy ? $default_subscribe_plicy : 'open'
My conclusion, this $default_subscribe_policy is
misset somewhere in my configuration as 'close' as opposed to
'closed'.
But the nasty problem is config_parse.pl doesn't report this
properly!
My brutal fix to config_parse.pl.
Force default_subscribe_policy.pl to "closed" in
grab_enum() to err on the safe side.
diff -c config_parse.pl{.save,}
*** config_parse.pl.save Wed Aug 12 07:25:39 1998
--- config_parse.pl Wed Aug 12 07:25:49 1998
***************
*** 1009,1016 ****
--- 1009,1020 ----
$value = pop(@enum);
if ( $value =~ s/^#!// ) {
+ #
+ $default_subscribe_policy = "closed";
+
$value = eval("$value");
push(@errors, $@) if $@ ne "";
+
}
} else {
***************
*** 1021,1027 ****
return $value if $value eq $i;
}
push(@errors, "$value at line $. is not a valid value.\n" .
! "Valid values are: " . join(';', @enum) . "\n");
return "";
}
--- 1025,1033 ----
return $value if $value eq $i;
}
push(@errors, "$value at line $. is not a valid value.\n" .
! "Valid values are: " . join(';', @enum) . "\nlist was $list" . " the key was $key " . "\n" . "installing_default was $installing_defaults" . "\n");
!
!
return "";
}
Yes, the culprit was
----
egrep close majordomo.cf
$config'default_subscribe_policy = "close";
----
The above line ought to read "closed".
But, config_parse.pl ought to be capable of analysing the
buggy situation a little better, I think.
Thank you for some hints and tips after I reported the problem.
The problem and cause was as outlined above and
my fixed majordomo happiliy accepts the
newconfig command.
--
Ishikawa, Chiaki ishikawa@personal-media.co.jp.NoSpam or
(family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
Personal Media Corp. ** Remove .NoSpam at the end before use **
Shinagawa, Tokyo, Japan 142-0051
|
|