The Thursday 2004-10-14 at 11:30 -0500, Danny Sauer wrote:

...

I wonder if such a thing does exist? Or if some other mail program can do the trick? Perhaps formail, but no idea how (yes, I have read the man).

Like Patrick "almost" said, you can just hit "v" to view the components of a file, and then you can use the other message manipulation things to manipulate the attachments. For example, "d" will delete a message part (which could be an attachment), "s" wil save, "t" will tag parts so you can use ";" to do something to several attachments. Etc.

Mmm. Using mutt, that is. One day I'll get round to try it again... I found the interface too complicated. (I knew more than one would say mutt ;-) The features you mention are available in Pine, like save, delete, etc. The only snag is that it doesn't put the filename in the removed notice. Perhaps I could try to patch Pine :-?

...

Even a library for programmers would help a bit.

Perl has some pretty nice MIME email handling components. The Email::MIME and Email::MIME::Attachment::Stripper modules are particularly relevent. :)

Ah, one more reason to learn perl :-) -- Cheers, Carlos Robinson

The Friday 2004-10-15 at 03:21 +0200, Anders Johansson wrote:

This is perhaps something for you:

http://www.oneguycoding.com/opensource/

Second from the top, mimeStrip

Aha! It seems to be what I'm looking for. Unfortunately, I am unable to get it started: cer@nimrodel:~/bin> ./mimeStrip.pl Can't modify constant item in lock at ./mimeStrip.pl line 58, near "STDIN)" Execution of ./mimeStrip.pl aborted due to compilation errors. The code in question is: open(STDIN,"+<$folder") || die "Error: opening input folder $folder\n"; if (!lock(STDIN)) { close(STDIN); printf STDERR "Error: could not lock folder $folder\n"; } The only docu for mimeStrip seems to be: The following modules are used in mimeStrip.pl use MIME::Base64; use File::Basename; use File::stat; use Fcntl ':flock'; <=== use Getopt::Long; use Time::ParseDate; for which you may need to compile and install IO-stringy-1.216.tar.gz Ok MIME-Base64-2.11.tar.gz ?? MIME-tools-5.316.tar.gz Ok MailTools-1.15.tar.gz Ok Time-modules-100.010301.tar.gz Ok libnet-1.0703.tar.gz -- non perl, ok. Fcntl seems to be part of the main perl-5 package. It might be that the script has not been updated for a year or so. [...] Commenting out the lock part, I can get it to work. It does strip files like I want. But not from one mailbox, the most important one for this task: it is a small daily publication in pdf I get, in which there is no text, only the attachement (ie, no "parts"). MimeStrip doesn't notice the attachement, unfortunately. Even Pine complains: Message 5 has only one part (the message body), and no attachments. and fails to delete it, or save: [Formatting error: Internal base64 decoder error: Error writing attachment to "/home/cer/bolet] Or even view them. The recent ones I can view and save with Pine, but not delete. They were produced with: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) and the recent ones with: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) One more sample of buggy or non standard software from Microsoft, I suppose... :-( Hugh. I'll have to save those files with mozilla, one by one... there are a lot of them! -- Cheers, Carlos Robinson

The Thursday 2004-10-21 at 10:28 -0500, Danny Sauer wrote:

...

The code in question is:

open(STDIN,"+<$folder") || die "Error: opening input folder $folder\n"; if (!lock(STDIN)) { close(STDIN); printf STDERR "Error: could not lock folder $folder\n"; }

What? Why would this fellow reopen STDIN anyway? The filehandle is only used in one place - the while loop that reads the contents in - and it's explicitly specified in there. It's not like the code takes advantage of the special features of STDIN, like the ability to just say <> rather than <STDIN>.

I have no idea O:-) Once uppon a time, I did program for a living, in dos/win3.11; never touched linux nor unix. And certainly not in perl ;-) The error seems to be with "lock" - if I coment that "if" sentence, it works. I assume it wants locks stdin because new mail might try enter the mailbox... I don't know, it makes more sense to me to lock a standard file, not stdin. But I have not tried yet even to analyze the program, but as I don't even know what things like "+<$folder" means in perl...

Anyway, you should probably replace STDIN with something that makes more sense anyway, like, perhaps FOLDER_HANDLE. Just a global search and replace oughtta do it. Why is it so hard for people to use reasonable variable names? And why is it so difficult for me to stay on-topic on this list? :)

