liz@grian.cps.altadena.ca.us (Liz Allen-Mitchell) (08/07/90)
I ran the checkgroups message from Gene Spafford and got some interesting results. Namely, it mentioned some groups including soc.culture.british as being ones I should remove! Now soc.culture.british is a real group and is in the newsgroups file produced by checkgroups -- still, I was asked to remove it. It wasn't the only one. I looked at the checkgroups code and see that it checks the sys file for a subscription list. Well, soc.culture.british is in my subscription list -- both soc.culture.british and soc.culture.celtic are listed individually. No problem with soc.culture.celtic though. I'm running cnews dated 10-Jan-1990. I don't know if that's the most recent or not. I also can't find a manual entry for checkgroups... Thanks for any help... -- - Liz Allen-Mitchell liz@grian.cps.altadena.ca.us ames!elroy!grian!liz "God is light; in him there is no darkness at all." -- 1 John 1:5b
tale@turing.cs.rpi.edu (David C Lawrence) (08/08/90)
From: liz@grian.cps.altadena.ca.us (Liz Allen-Mitchell)
Date: 7 Aug 90 05:34:47 GMT
I ran the checkgroups message from Gene Spafford and got some interesting
results. Namely, it mentioned some groups including soc.culture.british
as being ones I should remove! Now soc.culture.british is a real group
and is in the newsgroups file produced by checkgroups -- still, I was
asked to remove it. It wasn't the only one.
I don't really know why this is happening. All I can say is that it
doesn't happen to me; anyway ...
I'm running cnews dated 10-Jan-1990. I don't know if that's the most
recent or not. I also can't find a manual entry for checkgroups...
It's not the most recent. 25 May 90 is. I don't think it makes that
much difference though. Geoff is currently working on a better
checkgroups; one thing that has inhibited him, as I understand it, is
that checkgroups behaviour isn't clearly defined. Neither B News nor
C News does that hot a job of it. You haven't found a manual page for
it partially because of it not being a command or something that
manual pages are generally written for (file formats, etc), and
partially because of the afforementioned reason of its ambiguity. Of
course, things like "cancel" and "newgroup" are pretty well understood
by admins as to what they should do (ergo "clearly defined" by
default, even if there is the occasional battle which crops up
regarding propagation of cancels) and they don't have manual pages
either. They are described in RFC 1036. Unfortunately that document
isn't helpful with regard to checkgroups:
3.7. Checkgroups
The message body is a list of "official" newsgroups and their
description, one group per line. They are compared against the list
of active newsgroups on the current host. The names of any obsolete
or new newsgroups are mailed to the user "usenet" and descriptions
of the new newsgroups are added to the help file used when posting
news.
I have a few problems with the way C News does it, and I've been
meaning to write this for Geoff just to have some things to think
about (perhaps one or two here he didn't realise or didn't have any
admin input on). The following comments all relate to C News checkgroups.
One is the way checkgroups mungs the newsgroups file, especially with
regard to the last sentence of the checkgroups description. Arguably
the groups which checkgroups says to create will be created and then
they will indeed be new newsgroups so their descriptions should be in
the active file. Sometimes (usually) though, for me, if the group
isn't there it isn't supposed to be. Take the example of
comp.hypercube, which was renamed to comp.parallel. Occasionally an
admin lets loose a large checkgroups on the net which includes that
old group. I then have to edit out the line which was plunked into
newsgroups. What I would like: include the descriptive line for the
group in the mail notification to the admin. Then if I want to add
the group I can add the newsgroups description at the same time
without having to hunt for it in the checkgroups message. (It would
also be nice if "addgroup" would take a line, either from stdin or the
command line, to add to newsgroups as the description. I frequently
forget to do so when I make a new group.)
Next, I hate the way checkgroups always checks all groups, part of
which supposedly makes the hybridization of the message and the
localgroups and newsgroups files necessary. If I want to do just a
bionet checkgroups, that's it. Compare the bionet groups in the
message with the bionet groups in my active file. Seemingly it should
do this by finding the hierarchies in the message, either by a new
leader line like !mod, a "checkgroups gnu bionet" type Control: header
or just by finding the ^[^.]*. top level names from the message. This
last seems to have the drawback that I couldn't just "checkgroups
comp.sys" if that was all I was after.
checkgroups doesn't check moderated flags. I wish it did. In fact,
checkgroups doesn't care at all about flags. I modified mine to
consider 'x'ed groups as not really there. Ditto on = groups.
(Change the regexp which gets groups in active from
^([^.]*\.|general|junk|control) to ^([^.]*\.[ymn]$|general|junk|control)).)
This cuts down on telling me about groups that I don't really want to
hear about, like telling me to remove "alt.swedish.chef.bork.bork"
when I'm not really getting it anyway. This is a problem, however,
when I have decided to x or = a group which does appear in the
checkgroups message. I guess I like being reminded that I have it
this way, so I am encouraged to re-evaluate why I do, but what should
really be done (ignore it, allow a seperate exclusions file that says
"Yes, I want to x this group permanently and I don't want checkgroups
telling me about it everytime$&#*!", consider them present, whatever).
Because of not checking moderated groups, checkgroups can also make
bogus suggestions to "addgroup news.froup y" rather than "... m".
There is another problem that arises from the mixing of the gene pool
between the message and the *groups files. Say I have a description
for a group but the checkgroups message has a different description
for the same group. Not only do I now have two descriptions of the
group now in newsgroups, but I sometimes can't tell which one is the
newest one without going back to the checkgroups message or
newsgroups.bac to determine it. I think that what I would like in
this case is just a tiny script that gets left in lib, and
notification in the message which says, "Descriptions changed for
these groups: ... Run /usenet/lib/update-desc to apply the changes."
update-desc (or whatever) could then even remove itself when it is
done. :-)
Since admins aren't always on nice window system machines when they
want to make some of the mods suggested by checkgroups, it would be
nice if it left the suggested changes in a file which could be sh'ed
or something. A couple of quick edits to delete the changes not
wanted could be a lot less typing than typing all of the commands to a
shell or trying to extract them from a mail message (which might not
even be on the server to begin with -- mine aren't). What goes hand
in hand with this, especially if checkgroups starts checking moderated
groups, is something that allows the admin to easily switch from a
moderate to a unmoderated group and vice versa -- perhaps even
addgroup not stopping because it found the group in active, but
instead changing its flag to whatever the new one is. Right now when
I get something like the {rec,misc}.fitness thing showing up,
encouraging me to immediately start refiling rec to misc because of
the botch, I locknews and edit the active file. I could also delgroup
and addgroup right back again. Neither is as nice as just saying,
"change it."
--
(setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))cudep@warwick.ac.uk (Ian Dickinson) (08/08/90)
In article <AF0$2'-@rpi.edu> tale@turing.cs.rpi.edu (David C Lawrence) writes: >I have a few problems with the way C News does it, and I've been >meaning to write this for Geoff just to have some things to think >about (perhaps one or two here he didn't realise or didn't have any >admin input on). The following comments all relate to C News checkgroups. I've been thinking about this recently too.... I agree with all of what David says and I have a few teenies to add. I wish I could place a hierarchy in the localgroups file, so I could say 'uw' or 'uw.all' instead of having to list each individual group. The alternative is to make sure a checkgroups message could be limited to the hierarchys mentioned as arguments, or the the hierarchy mentioned within the message. The latter is a botch though, seeing as there would be no way to totally remove a hierarchy. >checkgroups doesn't check moderated flags. I wish it did. In fact, >checkgroups doesn't care at all about flags. I modified mine to >consider 'x'ed groups as not really there. Ditto on = groups. Sounds nice. Unfortunately, rn pl47 does care about flags being more than a single character, and as soon as you set a group to be =othergroup rn thinks that it is bogus - not good :-( Looks like I'd better fix it. Cheers, -- \/ato. Ian Dickinson. GNU's not got BSE. When I grow up I want to be a vato@cu.warwick.ac.uk Plinth. Water Elemental. Shower me! vato@tardis.cs.ed.ac.uk Sabeq. gdd046@cck.cov.ac.uk "Nuke me tender, nuke me good!"
tale@turing.cs.rpi.edu (David C Lawrence) (08/09/90)
In <1990Aug8.113753.3487@warwick.ac.uk> cudep@warwick.ac.uk (Ian Dickinson):
Unfortunately, rn pl47 does care about flags being more than a single
character, and as soon as you set a group to be =othergroup rn thinks
that it is bogus - not good :-( Looks like I'd better fix it.
I was the one who wrote the behaviour that way, and it doesn't have
anything to do with the flag being more than one character. Perhaps
it should be something different, but for how I use = it was totally
appropriate. If I am refiling rec.fitness to misc.fitness, for
example, it means I don't want rec.fitness to appear at my site. So
why should rn think it exists?
(Relevant code sections are in addng.c and ngdata.c, just in case you
want to hack at it anyway.)
--
(setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))andrew@ramona.Cary.NC.US (Andrew Ernest) (08/09/90)
In article <1990Aug8.113753.3487@warwick.ac.uk> cudep@warwick.ac.uk (Ian Dickinson) writes: >Unfortunately, rn pl47 does care about flags being more than a single >character, and as soon as you set a group to be =othergroup rn thinks >that it is bogus - not good :-( Looks like I'd better fix it. I believe rn's behavior is correct. '=' is for making a transition from a recently deleted group to a more appropriate new or existing group. The deleted group should indeed be considered bogus. People should NOT be encouraged to continue reading or attempting to post to that group. -- Andrew Ernest <andrew@ramona.Cary.NC.US>
cudep@warwick.ac.uk (Ian Dickinson) (08/09/90)
In article <}10$6V#@rpi.edu> tale@turing.cs.rpi.edu (David C Lawrence) writes: >I was the one who wrote the behaviour that way, and it doesn't have >anything to do with the flag being more than one character. I should have looked at the code before assuming really :-( >Perhaps it should be something different, but for how I use = it was totally >appropriate. If I am refiling rec.fitness to misc.fitness, for >example, it means I don't want rec.fitness to appear at my site. That's fair enough, but what about a name change of a long established group? >So why should rn think it exists? So that old articles can still be read by people who aren't regular enough readers to have been uptodate when I alias the group. (This worked sensibly when we ran Bnews, using the aliases file) Why should they lose all those articles just because rn won't let them read them? The articles expire soon enough anyway. Cheers, -- \/ato. Ian Dickinson. GNU's not got BSE. When I grow up I want to be a vato@cu.warwick.ac.uk Plinth. Water Elemental. Shower me! vato@tardis.cs.ed.ac.uk Sabeq. gdd046@cck.cov.ac.uk "Nuke me tender, nuke me good!"