Re: suggestion about nameing MU_STREAM_READ/WRITE...

[Sam Roberts]

Quoting Alain Magloire <address@hidden>, who wrote:
> > Quoting Alain Magloire <address@hidden>, who wrote:
> > Ok, but I think finding every msg in a mailbox with a particular
> > subject, and saving all the attachments to that message in
> > a folder named yyyy.mm.dd after the date of the message would
> > be hard with a utility with a cmd line like readmsg.
> 
> for i in `searchmsg --header=Subject "matching string"`
> do
>    readmsg $i > `date '+%Y.%m.%d'`
> done
> 
> Yes I know 8-)
> It's not quite what you were doing in mbox-explode.c
> The date is wrong and the you have the attachement
> not the entire message. But readmsg could take
> the approach of IMAP4 and "1.1" means message 1
> first part "2.3" message 2 third part  .... 

Sure, so it starts to look like:

for i in `searchmsg --header=Subject "matching string"`
do
  datehdr=`msgproperties --print-header=Date $i`
  datehdr=`datetosec $datehdr`
  datehdr=`date -s '+%Y.%m.%d'

  max=`msgproperties --print-attachment-count $i`
  for d = 1, d < $max;

    # ACK! my shell programming is good enough for day to day
    # stuff, but incrementing a counter through a loop is where
    # I usually drop into perl.
    # and you need to get the mime attripute for file name out
    # of a header, maybe with sed, and...
  readmsg $i > `date '+%Y.%m.%d'`
done

And it starts to be almost as complex as the C code...

Anyhow, you either have to provide utilities with command lines
complex enough they become a language in themselves (a la "find"),
or do lots of work in the shell.

All of which is fine if you need to write in sh, but
given the choice between sh and perl...

> > I think
> > mbox-explode a good example of somebody, namely me, doing something
> > useful with mailutils.
> 
> Yep, what I meant is mbox-explode.c could serve as the basis
> for a more general tool. examples/mbox-explode.c as it is right

Yep, some rainy evening soon.

> > I could have done it with perl, but
> 
> aaarrgg!!.  Arrie`re, arrie`re de'mon!!

Je ne comprende pas. (Et Je veux apprendre les phrases pour "[not] at
all", "a little", "mostly". And a few 10's of thousands of
other french words...)

> > I have a belief that the "ease of use" associated with languages
> > other than C and C++ is largely derived from their libraries,
> > not the languages themselves, so I wanted to test that.
> 
> Agreed.  Getting of topic, I think the comitte of C++ Std lib
> should have went further.

I'm really torn on this. C and C++ are truly general purpose
programming languages, they're used for so many kinds of things
I think it would have been hard to get any agreement.

What frustrates me is that nobody manages to get an equivalent
of CPAN for C++. There are a dozen perl packages on
CPAN for dealing with mail and mime, they weren't designed
by committee, or standardized, they just got written, and
since they're useful they get used and extended.

What I'd like to see is the FSF and other open-source groups
committing energy to developing C apis, like mailutils. Some
projects, like gzip, have library versions, but what about
tar? What about find? Mailutils is an example of how I
think things should be all the time.

Anyhow, so I think we should have a readmsg, or a single utility
that does all of the things that are reasonable, with a cmd line
of find-like complexity... 

And an MTA that delivers to local mailboxes with a /sbin/sendmail
compatible interface, that queues mail for remote delivery,
and acts as an SMTP client. I think this would be easy using
the mailutils API. If I ever get sieve working that's what
I think I want to do next.

nullmailer is ok, but it doesn't deliver locally.

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)