I guess there is a programming list somewhere - but I haven't tried, I'm too rusty :-)

...

Message 5 has only one part (the message body), and no attachments.

That's probably because there's only one part, and the content type is weird. Full headers would help, but in those, you really just need to parse the mbox (or run through a filter before delivering to the mbox) to separate the messages, then look for the first blank line. That'll be the division between the headers and body. The body then just needs decoded and saved.

Yes, I remember. As I mentioned, time ago I did a program in pascal to delete attachments, but I lost it. That was before receiving these problematic emails - they would fail anyway in my coding. I was hoping somebody else had done it before. Have a look at one of those emails - the important part, anyway: |Message-ID: |>MIME-Version: 1.0 |>Content-Type: application/pdf; |> name="viernes030124.pdf" |>Content-Transfer-Encoding: base64 |>Content-Disposition: attachment; |> filename="viernes030124.pdf" |>X-Priority: 3 (Normal) |>X-MSMail-Priority: Normal |>X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) |>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 |>Importance: Normal |>X-Spam-Status: No, hits=-2.0 required=5.0 |> tests=FROM_NAME_NO_SPACES,FROM_AND_TO_SAME,AWL |> version=2.31 |>X-Spam-Level: |>Status: R |>X-Status: |>X-Keywords: |> |>JVBERi0xLjIgDSXi48/TDQogDTE2IDAgb2JqDTw8DS9MZW5ndGggMTcgMCBSDS9GaWx0ZXIgL0Zs |>YXRlRGVjb2RlIA0+Pg1zdHJlYW0NCkiJlFdrb9s4Fv0F/Q/EAAV2AVvDh54fM2l2NkAmKSaZBRbI Pine can not handle them. Mozilla, yes. I haven't tried kmail.

That should be a pretty simple exercise, I'd think, given some programming skillz. There are perl modules to deal with that, too. I'm not sure why that program doesn't just use one of those, but then, the whole program is structured a bit poorly, IMHO.

I could easily - I think ;-) - write a program to remove the "attachment" there - but I would be at a loss on how to add a plain text instead (there is no text part), and also how to produce the file to save it.

Note, I posted some code on Aug 10 this year, under the subject "Re: [SLE] KMail question" which will pull the attachments out of messages fed in one at a time. It's a bit more compact and would require some modification for your use, though if you're happy with the somewhat questionable code you're running, that's not too relevent. :)

Aha, I've just found it. Interesting... I could perhaps trigger it from procmail, and bouncing a copy of those email (from Pine) would perhaps do the trick. Or even use kmail for a while... Er... is there a quick-perl-get-started-howto? O:-) -- Cheers, Carlos Robinson

The Saturday 2004-10-23 at 09:43 +0200, Jon Clausen wrote:

...

Er... is there a quick-perl-get-started-howto? O:-)

If at all possible, do get a copy of "Perl Black Book". Very comprehensive, nicely indexed and thoroughly readable. At times also *very* funny :)

It isn't cheap, but I found it to be *well* worth the investment.

I said "quick" - perhaps I should have said "brief" ;-) Anyway, geting such books is not easy here, and probably at double the original price . -- Cheers, Carlos Robinson

On Thu, 28 Oct 2004 14:55:39 -0500 Danny Sauer wrote:

--Danny, posting a bit late, so it seems

Just as long as you're not the "late Danny" it's OK! <G> Terence

The Thursday 2004-10-28 at 14:55 -0500, Danny Sauer wrote:

I'd probably point you to perl.com, personally. There's loads of tutorials and examples for quite a variety of skill levels (including "beginner"). As far as books, I've found O'Reilly's "Perl Cookbook" to be pretty useful. I'm partial to learning by example, though, so that could just be me. :)

I'll have a look around, thanks. I read a chapter on a linux "bible" I had around. It dedicates a chapter to some languages (one each). -- Cheers, Carlos Robinson

Carlos wrote regarding 'Re: [SLE] Removing attachements from stored mails (or my problems with perl)' on Sun, Oct 31 at 06:04:

The Saturday 2004-10-23 at 01:53 +0200, Carlos E. R. wrote:

...

The Thursday 2004-10-21 at 10:28 -0500, Danny Sauer wrote:

