[ Jason L Tibbitts III writes: ]
>
> >>>>> "DW" == Dave Wolfe <dwolfe@risc.sps.mot.com> writes:
>
> DW> If you use GLOBAL to set defaults, which is what seems to be happening,
> DW> the ordering gets a little confusing.
>
> It isn't for defaults, it's for things that don't make sense to set on a
> per-list basis.
Of course! Then the obvious extension is a 'set*onfig ALL access_table'
at the end of the GLOBAL and list-specific rules to set non-standard
defaults for anything not specifically set.
> although the ill-named access, which is intended to control whether or
> not Majordomo even responds to the mail, isn't a per-list value.
So to keep everyone at intel.com (but only intel.com) out of a specific
list, I'd have to list all possible requests? Or can I use ALL in that
context?
set*onfig moto_list access_table << END
ALL
ignore notify=OWNER
/.*\bintel\.com$/i
END
Having to list all the actions could suffer a lot of breakage when a
new request is added.
[ Problems with list delimiters, multiple line fields, continuation lines. ]
> That's the problem with the syntax I'm proposing. It's too dependent on
> whitespace and line counts. Perhaps something that looks more like a
> header:
[ deleted ]
Then there's always the old Windoze .ini, AIX, or httpd file formats.
No, really. Someone recently submitted an .ini config file module to
CPAN.
.ini:
-----
[paragraph identifier]
keyword=value
...
AIX:
-----
* standard c compiler
xlc: use = DEFLT
crt = /lib/crt0.o
mcrt = /lib/mcrt0.o
gcrt = /lib/gcrt0.o
libraries = -lc
proflibs = -L/lib/profiled,-L/usr/lib/profiled
options = -H512,-T512,-D_ANSI_C_SOURCE,-qansialias
[...]
* common definitions
DEFLT: xlc = /usr/lpp/xlc/bin/xlcentry
as = /bin/as
ld = /bin/ld
options = -D_IBMR2,-D_AIX,-D_AIX32,-bhalt:4
ldopt = "b:o:e:u:R:H:Y:Z:L:T:A:V:k:j:"
httpd:
-----
AuthUserFile /xxx/xxx/httpd/permit/.htpasswd
AuthGroupFile /xxx/xxx/httpd/permit/.htgroup
AuthName ByPassword
AuthType Basic
<Limit GET POST PUT>
require user dwolfe
</Limit>
Makes *my* stomach hurt. Maybe I shouldn't have eaten lunch while
thinking about this stuff. :-b
> Another thing to consider is what happens to multiple regexps:
>
> deny
> /^dwolfe/i
> /dave\.wolfe/i
>
> Are they 'or'ed or 'and'ed? 'or' makes more sense for this example,
Especially considering that 'and' makes *no* sense...
> but if we have conditions other than addresses:
>
> subscribe
> consult (defaults to list-owner)
> /.*aol\.com$/i
> SUBSCRIPTION_ADDRESS_DIFFERENT_FROM_REQUEST_ADDRESS (or whatever)
>
> then you want an 'and'ing.
I'll take it as a given that you want 'and'ing in this example...
Negated conditions come into play here too. How about using a keyword
here too?
subscribe
consult OWNER
NOT /\bsps\.mot\.com$/i
AND NOT /\bmcu\.mot\.com$/i
OR ADDRESS_MISMATCH
Absence of a logic keyword would imply 'OR', so unadorned sequences of
regexes would still be 'OR'ed.
--
Dave Wolfe
Follow-Ups:
References:
|
|
