And verily didst John P. Rouillard spake of these matters:
> > > I warn if the keyword isn't registered, ignore it and continue on.
> > >
> > > > In either case, it shouldn't bomb; it should just continue on to the
> > > > next line with a message to the user that it was ignored.
> > Shouldn't this output be returned to the user?
> Well, there is nothing the user can really do about it. What should
> happen is that the error message is sent to the list owner. Just
> haven't gotten a round tuit yet.
I thought we were talking about what error messages occur
when a new configuration setting is sent to Majordomo. In such a
case, the "user" is the person submitting the message. This
will be someone who has the list password: (one of) the owner(s).
In which case any warning messages should be returned to the user.
> > > > Another thing I don't like about having to submit a new
> > > > config file each time is the fact that I'll have to have
> > > > Majordomo send me the current config file, edit it (which
> > > > entails either writing it to a file, editing that, and
> > > > mailing the file, or else using my mailer's Reply command
> > > > and stripping off the leading ">"s on the whole file
> > > > as I edit my reply) and send it back. All to change one
> > > > little value.
***Uh oh, get the fire extinguisher....
> Get a real mailer,
Write a real config command.
> I would suggest MH, although using supercite
> withing emacs would work as well.
Good suggestion. Unfortunately, I don't seem to readily have a
version of MH for the Mac, Vax/VMS, MS-Dos, MCI-Mail, Profs,
CompuServe, or the HP3000. All of which can use every existing
Majordomo command with the mailers they have. What the heck, if
we're going to tell the list owner what mail program to use, why
don't we just limit them to being on the Internet (no, wait, the
NSFNet; no, Tymnet!) so they can log in and change it directly
(but only with ex).
***WHOOOSH!!!! Good thing you had the extinguisher ready. Whoa, did
I really just write that? Better dump a bucket of cold water on me....
> > But a config perl script doesn't help changing the values
> > remotely by e-mail, which remains a big pain in the neck.
> Sure it does
> show <results of config command> |
> config 'moderate = yes' 'advertise = /flooble/'
I like it. How do I use it from my MCI-Mail account? Ooops, I did it again...
> > > Create the file <listname>.closed, now create the file name
> > > <listname>.auto. What happens?? Same problem with the config file. I
> > > bounce it if both auto and closed are defined since the person is
> > > telling me they don't know what the hell they are doing. I can see
> > > similiar conflicting options in many different areas.
> > For example, have a subroutine validate_closed and a subroutine
> > validate_auto. Validate_closed would check its parameters, and
> > also check the current auto flag. If the auto flag is on, validate_closed
> > would turn it off and *tell the requestor that it did so*.
> > Validate_auto likewise would turn off validate_closed and tell the
> > requestor.
> and then regen the config file. Yes that could work, except I would
> prefer to boot the offending command and tell them why I booted it
> rather than "fixing" it for them. For all I know they meant moderated,
> and not closed.
Good point. Have a validate_closed and validate_auto subroutine.
If validate_closed receives an "on" parameter and auto is already on,
reject the closed=on setting and tell the user to turn off auto first.
If validate_auto receives an "on" parameter and closed is already on,
reject the auto=on setting and tell the user to turn off closed first.
Or forget the whole thing and have a new configuration keyword with
three legal values: auto, open, and closed.
Alan Millar amillar@bolis.SF-Bay.org __oo \
System Administrator =___/
If only we were all weiner dogs, our problems would be solved! -Brave Little Toaster