...

Note, I posted some code on Aug 10 this year, under the subject "Re: [SLE] KMail question" which will pull the attachments out of messages fed in one [...] I'm trying to use your code. I call it thus:

formail -s stripattach < mbox_file.

But it complains that "Can't locate Email/MIME.pm ". You did mention that:

|> You'll have to install Email::MIME and |> Email::MIME::Attachment::Stripper from CPAN.

So, I start downloading things from CPAN (actually, from a mirror at perl.com you mentioned). I download Email-MIME-1.8.tar.gz and try to

Ok, this is *way* easier if you use the CPAN shell. Get yourself set up as a user who can install perl modules (typically this means root), and type perl -MCPAN -e'shell' Answer the questions, and type install Email::MIME::Attachment::Stripper (for example). The cpan module will take care of installing the module and whatever modules are required. If you say "follow" rather than the default of "ask" when the CPAN setup prompts you about how to handle dependencies, you won't even have to say "yes" when it asks to download the deps. Overall the CPAN shell is super nice.

Now, test your code [...] ¡It works! :-)

Well, that much is good. :)

Well, it doesn't put a text saying that the file was removed. Probably I can live with that, at least for the set of mails I want to handle.

Pull the body off, stick a line at the end, reattach the body. Or, add a new text attachment whose contents are "file $filename removed", etc. :) Hooray for having the source code, eh?

Some of the files have repeated names... now, that is a problem. I could prepend, for example, the email date :-?

So, I add the line:

my $from_header = $mail_parsed->header("Date");

But the date is in the format. "Fri, 24 Jan 2003 10:32:04 +0100". I would need to modify it to something like an ISO date: 2004-01-24

¿Is that doable? I suppose there are ready made functions for that kind of string manipulation, but I don't even know how can I browse an index of all functions (modules) available, preferably in hierarchical sort. [...]

You probably want to look at Date::Parse for that. It works quite well. For finding modules, I usually use http://search.cpan.org/ (though that particular module is one that I use often for log parsing, etc).

Yes, "info perl" says to look at "perlintro", but I get "not found". There is only "perldoc", which assumes I already know what module I want to look at. [...] Mmmm.... there is a "man perlintro". Is that it? Not a browsable help? Pfff. :-(

The perl documentation is viewable using the perldoc program, which functions similarly to man or info. So, "perldoc perlinfo" is what you're looking for as a start. If you do a "man perl", you'll get a list of lots of other docs that are also included, those sections are further described under "perldoc perltoc". Most of the time, the main perl docs are also installed as man pages, so you can do things like "man perlintro", or, for a nice read, "man -t perlintro | lpr". The perldsc page and the perlfaq pages should be mandtory reading, and the prelretut page will do wonders for the regexp uninitiated. Finally, read perlstyle, and start most any program out with #!/usr/bin/perl -w use strict; That'll really encourage clean, reliable code. Oh, and you'll likely want perlcheat located nearby for a while. :) --Danny, willing to take this off-list if no one else cares ;)

Patrick wrote regarding 'Re: [SLE] OT: Removing attachements from stored mails (or my problems with perl)' on Tue, Nov 02 at 08:30:

* Danny Sauer [11-02-04 07:30]:

...

Carlos wrote regarding 'Re: [SLE] Removing attachements from stored mails (or my problems with perl)' on Sun, Oct 31 at 06:04: ...

...

So, I start downloading things from CPAN (actually, from a mirror at perl.com you mentioned). I download Email-MIME-1.8.tar.gz and try to

Ok, this is *way* easier if you use the CPAN shell. Get yourself set up as a user who can install perl modules (typically this means root), and type perl -MCPAN -e'shell' Answer the questions, and type install Email::MIME::Attachment::Stripper (for example). The cpan module will take care of installing the module and whatever modules are required. If you say "follow" rather than the default of "ask" when the CPAN setup prompts you about how to handle dependencies, you won't even have to say "yes" when it asks to download the deps. Overall the CPAN shell is super nice.

But you are going away from the SuSE distro standard rpm system and will introduce dependency problems in rpms which are false and eventually cause maintenance problems. Better to find an *rpm* solution, if possible.

Sorry - I was speaking from experience on my SuSE systems, not from pure theory. I've been using CPAN to keep my perl modules up to date since 5.x, and have had 0 problems with false dependencies related to perl modules. This is partially because almost nothing depends on perl module packages aside from other perl modules and partially because I generally run server-like machines where I'm not adding and removing random app-of-the-week all the time. I suppose that if you're a dim user who can't remember if you've installed a module or not, then you should stick with RPM for managing perl modules. Most of those users aren't gonna be using CPAN or anything like that anyway, though, since yast will take care of their deps. I'm pretty confident that "better" is in the eye of the beholder here. --Danny

Kastus wrote regarding '[SLE] Re: Perl modules as RPM (was: [SLE] OT: Removing attachements from stored mails (or my problems with perl))' on Wed, Nov 03 at 11:21:

(but this is for really lazy sysadmins who hate to do the same job more than once)

I thought that was the definition of a good sysadmin? :) --Danny

