bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: decode in mail


From: Alain Magloire
Subject: Re: decode in mail
Date: Fri, 27 Jul 2001 10:05:08 -0400 (EDT)

Bonjour

> > ... msglist is expand
> > will have to be change to return a structure:
> > 
> > struct {
> >  int msgno;
> >  int partno;
> > }
> > 
> > Comments?
> 
> Yes, it sounds good.
> 
> But if the same function (util_expand_msglist) will be used to expand
> lists inside the brackets, care should be taken not to allow more than
> 2 levels of recursion, otherwise a user might issue weird commands like:
> 
>        print 1[2[3[4]]]

Actually, this is possible(althought unlikely and weird):
MIME allows you to encapsulate a message within a message.  I think
the Content-Type is "message/rfc822". So the first message contains
a second rfc822 message which contains a third rfc822 message which
is 4 parts mime message.

> 
> Besides, a question of operator precedence arises. If one types:
> 
>        print 1-3[2]
> 
> should it be equivalent to
> 
>          print 1,2,3[2]
> 
> or
> 
>          print 1[2],2[2],3[2] ?
> 
> I would advocate for the latter.

I would vote for the former, it would make life easier.

print 1,2,3[2]

'[]' should be given precedence over the '-'.

To have the effect of the latter, I could see this

print (1-3)[2]

But introducing the '()' operator would probably be overkill 8-).

In the long run, it would be nice to have different expansion schemes,
for example, the wellknown MH (1..3), elm set of utilities selection list,
Berkeley /bin/mail msglist expansion, IMAP4 expansion.  Putting
this into a module in mailbox/ makes sense.

> By the way, if `print 1[2]' prints the part 2, `save 1[2] FILE'
> saves it to FILE, then it effectively duplicates the functionality
> of proposed `decode' command. We can then make `print 1[2]' behave
> the way we discussed for `decode', i.e. do some lookup in
> mailcap/mime.types, run appropriate viewer program, etc...
> In this case `decode' is superfluous.

Good rationale.  Yes, the [Pp]rint and the [Tt]ype command is meant
for (screen)display, it is probably useless to display pages of
base64 encoding.

> 
> Or is it supposed that usual commands print raw contents of the
> message part, whereas `decode' outputs decoded contents?

I think that was Jakob original plan.  But I can leave with [Pp]rint
acting smarter when paging messages.

--
alain




reply via email to

[Prev in Thread] Current Thread [Next in Thread]