Jim Henderson <hende...@gmail.com> posted h0a4mk$ou...@ger.gmane.org, excerpted below, on Fri, 05 Jun 2009 03:50:45 +0000:
> On Thu, 04 Jun 2009 20:27:49 -0700, John Sedore wrote: > >> On Thu, Jun 4, 2009 at 7:23 PM, Jim >> Henderson<hende...@gmail.com> wrote: >>> On Thu, 04 Jun 2009 15:44:27 -0700, John Sedore wrote: >>> >>>> Can anyone tell me how to delete individual groups from the group >>>> list? I'm using version 0.132. >>> >>> Right click, delete the groups' articles, and then unsubscribe from >>> the group. >>> >>> Jim >> >> Thanks Jim! But what if I'm trying to remove groups from the list of >> those available, not just unsubscribing? > > Like Travis said, if it's on the news server, it'll show in either the > subscribed or unsubscribed groups list. You can go in and edit the > newsrc files to remove it, but the next time you refresh the groups from > the server, it'll be added back in. > > But when you unsubscribe, the group is moved from the "subscribed > groups" list to the "other groups" list, so you can collapse that and > not have to look at the groups you don't want to see at least. This is correct. However, regulars here couldn't have seriously expected me to let this go without my take, so here it is... What I originally wondered about the original post (but didn't have time to post a reply to at the time) was /where/ the group was to be deleted from? The news server? *ALL* news servers worldwide? The subscribed group list? Somewhat obviously once you think about it, attempting to "delete individual groups from the group list", where "the" is taken in the context of "the Internet", doesn't tend to work. As has been said many times, "The Internet interprets censorship as damage and routes around it." (John Gilmore, according to wikipedia, see the Streisand effect link below.) Of course, that doesn't keep the censoring types from /trying/, sometimes with a bit of success, see the articles on removal of groups based on the NYAG's supposed kiddy porn content from some time ago. (But no one, least of all the news providers involved, could actually investigate the claims, lest they be guilty of downloading and looking at the stuff themselves, so they had to choose to act or not act based on the NYAG's claims alone... censorship at its best (um... worst)! Also see the Australian efforts and the dental office(!!), etc, that were somehow on the block list there.) Other times it doesn't work so well, see the wikipedia article on the Streisand effect: http://en.wikipedia.org/wiki/Streisand_effect Also of interest is the recent UK attempt to censor/ban an album entry (due to the cover) on Wikipedia itself, see: http://en.wikipedia.org/wiki/Internet_Watch_Foundation#Wikipedia http://en.wikipedia.org/wiki/Internet_Watch_Foundation_and_Wikipedia and the album: http://en.wikipedia.org/wiki/Virgin_Killer Ultimately in that case they backed down with this statement (from the Streisand effect link): "IWF's overriding objective is to minimise the availability of indecent images of children on the internet, however, on this occasion our efforts have had the opposite effect. We regret the unintended consequences for Wikipedia and its users." In fact, as is often the case, it's quite likely WAY more people checked the page and saw the image they were trying to ban as a direct result of the attempt, than would have ever looked at that page and seen the image otherwise. I know I'd have been extremely unlikely to have ever come across it otherwise (tho I'm in the US and thus wasn't affected by the ban), and the same likely goes, now, for many readers of this list. Among other things, it was feature news on all the usual Internet geek and anti-censorship sites, including slashdot.org, arstechnica.com (link wrapped), UK's own The Register, and others: http://yro.slashdot.org/yro/08/12/07/1253228.shtml http://yro.slashdot.org/yro/08/12/09/210230.shtml http://arstechnica.com/tech-policy/news/2008/12/iwf-backs-off-of- scorpions-wikipedia-block-after-criticism.ars http://www.theregister.co.uk/2008/12/07/brit_isps_censor_wikipedia/ http://www.theregister.co.uk/2008/12/10/iwf_reverses_wikiban/ Umm... if you can't tell by now, I'm stridently anti-censorship! =:^) Meanwhile, back to the question. The case of deletion from subscribed groups is simple enough, and has already been covered sufficiently. That leaves the case of deletion from the group list as downloaded from the news service provider. As Jim says, you can hand edit the newsrc files (in the ~/.pan2 directory by default) for the various servers that you have configured, that have the group, and remove the listing there. He also mentions that when you update/refresh the group lists, it'll be back. What he does /not/ say is that in pan, refreshing the group list is always a manual operation (unlike some clients which do it automatically every time you connect, OE comes to mind here). Thus, if you really don't want the thing showing up, and have no reason to refresh the group list to get new groups, just don't. In fact, you could remove the entire list of unsubscribed groups. The newsrc files follow the standard newsrc file format which can be googled, but in short, the group name is immediately followed by the subscribed/ unsubscribed character, a colon (:) for subscribed, an exclamation mark (!) for unsubscribed, then a space and a comma (,) separated list of individual article numbers and ranges. Thus, removing every line without a colon, a simple enough sed operation, should remove every unsubscribed group from the list. Do note that you can't delete the entire newsrc file, or you'll delete pan's tracking of the articles you've seen/read on that server as well as the list of subscribed groups. Without the file, pan will want to download the whole list again, including the groups you wanted removed! Similarly, you can't simply remove the write permissions, as pan then can't update its read-message tracking. If you've visited a group and want to remove all trace of it, in addition to its newsrc file lines, you'll want to remove entries in group- preferences.xml, if any, entries in newsgroups.xov, and the file for the group in the groups subdir. Additionally, downloading the groups list populates the newsgroups.dsc descriptions list and the newsgroups.ynm postings allowed (y), not allowed (n) or moderated (m) list, so regardless of whether you've visited the group or not, you might want to remove the entries there at the same time you remove them from the newsrc files. FWIW, I believe you can set the perms on these last two files read-only, if you don't plan on updating your group list. That should have the effect of eliminating them from the cleanup list if the group list is updated again. You will likely also wish to eliminate any cached messages from that group. A file-content string search for the offending group name in the cache dir should be sufficient to find them. However, since the cache is only 10 MB by default, it won't have a lot of them unless you only do text groups or have manually edited preferences.xml to increase the cache size, since at a 10-meg cache size, binaries from other groups will have likely overwritten most articles from the group in question before too long at all. Meanwhile, as it's conceivable that your reason for doing all this might be over concern for what "little eyes" might see before they're mature enough to handle it, note that it's possible to have multiple pan instances, each with its own configuration. The default configuration is stored in ~/.pan2, but by setting the PAN_HOME environmental variable in the environment pan inherits to point to another location, you can setup as many separate instances/profiles as you wish. Here for example, I have text, test, and bin instances, each with its own separate config. It would be entirely possible to setup a default config stripped of offensive groups and linked from the usual pan launcher icon/menu-item/ whatever, for your child to use, while setting up a short starter script (say pan.adult or whatever) that sets and exports the PAN_HOME var pointing elsewhere, before starting pan. You could then start the "fully loaded" pan.adult (or whatever) from the command prompt or run dialog (but beware run dialog history) without it ever being in the menu or other normal launcher at all, thus yielding a bit of protection for exploring fingers, who presumably don't use the command prompt much at that age. That'll let you have the full list of groups, subscribed or not, in pan.adult, without having them listed for those little eyes. Of course, a better solution might be to setup the kid with his/her own user login, thus their own home dir including their own ~/.pan2 dir as well as letting either you or them configure/customize the rest of their login, entirely separately from your own. But if you let the kids play around on your login, and they aren't old enough to be doing much with the command line yet, the separate pan instances/profiles could be useful, as they are in other cases, like my separate text/test/bin pan instances, here. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
