Re: Would a --field option to frm be generally useful?

[Alain Magloire]

Bonjour

> A few things in this diff:
> 
> 1 - I changed it to only print subject if get_header(SUBJECT)
>     returned success, otherwise I assume it would print the stack.

Ha yes, thanks.

> 2 - I corrected a tiny typo in the usage message.
> 
> 3 - And I added an option -f,--field that prints the named field
>     in the mailbox, and nothing else. Don't know if that's generally
>     useful, or if the API of frm is supposed to be some particular
>     way to be compatible with some other frm.

Compatible yes but not restricted to.
frm, readmsg, printmail, etc ... are very usefull, a friend of mine
wrote a "shellmail" that spawned those tools and use it as his email reader.

> Also, it wouls seem to me that I should be able to provide a url
> as the mailbox, but neither file://home/sam/Mail/Sent nor
> file:///home/sam/Mail/Sent seemed to work for me. I didn't have
> time to look for why, yet. Should they work?

Yes, I simply forget to "register" in the "registrar" (hello dinglis ;-)
the "file:" URL.  see in frm.c :

/* register the formats.  */
  {
    list_t bookie;
    registrar_get_list (&bookie);
    list_append (bookie, mbox_record);
    list_append (bookie, path_record);
    list_append (bookie, pop_record);
    list_append (bookie, imap_record);
  }

This means that I have registered:
mbox_record "mbox:" (Unix format)
imap_record  "imap:" (Imap mailbox)
pop_record  "pop:"  (POP mailbox)

if you want "file:"  add it to the list :
{
...
   list_append (bookie, file_record);
}

and you will be able to do :
# MAIL=file:///home/sam/Mail/Sent  ./frm
# ./frm file:/home/sam/Mail/Sent

And you will ask, why all this complexity and heavy artillerie?

The ideas behind it are :
- not to link with the clients things that it does not need.  
- Allow runtime extension, i.e. possibility of a client at runtime
  to support new mailboxes.  It's the component approach, or the
  COM or CORBA approach.  The mailbox library maintains a global
  linked list :
  {
    list_t bookie;
    registrar_get_list (&bookie);
  ...

  You can add to it(the link list) concrete implementation of mailboxes,
  when time comes to choose a concrete mailbox that implementing
  a specific URL (pop:, imap:, file: etc ...) it iterates to
  the link list to find a match(strcasecmp())  When one is found
  it creates it and return the structure.
...
    list_append (bookie, path_record);
    list_append (bookie, pop_record);
    list_append (bookie, imap_record);
  }

  If you need only mailbox, you should be able to :
gcc -o my_app -lmailbox -lpop

  of if you prefer to do that at Runtime :
gcc -o my_app -lmailbox

and in the code :

  {
    list_t bookie;
    registrar_get_list (&bookie);
    handle = dlopen ("libpop.so", RTLD_LAZY);
    pop_record = dlsym(handle, "pop_record");
    list_append (bookie, pop_record);
  }

  Or if you have some new funky mailbox that you implemented :

   dlopen ("libmailencrypt_ssl.so", ...);
   ssl_record = dlsym (handle, "ssl_record");
....
    list_append (list, ssl_record);


Well that is the general idea, but we are not here yet, I have to get
libtool to generate shared libs for each type: pop.so, imap.so, mh.so
etc ...  Work in progress.
  
--
alain