🚀 go-pugleaf

	- hi; in dipspc article, <1210782979snz@nospam.demon.co.uk>,
	  pete@nospam.demon.co.uk diagnosed, suggested and advised:
>	                 "ppint. at IMT" writes:
>
>>	- 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...
>
>Indirectly -- I believe the heat simply makes the beer evaporate 
>faster.  ;-)

	- ah; fx: *nods wisely*  - a topic upon which this ppint.
	is unversed; yr hmbl srppnt. can, however, advise that the
	effects of (real) cider consumed during lunchtime and/or
	the afternoon are conciderably enhanched by such unaccush-
	tomed - and even unsheashonal - shunshine'nd heatth...
>
>>	- 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:
>
>[snip description of batch-butchery

	- waugh! - not butchery!  - 'tis justified trimming!

	(- and it's all but essential, upon i-m-t-in-the-shop)

>                                    and the results]
>
>Initially I thought this might be a LF vs CR/LF problem (as Snews 
>uses the *nix-like linefeed EOL character), but no.  Batch.txt 
>uses standard rfc-whatever CR/LF as line delimiters, which get 
>converted to LF for storage in the newsbase.
>
>However, taking a fleeting look at the unbatch source (at least, 
>the version I have here which might be different from the JLW 
>one) it looks like there is a mechanism which checks the number 
>of bytes in an article -- that is, the length of the file between 
>successive "#! rnews <length>" entries.  I think it allows some 
>leeway, 10 bytes or so, as a check that the "#! rnews.." isn't 
>part of an article body <boggle> and if it fails this check

	- i.e. if the next "#! rnews <length number>" comes before
	*or* *after* the advised number of bytes +/-10(5?) - ?

>it assumes that this is _not_ the start of a new article but a 
>continuation of the present one.  Which is what I understand you 
>are seeing.

	- this would fit what i've seen, i think. if the <length
	number> of a killfiled article represents only the number
	of bytes in the article's header.
>
>So, the lesson learned is to excise articles _very_ carefully.  
>If the article you're cutting has for example lots of spurious 
>white space or blank lines (or rather the one before) you have to 
>maintain that garbag^H^H^H^H^H^Hwhite space.

	- *nods*
>
>Oh -- and one more thing: the <number> after the "#! rnews" 
>refers I believe to the length of the succeeding article, so when 
>excising an article, make sure that you don't accidentally leave 
>that "#! rnews" line instead of that of the next actual article.
>
>Hope that makes sense (and that it is not a red herring...)
>
	- thanks, pete; if it does - and if i've understood you
	aright - it would also work ok if i deliberately retain
	the "#! rnews" line of the excised article-plus-headers
	so long as i set the <bytesize number> to <00000000> (or
	however many digits the format is in there): but *not*,
	if i trim an article of massive, sometimes very poorly
	formatted over-quoting, leaving the headers in batch.txt
	- because the article byte-size will now not match the
	"#! rnews" line's <bytesize number>; even if i were to
	replace the cut text with the same number of blank lines,
	they still wouldn't tally - because a blank line is very
	few bytes.
	  and similarly, it'll not work if the whole body of an
	article is cut, if the headers're left behind with an un-
	modified "#! rnews <bytesize number>" line; and i don't
	think i want to start counting bytes, to correct this
	number to that of specific articles' header lines...

	- but unbatch should/_may be able to_ cope with the whole-
	sale excision of headers-and-article-body(if any), from
	"#! rnews <bytesize number>" line up to the start of the
	following article's "#! rnews <bytesize number>" line. yes?


	- further tests are indicated.

	- love, a ppint. happy to have two thirds of IMT open again
	    [please drop the "v", and change the "f" to a "g",
	        should you wish to cc. to, or email, me]
-- 
                 "everything's better with tentacles"
      - yr hmbl  srppnt. 9 or 10/5/08 (5/9 or 10/08 for merkins)

In article  <20080516.0928.80501034snz$@i-m-t.demon.co.uk>
           v$af$ppint@i-m-t.demon.co.uk "ppint. at pplay" writes:

Hi ppint

>         - hi; in dipspc article, <1210782979snz@nospam.demon.co.uk>,
>           pete@nospam.demon.co.uk diagnosed, suggested and advised:
> >                        "ppint. at IMT" writes:
[..]
> >Oh -- and one more thing: the <number> after the "#! rnews" 
> >refers I believe to the length of the succeeding article, so when 
> >excising an article, make sure that you don't accidentally leave 
> >that "#! rnews" line instead of that of the next actual article.
> >
> >Hope that makes sense (and that it is not a red herring...)
> >
>         - thanks, pete; if it does - and if i've understood you
>         aright - it would also work ok if i deliberately retain
>         the "#! rnews" line of the excised article-plus-headers
>         so long as i set the <bytesize number> to <00000000> (or
>         however many digits the format is in there): but *not*,
>         if i trim an article of massive, sometimes very poorly
>         formatted over-quoting, leaving the headers in batch.txt
>         - because the article byte-size will now not match the
>         "#! rnews" line's <bytesize number>; even if i were to
>         replace the cut text with the same number of blank lines,
>         they still wouldn't tally - because a blank line is very
>         few bytes.
>           and similarly, it'll not work if the whole body of an
>         article is cut, if the headers're left behind with an un-
>         modified "#! rnews <bytesize number>" line; and i don't
>         think i want to start counting bytes, to correct this
>         number to that of specific articles' header lines...
> 
>         - but unbatch should/_may be able to_ cope with the whole-
>         sale excision of headers-and-article-body(if any), from
>         "#! rnews <bytesize number>" line up to the start of the
>         following article's "#! rnews <bytesize number>" line. yes?

Indeed to all the above.  However, my hasty reply was sort of a 
pink herring.  Looking at the code a little longer, it appears 
that one can simply tell unbatch to ignore article length info 
altogether:  just run it with the 'l' (little ell) parameter, 
i.e.
        unbatch -jl     (I assume you already use '-j')

Problem solved!

Pete

-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."

	- hi; in dipspc article, <1211089452snz@nospam.demon.co.uk>,
	           pete@nospam.demon.co.uk discovered:
>	   v$af$ppint@i-m-t.demon.co.uk "ppint. at pplay" writes:
>>	  pete@nospam.demon.co.uk diagnosed, suggested and advised:
>>>	                 "ppint. at IMT" writes:
>[..]
>>>Oh -- and one more thing: the <number> after the "#! rnews" 
>>>refers I believe to the length of the succeeding article, so when 
>>>excising an article, make sure that you don't accidentally leave 
>>>that "#! rnews" line instead of that of the next actual article.
>>>
>>>Hope that makes sense (and that it is not a red herring...)
>>
>>	- thanks, pete; if it does - and if i've understood you
>>	aright - it would also work ok if i deliberately retain
>>	the "#! rnews" line of the excised article-plus-headers
>>	so long as i set the <bytesize number> to <00000000> (or
>>	however many digits the format is in there): but not, if
>>	i trim an article [..], leaving the headers in batch.txt
>>	- because the article byte-size will now not match the
>>	"#! rnews" line's <bytesize number>; [..]
[] 
>>	- but unbatch should/_may be able to_ cope with the whole-
>>	sale excision of headers-and-article-body(if any), from
>>	"#! rnews <bytesize number>" line up to the start of the
>>	following article's "#! rnews <bytesize number>" line. yes?
>
>Indeed to all the above.  However, my hasty reply was sort of a 
>pink herring.  Looking at the code a little longer, it appears 
>that one can simply tell unbatch to ignore article length info 
>altogether:  just run it with the 'l' (little ell) parameter, 

	- ooh!  - i can't see that as an option in the unbatch
	settings' help screen, but it sounds *just* what the
	doctor ordered *g*

>i.e.
>        unbatch -jl     (I assume you already use '-j')

	- i do indeed;
>
>Problem solved!
>
	- and my faith in the natural superiority of the ka9q/
	dis/snews(johnwash)/pcelm(oak)/etc package (and of dos
	software more generally) is - well, not so much re-
	stored, as maintained or even increased - as is that
	in the abilities and helpfulness of dipspc-ers :-))

	- many thanks;

	- drop into IMT for coffee, tea and/or (70%) chocolate
	any time you're in the area during shop hours - ppint.
-- 
"homeopathic compression: throw away the data and transmit the spaces;
 the data to be reconstructed from the spaces by virtue of these having
 remembered its shape. the only compression method more effective with
 increasing original data density." - yr hmbl srppnt, 1st october 2004

In article  <20080518.1523.80501038snz$@i-m-t.demon.co.uk>
           v$af$ppint@i-m-t.demon.co.uk "ppint. at pplay" writes:

>         - hi; in dipspc article, <1211089452snz@nospam.demon.co.uk>,
>                    pete@nospam.demon.co.uk discovered:
[..]
> >>      "#! rnews <bytesize number>" line up to the start of the
> >>      following article's "#! rnews <bytesize number>" line. yes?
> >
> >Indeed to all the above.  However, my hasty reply was sort of a 
> >pink herring.  Looking at the code a little longer, it appears 
> >that one can simply tell unbatch to ignore article length info 
> >altogether:  just run it with the 'l' (little ell) parameter, 
> 
>         - ooh!  - i can't see that as an option in the unbatch
>         settings' help screen, but it sounds *just* what the
>         doctor ordered *g*

Odd.  Or perhaps maybe not so odd at all; it is *so* easy to add 
new functionality to a piece of software but to fail to update 
the help screens :-(

> >i.e.
> >        unbatch -jl     (I assume you already use '-j')
> 
>         - i do indeed;
> >
> >Problem solved!
> >
>         - and my faith in the natural superiority of the ka9q/
>         dis/snews(johnwash)/pcelm(oak)/etc package (and of dos
>         software more generally) is - well, not so much re-
>         stored, as maintained or even increased - as is that
>         in the abilities and helpfulness of dipspc-ers :-))
> 
>         - many thanks;
> 
>         - drop into IMT for coffee, tea and/or (70%) chocolate
>         any time you're in the area during shop hours - ppint.

Thanks - I'll bear that in mind next time I'm "oop north" ;-)

Pete
-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."