🚀 go-pugleaf

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."