Dave <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
