🚀 go-pugleaf

	- hi; quiet round here, isn't it? [a] must be the excessi^W
	unaccustomed heat and all those strange sunbeams [b] causing
	dipspcers to doze off...

	- so, 'specially with your mental health in mind, and to
	exercise your little gray cells, a problem i've managed to
	create and inflict upon myself:

	- if, after downloading news, i manually trim batch.txt of
	either the complete headers of an article that's hit some
	rule in the ~/spool/news/killfile (from its #! rnews <number>
	to that of the next headers set in the file, or one or more
	pre-existing blank lines before this), or trim a complete
	rubbish/spam/velveeta article (from its #! rnews <number> to
	same), or trim a rubbish/spam/velveeta article's body (from
	the line after the headers, to same), unbatch misses the next
	#! rnews <number> and treats the following headers set and
	article body (if any) as part of the article body of the
	previous article left in the modified batch.txt.
	 leastways, this is my, possibly erroneous, identification of
	the cause of the observed effects.

	- if i save this unbatched double article whilst reading
	the newsgroup in snews as a new batchN.txt, edit out the
	initial headers set and the article body proper to it (if
	any), and run unbatch again, unbatch sorts the individual
	articles-per-separate file fine - but has the same hiccough
	if i first run a number of these batchN.txts into one another
	and save them as a single file (with each #! rnews <number>
	at the beginning - extreme left-hand side - of its own line -
	as it is in the modified, and in the original batch.txt,
	sfaics).

	- i can see no character before the # of the #! rnews <number>
	on its line, nor anything unusual at the end of the last line
	trimmed - or left untrimmed, if the line before the next
	#! rnews <number> be blank - and the behaviour is not depend-
	ant upon value given in the Lines: header line (which i'd not
	expected it to be, given that this value remains unaltered
	when a news article's body is skipped beause the article hits
	a killfile rule).

	- can any dipspcers identify why this is happening, and
	offer advice on how to avoid such "unbatchccough attacks" -
	preferably, advice other than "george, don't do that." ? [c]

	- love, a ppint. happy to have two thirds of IMT back open

	[- unbatchccoughs found using the unbatch.exe from both the
	current official snews and john's improved unbatch.exe in
	snews 1.31 (mods jw20504/386); batch.txt being trimmed and
	saved whether using protext v5.53 in document, or program,
	file-handling mode.]

	         [a] -   "I like rhetorical questions;
	                   I usually get them right."
	                   - joann l.dominik, 6/95

	   [b] - though obviously (?) not of the alpine variety

	[c] - some lowlife's been posting spam with the lengthy
	      body repeated in full as the header Subject: line,
	      which makes killfiling it of limited effectiveness:
	      and anyway, there are some quite readable posters
	      using gmail/google groups to post from, even if
	      they're somewhat erratic/clueless at snipping re-
	      quoted material)

	  [the address from which this was posted bounces e-mail;
	   please change the "f" to a "g" and drop the "v" if you
                       wish to cc. or e-mail me.]
-- 
 interstellar master traders 33 north road lancaster LA1-1NS england
      lancaster's sf/f/horror role-playing game and book shop
   http://www.i-m-t.demon.co.uk/ +44-781-344-1539 & +44-1524-382181
       10(ish) - 7pm (later by arrangement) monday - saturday