Quand je tape dans un shell "open fichier.png", l'image fichier.png
est bien ouverte avec Preview. Mais si le nom du fichier contenant
une image de type connu (par exemple PNG) n'a pas d'extension, par
exemple "image", alors "open image" provoque l'ouverture de l'image
avec ColorSync (et une erreur à l'ouverture). Est-ce un bug d'open
ou y a-t-il un problème avec ma config?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Lefevre
Dans l'article <dpheg9$26rb$, Matt écrit:
On Wed, 4 Jan 2006 20:39:55 +0000 (UTC), Vincent Lefevre <vincent+ wrote:
Quand je tape dans un shell "open fichier.png", l'image fichier.png est bien ouverte avec Preview. Mais si le nom du fichier contenant une image de type connu (par exemple PNG) n'a pas d'extension, par exemple "image", alors "open image" provoque l'ouverture de l'image avec ColorSync (et une erreur à l'ouverture). Est-ce un bug d'open ou y a-t-il un problème avec ma config?
Ni l'un ni l'autre. Mac OS X se base soit sur l'extension, soit sur le type de fichier.
Au fait, est-il possible de demander à Mac OS X de ne pas prendre en compte l'extension (je n'ai pas vu d'option à "open" pour cela)? N'est-il pas possible de fournir à "open" le type MIME?
En gros, le fichier vient d'un attachement de mail, donc c'est le type MIME qui est déclaré et qui doit être pris en compte (l'extension peut être inexistante ou fausse, et la prendre en compte serait un trou de sécurité). C'est pour pouvoir lire des attachements depuis Mutt.
Tu peux changer cela avec des applications comme RCDefaultApp par exemple. Cf. <http://www.rubicode.com/>
J'avais déjà ce panneau. Je viens de changer la préférence pour PNG (ColorSync -> Preview), mais "open" a toujours le même comportement. Comment faire pour que cela soit pris en compte?
Dans l'article <dpheg9$26rb$1@talisker.lacave.net>,
Matt <hfrarg@syrius.org> écrit:
On Wed, 4 Jan 2006 20:39:55 +0000 (UTC),
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Quand je tape dans un shell "open fichier.png", l'image fichier.png
est bien ouverte avec Preview. Mais si le nom du fichier contenant
une image de type connu (par exemple PNG) n'a pas d'extension, par
exemple "image", alors "open image" provoque l'ouverture de l'image
avec ColorSync (et une erreur à l'ouverture). Est-ce un bug d'open
ou y a-t-il un problème avec ma config?
Ni l'un ni l'autre.
Mac OS X se base soit sur l'extension, soit sur le type de fichier.
Au fait, est-il possible de demander à Mac OS X de ne pas prendre en
compte l'extension (je n'ai pas vu d'option à "open" pour cela)?
N'est-il pas possible de fournir à "open" le type MIME?
En gros, le fichier vient d'un attachement de mail, donc c'est le
type MIME qui est déclaré et qui doit être pris en compte (l'extension
peut être inexistante ou fausse, et la prendre en compte serait un
trou de sécurité). C'est pour pouvoir lire des attachements depuis
Mutt.
Tu peux changer cela avec des applications comme RCDefaultApp par exemple.
Cf. <http://www.rubicode.com/>
J'avais déjà ce panneau. Je viens de changer la préférence pour PNG
(ColorSync -> Preview), mais "open" a toujours le même comportement.
Comment faire pour que cela soit pris en compte?
On Wed, 4 Jan 2006 20:39:55 +0000 (UTC), Vincent Lefevre <vincent+ wrote:
Quand je tape dans un shell "open fichier.png", l'image fichier.png est bien ouverte avec Preview. Mais si le nom du fichier contenant une image de type connu (par exemple PNG) n'a pas d'extension, par exemple "image", alors "open image" provoque l'ouverture de l'image avec ColorSync (et une erreur à l'ouverture). Est-ce un bug d'open ou y a-t-il un problème avec ma config?
Ni l'un ni l'autre. Mac OS X se base soit sur l'extension, soit sur le type de fichier.
Au fait, est-il possible de demander à Mac OS X de ne pas prendre en compte l'extension (je n'ai pas vu d'option à "open" pour cela)? N'est-il pas possible de fournir à "open" le type MIME?
En gros, le fichier vient d'un attachement de mail, donc c'est le type MIME qui est déclaré et qui doit être pris en compte (l'extension peut être inexistante ou fausse, et la prendre en compte serait un trou de sécurité). C'est pour pouvoir lire des attachements depuis Mutt.
Tu peux changer cela avec des applications comme RCDefaultApp par exemple. Cf. <http://www.rubicode.com/>
J'avais déjà ce panneau. Je viens de changer la préférence pour PNG (ColorSync -> Preview), mais "open" a toujours le même comportement. Comment faire pour que cela soit pris en compte?
Si mutt permet de lancer un script pour l'ouverture d'une pièce jointe,
C'est ce que je fais justement (en particulier, le script vérifie par un "file -bi" que le type MIME est correct ou presque, et il fait aussi une copie de la pièce jointe puisque open rend la main immédiatement, et le nettoyage de toutes les copies qui n'ont pas été lues depuis 6 heures).
écrire un petit script qui récupère le type mime et suivant ce dernier, on appelle open(1) avec l'option "-a" ou "-b" si une application Mac Carbon ou Cocoa est utilisée.
Je voulais justement éviter d'utiliser ces options pour une facilité de maintenance.
J'avais déjà ce panneau. Je viens de changer la préférence pour PNG (ColorSync -> Preview), mais "open" a toujours le même comportement. Comment faire pour que cela soit pris en compte?
En effaçant le cache de LaunchServices, cela devrait régler le problème (typiquement les fichiers plist /Library/Caches/com.apple.LaunchServices* puis relancer sa session).
Dans l'article <dphnlg$2h33$1@talisker.lacave.net>,
Matt <hfrarg@syrius.org> écrit:
Si mutt permet de lancer un script pour l'ouverture d'une pièce jointe,
C'est ce que je fais justement (en particulier, le script vérifie
par un "file -bi" que le type MIME est correct ou presque, et il
fait aussi une copie de la pièce jointe puisque open rend la main
immédiatement, et le nettoyage de toutes les copies qui n'ont pas
été lues depuis 6 heures).
écrire un petit script qui récupère le type mime et suivant ce
dernier, on appelle open(1) avec l'option "-a" ou "-b" si une
application Mac Carbon ou Cocoa est utilisée.
Je voulais justement éviter d'utiliser ces options pour une facilité
de maintenance.
J'avais déjà ce panneau. Je viens de changer la préférence pour PNG
(ColorSync -> Preview), mais "open" a toujours le même comportement.
Comment faire pour que cela soit pris en compte?
En effaçant le cache de LaunchServices, cela devrait régler le problème
(typiquement les fichiers plist /Library/Caches/com.apple.LaunchServices*
puis relancer sa session).
Si mutt permet de lancer un script pour l'ouverture d'une pièce jointe,
C'est ce que je fais justement (en particulier, le script vérifie par un "file -bi" que le type MIME est correct ou presque, et il fait aussi une copie de la pièce jointe puisque open rend la main immédiatement, et le nettoyage de toutes les copies qui n'ont pas été lues depuis 6 heures).
écrire un petit script qui récupère le type mime et suivant ce dernier, on appelle open(1) avec l'option "-a" ou "-b" si une application Mac Carbon ou Cocoa est utilisée.
Je voulais justement éviter d'utiliser ces options pour une facilité de maintenance.
J'avais déjà ce panneau. Je viens de changer la préférence pour PNG (ColorSync -> Preview), mais "open" a toujours le même comportement. Comment faire pour que cela soit pris en compte?
En effaçant le cache de LaunchServices, cela devrait régler le problème (typiquement les fichiers plist /Library/Caches/com.apple.LaunchServices* puis relancer sa session).
Si mutt permet de lancer un script pour l'ouverture d'une pièce jointe,
C'est ce que je fais justement (en particulier, le script vérifie par un "file -bi" que le type MIME est correct ou presque, et il fait aussi une copie de la pièce jointe puisque open rend la main immédiatement, et le nettoyage de toutes les copies qui n'ont pas été lues depuis 6 heures).
Ça m'intéresse, ça...
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
Vincent Lefevre <vincent+news@vinc17.org> écrivait :
Dans l'article <dphnlg$2h33$1@talisker.lacave.net>,
Matt <hfrarg@syrius.org> écrit:
Si mutt permet de lancer un script pour l'ouverture d'une pièce jointe,
C'est ce que je fais justement (en particulier, le script vérifie
par un "file -bi" que le type MIME est correct ou presque, et il
fait aussi une copie de la pièce jointe puisque open rend la main
immédiatement, et le nettoyage de toutes les copies qui n'ont pas
été lues depuis 6 heures).
Ça m'intéresse, ça...
--
Si vous embauchez, voici mon CV
http://www.rail.eu.org/cv/cv.pdf
Si mutt permet de lancer un script pour l'ouverture d'une pièce jointe,
C'est ce que je fais justement (en particulier, le script vérifie par un "file -bi" que le type MIME est correct ou presque, et il fait aussi une copie de la pièce jointe puisque open rend la main immédiatement, et le nettoyage de toutes les copies qui n'ont pas été lues depuis 6 heures).
Ça m'intéresse, ça...
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
Vincent Lefevre
Dans l'article <dpi4mf$7gq$, Matt écrit:
Si vraiment cela t'empêche de dormir, tu peux soumettre ta frustration à Apple par le biais de :
C'est ce que je fais justement (en particulier, le script vérifie par un "file -bi" que le type MIME est correct ou presque, et il fait aussi une copie de la pièce jointe puisque open rend la main immédiatement, et le nettoyage de toutes les copies qui n'ont pas été lues depuis 6 heures).
# Open the file under a name that won't be removed by Mutt... # Note: the rm is necessary otherwise the file gets corrupted! I assume # that for security reasons (not possible under Mac OS X), Mutt really # clears the temporary file before removing it. ln -nT "$1" "$file" test -O "$file" open "$file" rm "$1"
# Some clean-up (this should also probably be done by cron): # Remove the files that haven't been accessed since 6 hours. find "$d" -maxdepth 1 -name "${prefix}*" -amin +360 -type f -user "$USER" -exec /bin/rm {} ;
Je n'ai pas encore modifié le open. Je pense que la solution est de fournir un autre argument à view-attach spécifiant l'application; ainsi seul le .mailcap devra être modifié en cas de sous-type MIME à ouvrir avec une autre application (suivant les préférences de l'utilisateur).
Une note concernant le rm "$1" dans le script: une possibilité était de faire une copie du fichier, mais cela aurait pris plus d'espace disque. Je fais donc un lien hard, et un rm avant le retour à Mutt pour que Mutt ne puisse pas retrouver le fichier et le remettre à zéro (avant de l'effacer). Ceci dit, un mv -T doit tout aussi bien marcher.
Enfin, si le répertoire est public, ce genre de chose doit être fait sur un système de fichiers où ces commandes sont atomiques.
Dans l'article <87psn7kll1.fsf@nez-casse.depot.rail.eu.org>,
Erwan David <erwan@rail.eu.org> écrit:
Vincent Lefevre <vincent+news@vinc17.org> écrivait :
C'est ce que je fais justement (en particulier, le script vérifie
par un "file -bi" que le type MIME est correct ou presque, et il
fait aussi une copie de la pièce jointe puisque open rend la main
immédiatement, et le nettoyage de toutes les copies qui n'ont pas
été lues depuis 6 heures).
# Open the file under a name that won't be removed by Mutt...
# Note: the rm is necessary otherwise the file gets corrupted! I assume
# that for security reasons (not possible under Mac OS X), Mutt really
# clears the temporary file before removing it.
ln -nT "$1" "$file"
test -O "$file"
open "$file"
rm "$1"
# Some clean-up (this should also probably be done by cron):
# Remove the files that haven't been accessed since 6 hours.
find "$d" -maxdepth 1 -name "${prefix}*" -amin +360 -type f -user "$USER"
-exec /bin/rm {} ;
Je n'ai pas encore modifié le open. Je pense que la solution est de
fournir un autre argument à view-attach spécifiant l'application;
ainsi seul le .mailcap devra être modifié en cas de sous-type MIME
à ouvrir avec une autre application (suivant les préférences de
l'utilisateur).
Une note concernant le rm "$1" dans le script: une possibilité était de
faire une copie du fichier, mais cela aurait pris plus d'espace disque.
Je fais donc un lien hard, et un rm avant le retour à Mutt pour que
Mutt ne puisse pas retrouver le fichier et le remettre à zéro (avant
de l'effacer). Ceci dit, un mv -T doit tout aussi bien marcher.
Enfin, si le répertoire est public, ce genre de chose doit être fait
sur un système de fichiers où ces commandes sont atomiques.
C'est ce que je fais justement (en particulier, le script vérifie par un "file -bi" que le type MIME est correct ou presque, et il fait aussi une copie de la pièce jointe puisque open rend la main immédiatement, et le nettoyage de toutes les copies qui n'ont pas été lues depuis 6 heures).
# Open the file under a name that won't be removed by Mutt... # Note: the rm is necessary otherwise the file gets corrupted! I assume # that for security reasons (not possible under Mac OS X), Mutt really # clears the temporary file before removing it. ln -nT "$1" "$file" test -O "$file" open "$file" rm "$1"
# Some clean-up (this should also probably be done by cron): # Remove the files that haven't been accessed since 6 hours. find "$d" -maxdepth 1 -name "${prefix}*" -amin +360 -type f -user "$USER" -exec /bin/rm {} ;
Je n'ai pas encore modifié le open. Je pense que la solution est de fournir un autre argument à view-attach spécifiant l'application; ainsi seul le .mailcap devra être modifié en cas de sous-type MIME à ouvrir avec une autre application (suivant les préférences de l'utilisateur).
Une note concernant le rm "$1" dans le script: une possibilité était de faire une copie du fichier, mais cela aurait pris plus d'espace disque. Je fais donc un lien hard, et un rm avant le retour à Mutt pour que Mutt ne puisse pas retrouver le fichier et le remettre à zéro (avant de l'effacer). Ceci dit, un mv -T doit tout aussi bien marcher.
Enfin, si le répertoire est public, ce genre de chose doit être fait sur un système de fichiers où ces commandes sont atomiques.
