Trn 3.0 has been released
Wayne Davison
It is now residing on ftp.uu.net in the /news/readers/trn directory:
ftp.uu.net:/news/readers/trn/trn-3.0.tar.gz (or .Z)
with the mthreads thread-manager released as a separate package:
ftp.uu.net:/news/readers/trn/mthreads-3.0.tar.gz (or .Z)
Trn is a threaded newsreader that uses the References line of each
article to group the articles into actual reply order. It can access
articles directly or via NNTP with thread data coming either from
mthreads-generated thread files (local or XTHREAD-NNTP), news overview
files (local or XOVER-NNTP), or on-the-fly reading of the articles.
Trn also has a thread/subject/article selector that makes it easier to
browse through a high volume group and select just the articles that
look interesting.
There's been quite a few changes from trn 2.5. The following list is
taken from the NEW file, included with trn:
o Trn is now capable of reading more news database formats. It
currently supports news overview (.overview files), mthreads
(.thread files), and direct threading of the articles. The
NNTP version supports the XTHREAD and XOVER NNTP extensions.
If you compile trn with support for both formats it will figure
out which groups (or which server) has which type of data and
act accordingly.
o Mthreads is now a separate package from trn since not everyone
will need to use it. Look for it in the same place you found
trn.
o Trn attempts to build some useful default macros for your
terminal's arrow keys. On the article level they move around
in the thread; in the selector they change pages (left/right)
and switch selections (up/down); on the newsgroup level they
move by group (up/down) and enter a group (right). If you
don't like this, turn it off with the +A option.
o There's a new search scope -- the from line. For example:
use /author/f+ to search for and select 'author's articles.
o The thread selector has been extended to be a subject and
article selector. Use the 'S'et selector command to change
modes or use '=' to toggle between the article selector and
the subject/thread selector (whichever was last in use).
o The selector can now be sorted in a variety of ways: by date,
subject, author, article count (in the subject/thread selector),
or a combination of subject and date (in the article selector).
The default is date order of the oldest unread article in a thread.
Use the 'O'rder command to pick a new one or use 'R' to reverse
the sort. See also the "-O<mode><order>" option to set your
favorite mode and order. You can even put a "&-Oas" command (for
example) into a group's kill file to set a per-group default.
o The selector allows you to exclude all the non-selected articles
from the display (i.e. narrow it) -- use 'E' to toggle this mode.
o The selector has two new selection commands: '*' is used to select
(or deselect) the current item and all other items with the same
subject (useful in the article selector); '#' is used to make an
overriding selection that immediately reads the current item
ignoring all other selections.
o You can now type 'M' in the selector to mark the current item's
articles as read-but-returning and press 'Y' to yank back and
select these articles before exiting the group.
o Selections via searches are article-oriented (/subj/+) or
thread-/subject-oriented (/subj/++). The article selector's
default command is "+", while the thread/subject selector's is
"++". In other words doing a "/subj" search with no specified
command selects whatever type of object you're looking at in the
selector.
o If you specify the "-p" option, your postings and any replies to
them are auto-selected whenever trn encounters them.
o The '+' command in a non-threaded group visits the subject selector.
You can also use "_a", "_s", "_t" or "_T" to force the article,
subject, thread, or thread-but-I'll-settle-for-subject selector.
o The selector displays subjects/threads that are partially-selected
with a '*'. Fully-selected items are marked with a '+', as before.
Use the article selector (possibly with 'E'xclusive set) to see
which articles are selected in a partially-selected group (or just
read them).
o The selector remembers which subjects you selected (and didn't kill)
and marks any newly-arriving articles in these subjects as selected
until you exit the group.
o The medium display mode of the thread selector has been improved
to make it more readable.
o The selector will leave out the middle portion of a subject that is
too long to display the last two words of the subject. If you don't
like this, use the -u option to leave them unbroken.
o 'T'hread KILL commands now use message-ids to either junk
or select articles. The 'T' command has been extended to be
more flexible on the article level and has been added to the
selector.
o Another new command 'A'dds selection or kill commands to the KILL
file, and works from both the article level and the selector.
o The tree display has been updated to display unread-but-not-
selected articles as <x>. Other unread articles are still [x],
while read articles still display as (x).
o Trn can enter a group without thread information available and
thread it in the background while you read. Articles that have
references that may or may not exist show up as "(?)". If you
visit an article like this and wait there, the screen will update
when we know for sure one way or the other (after processing more
of the group).
o The -a option is used to tell trn to thread all of the
articles on entry to the group. If you don't specify this
option a group may have a few (or many) articles that get
threaded in the background and won't show up on the tree
display until trn processes them.
o Pressing "_+" on the article level will select the entire thread
associated with the current article -- useful if you've selected
individual articles and wish to read the rest of the discussion.
Use "_-" to deselect the current thread.
o The commands _N and _P move to the next and previous article
in numerical (arrival) order (article level). Thus, you can
use the command "._P" on the newsgroup level to start reading
a group from the very last article to arrive.
o The 't' command on the newsgroup level now turns OFF reading a
group with threads (this setting is stored in the .newsrc file,
so it is remembered from session to session). Trn 2.x used this
to force threading to be turned ON, but it wasn't usually needed
for normal operation. To temporarily turn threads on once inside
a non-threaded group, use the 't' or "_t" commands (article level)
or the "St" command (selector).
o Trn now checks for the environment variable TRNMACRO on startup
(which defaults to DOTDIR/.trnmac) before checking for the usual
RNMACRO (DOTDIR/.rnmac) file. If you're running trn in its rn-
compatible mode, only RNMACRO is tried.
o The threaded and non-threaded data in a group has been unified,
resulting in more cached information on the non-threaded side
(such as the from line) and more efficient handling of missing
articles, just to name two benefits.
o The newsgroup information is freed when we enter a new group,
not when we exit the current group. This means that if you
quit out of a group (even accidentally), you can go back in
and everything is still there except the selections, which
get cleared on group exit.
o KILL file processing will now ignore the THRU line as much as
possible without slowing down the handling of KILL files.
If you have really slow searches (header or article searches)
or you use trn without a database it will use the THRU line
to only search an article one time (as it would in rn). This
means that if you have subject-oriented selection commands you
don't have to worry about missing articles if you don't read all
of them the first time you enter a group after they arrive. This
also means that you won't have to edit your local kill file to
remove the THRU line to force a re-scan -- this is now unnecessary.
o Header parsing is now done in-memory, making threading and
caching of articles much faster. This especially helps out
NNTP users because trn used to write a tmp file for every
header parse.
o Several new mode letters (accessed by %m in macros) were added.
The most significant are 'f' for the end (Finis) of the newsgroup
selection level (instead of 'n') and 'e' for the end of the article
reading level (instead of 'a').
o A new % modifier has been introduced: "%:FMTx". This allows you
to apply a printf-style column format to a regular %x expansion.
For example, %:-50.50s would left-justify the subject into 50
characters, exactly.
o The -f option will make trn go a little faster by getting rid of the
delay/prompt after kill file processing, printing the "skipping
article" message, and printing the "Depositing KILL command" message.
This is the default if -t (terse) is specified, but can be overridden
by specifying +f after the -t option.
o A new option for the gadget-conscious (-B) displays a spinner when
trn is processing articles in the background.
o Added the -G option to make the newsgroup 'g'o command look for
near matches (for those typing mistakes).
o New newsgroups that are left unsubscribed are not appended to the
.newsrc unless you use the -I option or you're running an NNTP
version that does not use the NEWGROUPS code.
o Support for metamail's mime handling is now built into the code --
see the METAMAIL define in common.h.
o Pnews does more checking of your article before posting, has a
spelling-check option, and allows the Cc: header to be used to
send mail while posting the article.
I'll be posting a shar'ed version of trn to comp.sources.unix in the near
future.
--
Wayne Davison
dav...@borland.com
Guy Middleton
the articles already in our news spool, but rather just added the code to
cnews, and let the files build up normally.
Because of this, trn has to read article headers to build its thread trees,
in this loop from ov_data() in rt-ov.c:
for (an = first, ap = article_ptr(an); an <= artnum; an++, ap++) {
if (!(ap->flags & cachemask)) {
#ifdef USE_NNTP
onemissing(ap);
#else
(void) parseheader(an);
#endif
}
}
This take a *long* time. It would be good if we could give the user some
idea that we are doing something. It looks like the 'spin()' routine would
be good for this, and there is a call to spin() in pareseheader(), but I
can't see anything happening.
Wayne Davison
> As recommended by the cnews-NOV docs, I didn't create .overview files for all
> the articles already in our news spool, but rather just added the code to
> cnews, and let the files build up normally.
If you do this, I would recommend not attempting to use the files until
they have built up a bit more -- until then they aren't extensive enough
to be useful.
> Because of this, trn has to read article headers to build its thread trees,
> in this loop from ov_data() in rt-ov.c:
This is a loop designed to fill in quirks in the overview data, not to
read whole ranges of articles. It was definitely not prepared to handle
the situation where whole sections are missing from the beginning of the
overview file (it actually handles overview files that aren't up to date
at the end, though).
I will see about making it handle this case better in the future, but
until then I'd recommend building all your overview files -- I think
it's worth the effort. After your overview files are in place I think
you'll find the code will perform quite nicely.
..wayne..
David Myers
dav...@borland.com (Wayne Davison) writes:
> After your overview files are in place I think you'll find
> the code will perform quite nicely.
It sure does! Nice job, Wayne. Thanks.
--
David Myers "You guys listen to managers (513) 865-1343
Mead Data Central much too often." Fabrication Systems
P.O. Box 933 My manager d...@meaddata.com
Dayton, Ohio 45401 2/5/93 7 ...!uunet!meaddata!dem
Guy Middleton
> In article <C8AGx...@borland.com>,
> dav...@borland.com (Wayne Davison) writes:
>
> > After your overview files are in place I think you'll find
> > the code will perform quite nicely.
>
> It sure does! Nice job, Wayne. Thanks.
Yes indeed, it's noticeably quicker than trn 2.0.
But I now have more nits to pick. Why does Configure insist that I give full
pathnames for "more", "vi", and "ispell"? I tried it without, and everything
works fine.
We would rather rely on $PATH to find binaries, since we compile the programs
once, and distribute to a large number of machine, some of which may have
private copies of these programs.
Guy Middleton
Check spelling, Send, Abort, Edit, or List?
question, especially since the keywords are capitalized in the question
itself.
*** 1.1 1993/06/09 16:32:52
--- Pnews.SH 1993/06/09 16:35:37
***************
*** 392,401 ****
read ans
case "$ans" in
! a*)
state=rescue
;;
! e*)
set $ans
case $# in
2) VISUAL="$2" ;;
--- 392,401 ----
read ans
case "$ans" in
! [aA]*)
state=rescue
;;
! [eE]*)
set $ans
case $# in
2) VISUAL="$2" ;;
***************
*** 402,415 ****
esac
state=edit
;;
! l*)
$pager $tmpart
state=ask
;;
! s*)
state=send
;;
! c*)
$speller $tmpart
state=ask
;;
--- 402,415 ----
esac
state=edit
;;
! [lL]*)
$pager $tmpart
state=ask
;;
! [sS]*)
state=send
;;
! [cC]*)
$speller $tmpart
state=ask
;;
Guy Middleton
One of our users posts messages in which the From: line is
From: "Joe User (Joe)" <ju...@watdragon.uwaterloo.ca>
This is a legal RFC-822 address, so the news software should be able
to handle it. When we try to reply to it, trn replies instead to
To: "Joe User
Since our mailer understands Internet addresses, it should be safe to reply
to the "From:" line directly, rather than to trn's stripped "To:" line:
*** 1.1 1993/06/07 19:42:20
--- common.h 1993/06/09 16:50:05
***************
*** 536,544 ****
#ifdef INTERNET
# ifndef MAILHEADER /* % */
# ifdef CONDSUB
! # define MAILHEADER "To: %t\nSubject: Re: %S\n%(%{REPLYTO}=^$?:Reply-To: %{REPLYTO}\n)Newsgroups: %n\nIn-Reply-To: %i\n%(%[references]!=^$?References\\: %[references]\n)Organization: %o\nCc: \nBcc: \n\n"
# else
! # define MAILHEADER "To: %t\nSubject: Re: %S\nNewsgroups: %n\nIn-Reply-To: %i\nReferences: %[references]\nCc: \nBcc: \n\n"
# endif
# endif
#else
--- 536,544 ----
#ifdef INTERNET
# ifndef MAILHEADER /* % */
# ifdef CONDSUB
! # define MAILHEADER "To: %f\nSubject: Re: %S\n%(%{REPLYTO}=^$?:Reply-To: %{REPLYTO}\n)Newsgroups: %n\nIn-Reply-To: %i\n%(%[references]!=^$?References\\: %[references]\n)Organization: %o\nCc: \nBcc: \n\n"
# else
! # define MAILHEADER "To: %f\nSubject: Re: %S\nNewsgroups: %n\nIn-Reply-To: %i\nReferences: %[references]\nCc: \nBcc: \n\n"
# endif
# endif
#else
Guy Middleton
Guy Middleton
is another trn running. On our MIPS box, SIGEMT and SIGXCPU are the same
thing, and SIGEMT can't be ignored. Anyway, kill(0) is intended for just
this use, why not use it?
*** 1.1 1993/06/09 17:00:12
--- init.c 1993/06/09 17:02:47
***************
*** 215,223 ****
#ifdef TERSE
printf("Trn left running, #%d.\n", processnum) FLUSH;
#endif
! if (kill(processnum, SIGEMT)) {
/* does process not exist? */
- /* (rn ignores SIGEMT) */
sleep(2);
#ifdef VERBOSE
IF(verbose)
--- 215,222 ----
#ifdef TERSE
printf("Trn left running, #%d.\n", processnum) FLUSH;
#endif
! if (kill(processnum, 0)) {
/* does process not exist? */
sleep(2);
#ifdef VERBOSE
IF(verbose)
*** 1.1 1993/06/09 16:58:17
--- final.c 1993/06/09 16:59:09
***************
*** 49,60 ****
#endif
#ifdef SIGWINCH
sigset(SIGWINCH, winch_catcher);
- #endif
-
- #ifndef lint
- #ifdef SIGEMT
- sigignore(SIGEMT);
- #endif
#endif
#ifdef DEBUG
--- 49,54 ----
Guy Middleton
gamiddle@/software/trn-3.0/data/whoami != gami...@math.uwaterloo.ca (Guy Middleton)
Not your article
/software/trn-3.0/data/whoami is the name of the data file that contains the
hostname.
The following patch to intrp.c fixes this. The important thing is to move
the savestr(buf) to the end of the function; otherwise buf's contents are
never used.
I didn't understand what all the index() stuff does, so I just removed it.
It may have do something useful in the cases where the hostname is derived
from uname() or gethostname().
*** 1.1 1993/06/09 18:29:06
--- intrp.c 1993/06/09 18:50:38
***************
*** 177,192 ****
# endif /* PHOSTCMD */
# endif /* HAS_UNAME */
#endif /* HAS_GETHOSTNAME */
- if (*buf) {
- char *cp = index(buf,'.');
- if (cp)
- *cp = '\0';
- cp = index(phostname,'.');
- if (cp)
- strcat(buf,cp);
- phostname = savestr(buf);
- }
}
}
/* expand filename via %, ~, and $ interpretation */
--- 177,185 ----
# endif /* PHOSTCMD */
# endif /* HAS_UNAME */
#endif /* HAS_GETHOSTNAME */
}
+ if (*buf)
+ phostname = savestr(buf);
}
/* expand filename via %, ~, and $ interpretation */
Rich Salz
> From: "Joe User (Joe)" <ju...@watdragon.uwaterloo.ca>
>This is a legal RFC-822 address, so the news software should be able
>to handle it.
Sorry, but no. RFC1036 severely limits the format of From lines:
brackets. Thus, the three permissible forms are:
Horton & Adams [Page 3]
RFC 1036 Standard for USENET Messages December 1987
From: ma...@cbosgd.ATT.COM
From: ma...@cbosgd.ATT.COM (Mark Horton)
From: Mark Horton <ma...@cbosgd.ATT.COM>
Wayne Davison
> I think trn should use kill(0) rather than kill(SIGEMT) to see if there
> is another trn running.
I see no problem making the change. Does anyone else know why kill(SIGEMT)
might be preferable to kill(0)?
> Anyway, kill(0) is intended for just this use, why not use it?
I have wondered that myself -- I guess we'd have to ask Larry Wall why he
did things this way in the original rn.
..wayne..
Raphael Manfredi
:gami...@math.uwaterloo.ca (Guy Middleton) wrote:
:> Anyway, kill(0) is intended for just this use, why not use it?
:
:I have wondered that myself -- I guess we'd have to ask Larry Wall why he
:did things this way in the original rn.
Probably because kill(0) was not available widely at the time he wrote it.
Some systems still do not support this feature, and metaconfig has a symbol
to deal with that.
However, the probability of seeing a system without kill(0) and with a
broken SIGEMT should be rather low...
--
Raphael Manfredi <r...@acri.fr>
Advanced Computer Research Institute
1, boulevard Marius Vivier-Merle / Tel +33 72-35-80-55 \
69443 Lyon Cedex 03, FRANCE \ Fax +33 72-35-84-10 /
Bruce Lilly
posted to news.software.readers,news.software.nntp,
gami...@math.uwaterloo.ca (Guy Middleton) wrote:
>One of our users posts messages in which the From: line is
>
> From: "Joe User (Joe)" <ju...@watdragon.uwaterloo.ca>
>
>This is a legal RFC-822 address, so the news software should be able
>to handle it. When we try to reply to it, trn replies instead to
>
> To: "Joe User
>
>Since our mailer understands Internet addresses, it should be safe to reply
>to the "From:" line directly, rather than to trn's stripped "To:" line:
%f might or might not be OK; I haven't checked exactly where it
comes from. Note that you do not want to blindly use the address
in the original article's From: header; if the article contains
a Reply-To: header, that should be used in preference to From:.
See RFC822 section 4.4.4 and Appendix A.
IMHO, it would be better to fix whatever is broken so that in
the example above the address is not prematurely truncated.
--
Bruce Lilly ...uupsi!monymsys!sonyd1!blilly!bruce
Wayne Davison
> Note that you do not want to blindly use the address
> in the original article's From: header; if the article contains
> a Reply-To: header, that should be used in preference to From:.
Trn has been doing this for a LONG time (ever since it was rn :-).
> IMHO, it would be better to fix whatever is broken so that in
> the example above the address is not prematurely truncated.
I've fixed this for the next release so that the "<...>" portion of an
address is used in preference to any other piece of the address.
..wayne..
Larry Wall
Yikes, that's ancient history. When rn was written, many systems
didn't support kill(0) to test for process existence. I believe it was
a Berkeley innovation that, FOR SOME PECULIAR REASON, was slow to
diffuse to other varieties of Unix.
Larry Wall
lw...@netlabs.com
Bruce Lilly
posted to news.software.readers,news.software.nntp,
dav...@borland.com (Wayne Davison) wrote:
>I see no problem making the change. Does anyone else know why kill(SIGEMT)
>might be preferable to kill(0)?
If trn is not set up to catch SIGEMT (i.e. SIG_DFL is assigned),
it may dump a core file (depending on permissions). I would
hope that SIGEMT is set to be caught or ignored, otherwise the
trn receiving the signal will dump core and exit, while the one
sending the signal will presumably also exit.
So, if SIGEMT is being caught, what does trn do when it catches
SIGEMT (that may explain why SIGEMT is being used)?
If SIGEMT is set to be ignored by trn, then there's no reason
not to use signal 0 instead of SIGEMT.
--
Bruce Lilly ...uupsi!monymsys!sonyd1!blilly!bruce
Guy Harris
>is another trn running. On our MIPS box, SIGEMT and SIGXCPU are the same
>thing, and SIGEMT can't be ignored. Anyway, kill(0) is intended for just
>this use, why not use it?
Pre-4.xBSD (for some value of "x"; I think the correct value is 2)
UNIXes, and pre-System V Release "y" (for some value of "y") UNIXes,
don't support "kill(0)", as I remember. I.e., all *modern* UNIXes
handle "kill(0)", but if there are a sufficient number of non-modern
UNIXes out there, this may have to be something selected by Configure.
BTW, does 3.0 save a host name in the file where it saves the process
ID? Around here, sometimes *no* "kill()" will discover whether the other
"trn" is running or not, because it may be running on a different
machine - sometimes I run it on my workstation, and sometimes I run it
on another machine.
Guy Harris
>didn't support kill(0) to test for process existence. I believe it was
>a Berkeley innovation that, FOR SOME PECULIAR REASON, was slow to
>diffuse to other varieties of Unix.
Well, as I remember, AT&T implemented it in System V at about the same
time that Berkeley implemented it in BSD; given that, it'd have to be a
pretty peculiar reason, indeed....