* Danny Sauer [11-03-04 10:43]:

Patrick wrote regarding 'Re: [SLE] OT: Removing attachements from stored mails (or my problems with perl)' on Tue, Nov 02 at 08:30:

...

But you are going away from the SuSE distro standard rpm system and will introduce dependency problems in rpms which are false and eventually cause maintenance problems. Better to find an *rpm* solution, if possible.

Sorry - I was speaking from experience on my SuSE systems, not from pure theory.

????

I've been using CPAN to keep my perl modules up to date since 5.x, and have had 0 problems with false dependencies related to perl modules.

I too have done this, but try to limit it.

This is partially because almost nothing depends on perl module packages aside from other perl modules and partially because I generally run server-like machines where I'm not adding and removing random app-of-the-week all the time.

spamassassin/razor

I suppose that if you're a dim user who can't remember if you've installed a module or not, then you should stick with RPM for managing perl modules.

Should I be getting upset?

Most of those users aren't gonna be using CPAN or anything like that anyway, though, since yast will take care of their deps.

Or YaST, you said most and I must assume that you are referring to noob's. But YaST is rpm dependent and only complains, does not *solve* dependency problems.

I'm pretty confident that "better" is in the eye of the beholder here.

Depends, on whether the "beholder" is considering the noob's or himself. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos

The Monday 2004-11-01 at 15:18 -0600, Danny Sauer wrote:

Ok, this is *way* easier if you use the CPAN shell. Get yourself set up as a user who can install perl modules (typically this means root), and type perl -MCPAN -e'shell' Answer the questions, and type install Email::MIME::Attachment::Stripper (for example). The cpan module will take care of installing the module and whatever modules are required. If you say "follow" rather than the default of "ask" when the CPAN setup prompts you about how to handle dependencies, you won't even have to say "yes" when it asks to download the deps. Overall the CPAN shell is super nice.

I had heard of that method. However... I suppose in this case it would have tried to update most of everything to the newest - because Email-MIME-Encodings-1.3 wanted to update, MIME::Base64 3.05 and MIME::QuotedPrint 3.03, and those would surely want to update something else... an endless chain. I decided to install instead the older Email-MIME-Encodings-1.1, which was happy with what was on the system. As I'm not an expert, but at the start of principiant, I don't want to change any thing but the strictest necessities - perhaps i could break something, like amavis. Thus I prefer the slow, manual method. I control it. Some other time :-)

...

Now, test your code [...] ¡It works! :-)

Well, that much is good. :)

...

Well, it doesn't put a text saying that the file was removed. Probably I can live with that, at least for the set of mails I want to handle.

Pull the body off, stick a line at the end, reattach the body. Or, add a new text attachment whose contents are "file $filename removed", etc. :) Hooray for having the source code, eh?

Yes, the second method is preferable, no modifying of the email text. I would have to learn how to do it, yet :-)

[...]

You probably want to look at Date::Parse for that. It works quite well. For finding modules, I usually use http://search.cpan.org/ (though that particular module is one that I use often for log parsing, etc).

I'll have a look. That module is included by SuSE, it is installed.

...

