mutt & mailcap

[dpr]

Hallo,

ich habe hier ein 10.4.6 und mutt 1.5.11 (fink).

Ich möchte aus mutt heraus zur Betrachtung von Attachments die jeweiligen Applikationen (hier am Beispiel einmal Preview) starten. mime.types existiert und wird gelesen. In ~/.mailcap habe ich

application/pdf;open -a /Applications/Preview.app %s
image/jpeg;open -a /Applications/Preview.app %s

Das erwartete Verhalten wäre: ich lasse mir die Liste der Attachments einer Mail anzeigen ('v'), navigiere zum gewünschten Attachment, drücke Enter, Applikation startet und zeigt das per Argument übergebene File an.

Was passiert: die richtige Applikation startet, allerdings wird das darzustellende File nicht geladen; zumindest wird es nicht angezeigt.

Nun hätte es ja sein können, daß die Übergabe als Argument (oben: %s) nicht funktioniert. Deswegen habe ich die .mailcap (um eine Fehlermeldung zu erzwingen) temporär geändert:

application/pdf;'open -a /Applications/Preview.app %s'
image/jpeg;'open -a /Applications/Preview.app %s'

Klar klappt das nicht, aber es gibt als Fehlermeldung

open -a /Applications/Preview.app /tmp/foobar.jpg: No such file or directory

was darauf hinweist, das mein Problem nicht eine fehlerhafte Übergabe des darzustellenden Files ist.

Auf der Kommandozeile macht erstaunlicherweise

open -a /Applications/Preview.app /tmp/foobar.jpg

genau, was ich erwarten würde: das JPEG wird durch Preview angezeigt.

So, und nun gehen mir die Ideen aus. Hat jemand einen Vorschlag (außer "Use the source, Luke" ;-) Das kommt, wenn gar nichts helfen will.)

Danke, Denny

 

[dpr]

Niemand eine Idee oder ist meine Problembeschreibung mißverständlich?

Ich habe jetzt einmal mutt 1.4.2 getestet, daran liegt es nicht. Auch die Umgebungsvariablen unterscheiden sich bis auf SHLVL zwischen open ... aus dem Terminal oder aus mutt heraus nicht.

Also, nur Mut. Immer raus mit den Spekulationen!

 

[dpr]

Witziges Betrübssystem habe ich hier

Folgender Zwischenstand:

image/jpeg; open -a /Applications/Preview.app %s

in der ~/.mailcap wollte ja nicht zum gewünschten Ergebnis führen. Etwas trial and error ergab nun:

open -a /Applications/Preview.app %s auf einer Kopie von %s funktioniert!

Die Langfassung: ich habe zum Test meine ~/.mailcap geändert in

image/jpeg; /tmp/test.sh %s

mit /tmp/test.sh:

!/bin/sh

NN=/tmp/mutt_tmp_`basename $*`
cp $* $NN
open -a /Applications/Preview.app $NN

also einer simplen Kopie des anzuzeigenden Files. Das funktioniert wie erwartet. Die große Preisfrage ist nun: warum? lsof sagt mir, daß das Original nicht einmal mehr offen ist, also an der Anzahl der das Originalfile referenzierenden Prozesse kann es nicht liegen.

Ideen zur Erklärung?

 

[dpr]

Use the source, Luke

Falls es jemanden interessiert...

Problem erkannt: nach erfolgreichem exit des in der mailcap spezifizierten Programms zur Anzeige eines MIME-Types wird das temporäre File, das dieses Attachment enthält, von mutt gelöscht. Da open allerdings sofort zurückkommt und seine Arbeit im Hintergrund verrichtet, gibt es, wenn dann die durch open gestartete Applikation bereit ist, das anzuzeigende File nicht mehr. Eine Fehlermeldung wäre ja mal ganz hilfreich, aber das ist wohl ein anderes Thema.

Da man open nicht dazu überreden kann, auf die zu startende Applikation zu warten, muß mutt das fixen: needsterminal in die ~/.mailcap und ein 'set wait_key=yes' (ist eh default) in die ~/.muttrc behebt das Problem.