mutt/2205: problem with long lines in mailcap files

[telegraph@xxxxxxx]

>Number:         2205
>Notify-List:    
>Category:       mutt
>Synopsis:       problem with long lines in mailcap files
>Confidential:   no
>Severity:       normal
>Priority:       medium
>Responsible:    mutt-dev
>State:          open
>Keywords:       
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 18 20:45:43 +0200 2006
>Originator:     Gregor Zattler
>Release:        1.5.11 (cvs 2006-04-18 15:28:50, according to ChangeLog)
>Organization:
>Environment:
debian unstable

$ uname -a
Linux pit.ID-43118.user.dfncis.de 2.6.16.7 #4 PREEMPT Tue Apr 18 14:25:07 CEST 
2006 i686 GNU/Linux
>Description:
Mutt somehow chops long lines in mailcap files before executing
the according commands via
sh -c "..."

This causes different error messages which depend on line lengths,
lengths of file names and which shell is used.



I used to have long lines like this[1]:

application/* ; run-mailcap --action=view $(file -m 
/home/grfz/.magic:/home/grfz/.mutt/.magic:/etc/magic:/usr/share/file/magic -bi 
%s 2>/dev/null):%s

in my ~/.mutt/mailcap.mutt which is first entry in my
mailcap_path.  I saw error messages like:


sh: /tmp: Is a directory

or:

sh: /bi: No such file or directory

or:

sh: -c: line 0: unexpected EOF while looking for matching `''
sh: -c: line 1: syntax error: unexpected end of file


I then experimented with

application/* ; FULLFILENAME=%s && FILECONTENTTYPE=$(file -m 
/home/grfz/.magic:/home/grfz/.mutt/.magic:/etc/magic:/usr/share/file/magic -bi 
$FULLFILENAME 2>/dev/null) && /bin/echo ${FILECONTENTTYPE}:${FULLFILENAME} 
2>/tmp/nuk >/tmp/buk

which produced error messages like:

sh: /bi: No such file or directory

or:

sh: -c: line 0: unexpected EOF while looking for matching `}'
sh: -c: line 1: syntax error: unexpected end of file

(all examples with /bin/sh -->/bin/bash).


{
   Strange enough this problem does not occur with auto_viewed
   attachments (at least not with my test emails and their
   attachments).  I use mailcap entries like this:

   application/* ; MM_QUIET=1 MAILCAPS=/home/grfz/.mailcap-copiousoutput 
metamail  -d -b -c $(file -m 
/home/grfz/.magic:/home/grfz/.mutt/.magic:/etc/magic:/usr/share/file/magic -bi 
%s 2>/dev/null) %s ; copiousoutput

   this way I can read most attachments in the pager.
}



Starting mutt like this:

MAGIC=/home/grfz/.magic:/home/grfz/.mutt/.magic:/etc/magic:/usr/share/file/magic
 mutt

and using a much shorter mailcap entry:

application/* ; run-mailcap $(file -bi %s):%s

"solves" the problem.



Thanx,
Gregor



Footnotes:
[1]  This nested mailcap handling copes with buggy MUAs which send
     email attachments with wrong mime types (ms word documents
     flagged as application/octet-stream or as application/rtf or
     as application/ms-word)

>How-To-Repeat:
>Fix:
use shorter mailcap entrys.
>Add-To-Audit-Trail:

>Unformatted: