[Pan-users] Re: ANNOUNCE: pan-attach and pan-attach-kd, version 0.0.2006.10.07.0

[Duncan]

Dave <address@hidden> posted
address@hidden, excerpted below, on  Sun, 08 Oct 2006
01:15:12 +0100:


> Excellent!
> 
> Just tried it with an attachment in uu and yenc format and both worked
> just fine after editing and moving my sig.

yenc?  I take it you are still using pan 0.14?  yenc fails to post in
new-pan (well, from 0.113 or whenever I first tried it) here, with an
error from one of the gtk libs.  I guess it wants only text, and the
basically 8-bit yenc it doesn't like.  I have a bug open on it (and
Charles had me post a gdb traceback so he's considering it a bug too, I
wasn't sure he would), and old-pan used to take it, so it should be
possible.

> Is there a way to insert the encoded file before the sig?  Pan refuses
> to post the article stating the sig is waaaaay to0 big.  No real problem
> though.

It /should/ be a (GNKSA) warning, not an error.  IOW, it should warn you,
but then let you go ahead.  At least it does in new-pan, and I never had
any trouble even with multiple attachments (I tried up to three but they
were moderate size jpegs) in old-pan (that was with pan-attach, but that
shouldn't matter for this). It warned, but there was a continue
anyway button, and since I knew what the problem was and that it wasn't
really the sig, I just hit that.

As for putting it elsewhere in the file, it would be possible, but more
difficult and therefore more prone to bugs.  At present, the script simply
appends the attachment output from uuenview to the end of the file --
pretty simple and hard to get wrong.  To insert it in the middle, the
script would essentially have to split the post-temp-file at the sig
(probably by grepping the "-- " sig delimiter), probably saving the sig
off to a second file while deleting it from the working file, then append
the attachment, then append the other file back after the attachment.

Not only is that more complex and therefore open to additional bugs, just
to keep everything nicely separate, I presently insert a couple blank lines
buffer before the attachment, which is now after the sig so there's no
more text content.  Were I to put the attachment previous to the sig and
add a couple blank lines safety after the attachment as well, the effect
would be four blank lines between the end of any text and the sig, more if
there were multiple attachments!

Of course, in theory I could delete the blank lines and make it work, but
then there's more chance of a bug causing the text to merge with the
attachment and garble one or both.  Thus, I prefer to keep the blank lines
as clean separation and avoid such bugs, and keeping the attachments after
the sig means the additional blank lines don't matter so much. =8^\

So, you see, I /did/ think of it. =8^)  If someone can convince me it's
worth the trouble doing it the other way, it's certainly possible.  I'm
just not convinced it's worth the possible bugs -- considering I have no
control at all of the clients that'll be used to decode things as far and
wide as the posts might go, and thus, of the bugs said clients might have.
(A commonly repeated rule of thumb in the Internet RFCs, the documents
that define Internet reference standards, is be strict in what you send,
but tolerant in what you receive, thus making allowances for clients that
don't quite get it right.  This isn't at the level of a standard, but the
same idea applies, and I like that clear safety margin.)

> I'm happy that it works :-)

So am I, both for posting on my own, and more so that my hard work is
found useful by others. =8^)  I don't do C/C++, so it's a pretty special
thing when something I /can/ do actually fills a functionality hole, not
only for me, but for other people as well.  =8^)

> I would imagine the only real problem might be for those who need to
> post a bigger file than their news server allows in a single article.
> That said, I don't need to do that anyway.  My need is to post the odd
> photo now and then to an internal ISP newsgroup.  This script of yours
> is perfect for that.

Yes, the script is for the trivial/occasional little attachment, but it's
useful for that. =8^)  For the bigger jobs, there are a couple other
solutions.  First, there's newspost, the batch-poster.  Historically, that
has been the recommended solution when pan users need to post, and it's
going to work better for the large post anyway, but now there's a
solution for the trivial/small post as well. 

Second, one can do what they do in the ISO groups all the time -- manually
split the file up as necessary (on *ix, the "split" command can be used),
then post the pieces. Of course, in the ISO groups, they may split a 700
meg ISO into 14 50 meg pieces, then post each of those with the client
further splitting them. Here, we're talking about splitting maybe a 7 meg
into 14 pieces, and posting the 500 k pieces as single parts.  Same idea
tho, just not using as complex a tools so more must be done manually.

> Thanks for all the work.

Thanks for the feedback.  As I said, it's very nice to have someone else
find my script hacking actually useful.  <g>

BTW, one improvement that should be fairly easy, that I'm already thinking
about, is allowing multi-select in the file box, so multiple files can be
attached in a single shot -- if they are all in the same dir, of course. 
This won't help those already running into size limits, nor is it really
suitable for wide propagation given the problems many servers have with
size, but it could be useful for those whose target audience is all on the
same server, as long as the server allows that size, of course.  Changing
the file selection dialog is trival -- a matter of adding one more
parameter to the call is all.  Adding a loop to the attachment sequence to
process multiple files would be slightly more work, but nothing like
either the original bash proof of concept, or the port to kdialog, either
one.  Perhaps half an hour to an hour more work, plus additional testing,
is all.  However, I figured I'd see how the basic approach worked out
first, before trying to complicate it.

Another idea I have now that I got this one down, is creating a front-end
to newspost.  Both KDE and GNOME formerly had frontends (knewspost and
gnewspost, respectively), but AFAIK they are both /years/ out of date, and
no one with the skills seems to have the need and no one with the need
seems to have the skills, so the way seems open for a poor script-only guy
to have at it. =8^)  OTOH, with new-pan coming along so nicely and just
about to hit 1.0, adding full batchable binary posting to it as well would
make a very nice 2.0.  Still, I'm guessing that would be at /least/ another
year out, likely two, given a couple point releases with more minor
improvements first and that Charles has been pushing /very/ hard with the
weekly betas and has already said he wants (and he certainly does deserve)
a bit of a break after 1.0.  Thus, there's likely some time for that
front-end to actually be useful, if I decide to do it.  That said, I'd
have to actually /use/ newspost first before I decided to do a front-end,
so while there's a gambler's chance I'll do it, it's still significantly
less than 50/50.  I'd put the chances at 10-20% ATM, but that's still
dramatically higher than it was a couple weeks ago, before I got serious
about kdialog, which I knew about but didn't actually know until I did
pan-attach-kd or that would have likely been pan-attach and there'd have
never been the crude non-interactive bash-only version.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman