bill@persci.UUCP (07/23/85)
I have run into a slight problem with 'rn'. I haven't figured out how to re-read a newsgroup yet (I'm sure it's in the documentation, but I haven't ferreted it out yet), so I have had to use > %readnews -x -r -n newsgroup to re-read articles in specific groups. (If someone knows how to do this in rn, please let me know..) Yesterday, I got an error message from readnews, saying 'line too long'. I exited and tried to check my .newsrc with vi, only to get the same message! I was surprised to see how rn collects article numbers (I had a *LOT* of gaps in the sequencing in a number of newsgroups, causing a very long list of read articles to be generated. Not finding anything in the documentation on how to clean this up, I wrote the following script to do the job: > #!/bin/csh -f > sed 's/^\([^ ]* [0-9]*\)[,-].*[,-]\([0-9]*\)$/\1-\2/' <.newsrc >.tmpnewsrc > /bin/mv .newsrc .oldnewsrc > /bin/mv .tmpnewsrc .newsrc (This script takes a list of numbers, separated by commas or dashes, and replaces the list with the first and last numbers, separated by a dash.) It worked (just fine), but seemed like a kludge. Mt question is, can rn do this same kind of cleanup (so I don't have to run this script periodically), or am I doing something wrong with rn that it generates long lists of marked articles? Also, what are the commands to read an already read newsgroup, in reverse, as in '%readnews -x -r -n newsgroup' (without editing .newsrc)?
lwall@sdcrdcf.UUCP (Larry Wall) (07/26/85)
In article <261@persci.UUCP> bill@persci.UUCP (Bill Swan) writes: >I have run into a slight problem with 'rn'. I haven't figured out how to >re-read a newsgroup yet (I'm sure it's in the documentation, but I haven't >ferreted it out yet), so I have had to use >> %readnews -x -r -n newsgroup >to re-read articles in specific groups. (If someone knows how to do this >in rn, please let me know..) There are several ways to read previously read articles in rn. 1) Use the 'P' command to backup one article at a time. 2) If you know the article number you want, just type the number. 3) If you know the subject you want, just type "?subject?r<CR>". (And "?<CR>" thereafter.) Starting at "end of newsgroup" you can go forward to the first article with "/subject/r". You can use modifiers on the search command to search the whole header or the whole article. 4) Use "1-$m" to mark everthing unread. 5) Use "/pattern/rm" or "?pattern/rm" to mark articles matching pattern as unread. 6) Edit your .newsrc and remove the list of numbers. >Yesterday, I got an error message from readnews, saying 'line too long'. I >exited and tried to check my .newsrc with vi, only to get the same message! >I was surprised to see how rn collects article numbers (I had a *LOT* of >gaps in the sequencing in a number of newsgroups, causing a very long list >of read articles to be generated. Not finding anything in the documentation >on how to clean this up, I wrote the following script to do the job: >> #!/bin/csh -f >> sed 's/^\([^ ]* [0-9]*\)[,-].*[,-]\([0-9]*\)$/\1-\2/' <.newsrc >.tmpnewsrc >> /bin/mv .newsrc .oldnewsrc >> /bin/mv .tmpnewsrc .newsrc >(This script takes a list of numbers, separated by commas or dashes, and >replaces the list with the first and last numbers, separated by a dash.) >It worked (just fine), but seemed like a kludge. It is a kludge, and destroys information as to what you have or haven't read. The long lines arise because of cross referenced articles being marked as read in newsgroups that you don't read often. You aren't doing anything wrong--the lines are long (in part) because they contain information which you will be QUITE thankful for when you eventually visit the newsgroup. Rn doesn't care how long the lines get; it can read them as long as you have more memory. Unfortunately the lines may get too long for readnews to use, as you have noted. The pat answer is to tell you not to use readnews. I'm not going to tell you that, since one of my stated goals has always been to try to remain compatible in the .newsrc with readnews. In fact, what's going on is that rn is TRYING to shorten those lines, but is being stymied by a problem with expire. When rn goes to add a cross reference to a line for the first time in a session, it checks to see if any articles have expired in that newsgroup, and if so, whether it can consider those expired articles as read. The way it determines what articles have expired is by reading the minimum article number from the active file. Now, if expire is working right, the longest a line ordinarily gets in even a VERY active newsgroup that you NEVER read is 400 or 500 bytes--easily handlable by readnews. Unfortunately, as noted by Rick Adams a few days ago, if inews/rnews runs while expire is running (which often happens if you get batches of articles in the middle of the night), the articles are installed in the news directories but are not recorded in the history file or in the active file. The fact that the active file is wrong doesn't much matter because the article really is out there, and as soon as another article comes into that newsgroup, inews skips those article numbers and they magically reappear. (This can lead to occasional spurious "Corrupt Xref" messages, though.) The fact that the history file is wrong is less innocuous, in that expire uses the history file to decide what articles need expiring, and if an article isn't in the history file, it ordinarily doesn't get expired, ever. So you get stranded articles, often 2 or 3 in a row, with tens of expired articles after them. This also has the effect that the minimum article number stored in the active file stays artificially low. This in turn causes the lines in your .newsrc file to grow, because rn thinks it has to remember more. There are several possible solutions that I see: 1) Don't use readnews. 2) Using rn, go to the newsgroup with the long line and read the first few "stranded" articles, until rn skips the unavailable articles. Then you can exit and use readnews. 3) Teach rn to look for expired articles with numbers greater that the minimum article number as revealed by the active file. 4) Run expire with the option that makes it examine the actual news heirarchy for articles to expire. 5) Install the expire shell script that Rick sent out which prevents article stranding by temporarily shunting incoming articles off to the side. I already said I won't recommend #1, though others are more partisan than I am. #2 works, but is sort of a pain, and only treats the symptoms to boot. #3 is much too inefficient to impose on every news reader on the machine. #4 works but makes expire take much, much longer. #5 is the best solution by my lights. In case you missed it, Rick's shell script is at the end of this article. Larry Wall {allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall ------------------------------------------------------------------ Currently if inews/rnews is running when expirs is running you MAY loose some articles from the history file. Here is the shell script I run from crontab to do the expiring. It works. ---rick #! /bin/sh # This is how I do it on seismo. umask 002 # Prevent additions to history file while expire is running mv /usr/bin/rnews /usr/bin/rnews.x echo 'exec cat >/usr/spool/news/rnews.$$' >/usr/bin/rnews chmod 4755 /usr/bin/rnews /etc/chown news /usr/bin/rnews # actually expire the articles cd /usr/lib/news /usr/lib/news/expire -v2 # get a fresh logfile cd /usr/spool/log mv news.5 news.6 mv news.4 news.5 mv news.3 news.4 mv news.2 news.3 mv news.1 news.2 mv news.0 news.1 mv news news.0 cp /dev/null news /etc/chown news news* # turn rnews loose mv /usr/bin/rnews.x /usr/bin/rnews cd /usr/spool/news for i in rnews.* do /usr/bin/rnews <$i rm -f $i done