Yes, "info perl" says to look at "perlintro", but I get "not found". There is only "perldoc", which assumes I already know what module I want to look at. [...] Mmmm.... there is a "man perlintro". Is that it? Not a browsable help? Pfff. :-(

The perl documentation is viewable using the perldoc program, which functions similarly to man or info.

But 'pinfo' style would be preferable; perldoc does not navigate documents.

So, "perldoc perlinfo" is what you're looking for as a start.

cer@nimrodel:~> perldoc perlinfo No documentation found for "perlinfo". It doesn't work. And 'pin' doesn't find it.

If you do a "man perl", you'll get a list of lots of other docs that are also included, those sections are further described under "perldoc perltoc".

Ok - this document is 12858 lines long, a long, long plain file. It can not be searched easily, no _links_. Try, for example "pinfo fetchmail" (not info fetchmail). There is a line like this: |> You can then handle the retrieved mail using normal mail |> user agents such as mutt(1), elm(1) or Mail(1). The words mutt(1), elm(1) or Mail(1) are printed in green in the xterm text. I can click with the mouse, or cursor to elm(1) till it is red, hit enter, and open that man page. Left cursor will put me back on the previous documents. Ie, I can navigate plain man pages. But perldoc doesn't do that. It is a "TOC" whose entries do not automatically take me to the referred documentation. Maybe there is a web page somewhere, but as I don't have a permanent network connection, I would have to mirror it locally, if possible. Another thing: pinfo adapts to xterm size, and reflows the text; perldoc doesn't. Or, what would be most useful to me, a hierarchical index of modules and functions available, so that having an idea of what I want to accomplish, I can find what module does what I want to do. To use a man page I already have to know its name. You know, I'm spoilt. During the time I programmed for a living, I used mostly Borland C and Borland Pascal - not only the IDE is magnific, but the online help was so good that I learned to program TP without a manual (of course, I had had classes, formal training). When I did get the TP manual (which were also splendid) I became a guru. Easy! I'm spoilt: anything sort of that kind of environment and I start fidgeting O:-)

Most of the time, the main perl docs are also installed as man pages, so you can do things like "man perlintro", or, for a nice read, "man -t perlintro | lpr". The perldsc page and the perlfaq pages should be mandtory reading, and the prelretut page will do wonders for the regexp uninitiated.

Finally, read perlstyle, and start most any program out with #!/usr/bin/perl -w use strict; That'll really encourage clean, reliable code. Oh, and you'll likely want perlcheat located nearby for a while. :)

I will read some of them, of course. :-)

--Danny, willing to take this off-list if no one else cares ;)

Who knows? There are always people reading even if they don't contribute. -- Cheers, Carlos Robinson

The Wednesday 2004-11-03 at 14:51 -0600, Danny Sauer wrote:

...

No documentation found for "perlinfo".

It doesn't work. And 'pin' doesn't find it.

Argh. I typed perlinfo a bunch of times when I meant perlintro... Whoops. Sorry 'bout that.

Ah, ok, found that one :-)

...

...

If you do a "man perl", you'll get a list of lots of other docs that are also included, those sections are further described under "perldoc perltoc".

Ok - this document is 12858 lines long, a long, long plain file. It can not be searched easily, no _links_.

I like the '/' key, mostly because I live in vim. Surely your pager lets you search like that? The lack of links does suck, though. Read on...

Ah, yes, I know. '/' searches forward, '?' searches backwards, as in "less". By the way, the choice is quite counterintuitive on a non US keyboard. Linux still needs more internationalization effort... but that is a different issue :-) [browsable docs with links]

That's a limitation of the default pager. Wanna browse documentation for all the modules on your system easily? Install Pod::Webserver (it has a few deps, but they're all small), run "podwebserver", and point a web browser to http://localhost:8020/. If you scroll down to the perl_core_docs section, you'll have nice HTML versions of all those things, interlinked and easily read/printed/etc. It's not quite as cool as JavaDoc, but it's right up there. Use lynx (or links) if you want a terminal view.

Ahhhh... ok, I'll try.

...

To use a man page I already have to know its name.

Yeah, it takes a little time to get comfortable with what a module's likely to be called. The CPAN search site is about the easiest thing to use, aside from searching in the CPAN shell (yay regexp search).

Needs being on line... which I seldom are.

...

I'm spoilt: anything sort of that kind of environment and I start fidgeting O:-)

ActiveState has a nice IDE - Komodo - built on the mozilla framework. I think it's got a nice doc browser too (and you can use it with languages other than perl, if you like that kind of thing).

Another thing to look at :-) -- Cheers, Carlos Robinson