J'arrive pas =E0 envoyer un mail sous unix/linux en ligne de commande
avec de la couleur :
echo " un ^[[31m deux ^[[0m trois " | mail -s "voyons"
mon_adresse@mail.com
Ce genre de commande marche tres bien (deux en rouge) si j'envoie ce
message sur une machine unix.
Dans le terminal les commandes unix mail d=E9cryptent tr=E8s bien les
caract=E8res d'=E9chappement couleur.
Par contre si j'envoie vers un serveur externe : Lotus / yahoo /gmail
Le message est compris comme une pi=E8ce jointe extension .dat ...
J'essaie de me battre avec les commandes uuencode , les types mime etc
j'arrive a recevoir les caract=E8res textes mais je perd l'iformation de
couleur
Avez vous des id=E9es, une solution
(pour pas avoir =E0 cr=E9er une page html)
J'arrive pas à envoyer un mail sous unix/linux en ligne de commande avec de la couleur :
echo " un ^[[31m deux ^[[0m trois " | mail -s "voyons"
Ce genre de commande marche tres bien (deux en rouge) si j'envoie ce message sur une machine unix. Dans le terminal les commandes unix mail décryptent très bien les caractères d'échappement couleur.
Amusant.
Par contre si j'envoie vers un serveur externe : Lotus / yahoo /gmail Le message est compris comme une pièce jointe extension .dat ...
Mais... tu récupères le message depuis ce serveur externe avec le même unix mail ?
J'essaie de me battre avec les commandes uuencode , les types mime etc j'arrive a recevoir les caractères textes mais je perd l'iformation de couleur
Avez vous des idées, une solution (pour pas avoir à créer une page html)
Peut-être qu'en local le comportement est différent, et qu'il n'a pas besoin de s'assurer qu'il n'y a que des caractères autorisés ? Quel charset utilises-tu, au fait ? De mémoire, les charsets les plus courants n'autorisent pas forcément tous les codes de contrôle ASCII (donc pas le code ESC).
J'arrive pas à envoyer un mail sous unix/linux en ligne de commande
avec de la couleur :
echo " un ^[[31m deux ^[[0m trois " | mail -s "voyons"
mon_adresse@mail.com
Ce genre de commande marche tres bien (deux en rouge) si j'envoie ce
message sur une machine unix.
Dans le terminal les commandes unix mail décryptent très bien les
caractères d'échappement couleur.
Amusant.
Par contre si j'envoie vers un serveur externe : Lotus / yahoo /gmail
Le message est compris comme une pièce jointe extension .dat ...
Mais... tu récupères le message depuis ce serveur externe avec le même
unix mail ?
J'essaie de me battre avec les commandes uuencode , les types mime etc
j'arrive a recevoir les caractères textes mais je perd l'iformation de
couleur
Avez vous des idées, une solution
(pour pas avoir à créer une page html)
Peut-être qu'en local le comportement est différent, et qu'il n'a pas
besoin de s'assurer qu'il n'y a que des caractères autorisés ? Quel
charset utilises-tu, au fait ? De mémoire, les charsets les plus
courants n'autorisent pas forcément tous les codes de contrôle ASCII
(donc pas le code ESC).
J'arrive pas à envoyer un mail sous unix/linux en ligne de commande avec de la couleur :
echo " un ^[[31m deux ^[[0m trois " | mail -s "voyons"
Ce genre de commande marche tres bien (deux en rouge) si j'envoie ce message sur une machine unix. Dans le terminal les commandes unix mail décryptent très bien les caractères d'échappement couleur.
Amusant.
Par contre si j'envoie vers un serveur externe : Lotus / yahoo /gmail Le message est compris comme une pièce jointe extension .dat ...
Mais... tu récupères le message depuis ce serveur externe avec le même unix mail ?
J'essaie de me battre avec les commandes uuencode , les types mime etc j'arrive a recevoir les caractères textes mais je perd l'iformation de couleur
Avez vous des idées, une solution (pour pas avoir à créer une page html)
Peut-être qu'en local le comportement est différent, et qu'il n'a pas besoin de s'assurer qu'il n'y a que des caractères autorisés ? Quel charset utilises-tu, au fait ? De mémoire, les charsets les plus courants n'autorisent pas forcément tous les codes de contrôle ASCII (donc pas le code ESC).
poulacou
On 30 avr, 11:26, Olivier Miakinen <om+ wrote:
J'arrive pas à envoyer un mail sous unix/linux en ligne de commande avec de la couleur :
echo " un ^[[31m deux ^[[0m trois " | mail -s "voyons"
Ce genre de commande marche tres bien (deux en rouge) si j'envoie ce message sur une machine unix. Dans le terminal les commandes unix mail décryptent très bien les caractères d'échappement couleur.
Amusant.
Par contre si j'envoie vers un serveur externe : Lotus / yahoo /gmail Le message est compris comme une pièce jointe extension .dat ...
Mais... tu récupères le message depuis ce serveur externe avec le mê me unix mail ?
Non le serveur mail est différent : Domino avec comme client Lotus contre machine linux locale
J'essaie de me battre avec les commandes uuencode , les types mime etc j'arrive a recevoir les caractères textes mais je perd l'iformation de couleur
Avez vous des idées, une solution (pour pas avoir à créer une page html)
Peut-être qu'en local le comportement est différent, et qu'il n'a pas besoin de s'assurer qu'il n'y a que des caractères autorisés ? Quel charset utilises-tu, au fait ? De mémoire, les charsets les plus courants n'autorisent pas forcément tous les codes de contrôle ASCII (donc pas le code ESC).
c'est justement mes interrogations ... Tout est fait pas defaut Je voie : Content-Type: message/rfc822
On 30 avr, 11:26, Olivier Miakinen <om+n...@miakinen.net> wrote:
J'arrive pas à envoyer un mail sous unix/linux en ligne de commande
avec de la couleur :
echo " un ^[[31m deux ^[[0m trois " | mail -s "voyons"
mon_adre...@mail.com
Ce genre de commande marche tres bien (deux en rouge) si j'envoie ce
message sur une machine unix.
Dans le terminal les commandes unix mail décryptent très bien les
caractères d'échappement couleur.
Amusant.
Par contre si j'envoie vers un serveur externe : Lotus / yahoo /gmail
Le message est compris comme une pièce jointe extension .dat ...
Mais... tu récupères le message depuis ce serveur externe avec le mê me
unix mail ?
Non le serveur mail est différent : Domino avec comme client Lotus
contre machine linux locale
J'essaie de me battre avec les commandes uuencode , les types mime etc
j'arrive a recevoir les caractères textes mais je perd l'iformation de
couleur
Avez vous des idées, une solution
(pour pas avoir à créer une page html)
Peut-être qu'en local le comportement est différent, et qu'il n'a pas
besoin de s'assurer qu'il n'y a que des caractères autorisés ? Quel
charset utilises-tu, au fait ? De mémoire, les charsets les plus
courants n'autorisent pas forcément tous les codes de contrôle ASCII
(donc pas le code ESC).
c'est justement mes interrogations ...
Tout est fait pas defaut
Je voie : Content-Type: message/rfc822
J'arrive pas à envoyer un mail sous unix/linux en ligne de commande avec de la couleur :
echo " un ^[[31m deux ^[[0m trois " | mail -s "voyons"
Ce genre de commande marche tres bien (deux en rouge) si j'envoie ce message sur une machine unix. Dans le terminal les commandes unix mail décryptent très bien les caractères d'échappement couleur.
Amusant.
Par contre si j'envoie vers un serveur externe : Lotus / yahoo /gmail Le message est compris comme une pièce jointe extension .dat ...
Mais... tu récupères le message depuis ce serveur externe avec le mê me unix mail ?
Non le serveur mail est différent : Domino avec comme client Lotus contre machine linux locale
J'essaie de me battre avec les commandes uuencode , les types mime etc j'arrive a recevoir les caractères textes mais je perd l'iformation de couleur
Avez vous des idées, une solution (pour pas avoir à créer une page html)
Peut-être qu'en local le comportement est différent, et qu'il n'a pas besoin de s'assurer qu'il n'y a que des caractères autorisés ? Quel charset utilises-tu, au fait ? De mémoire, les charsets les plus courants n'autorisent pas forcément tous les codes de contrôle ASCII (donc pas le code ESC).
c'est justement mes interrogations ... Tout est fait pas defaut Je voie : Content-Type: message/rfc822
Olivier Miakinen
echo " un ^[[31m deux ^[[0m trois " | mail -s "voyons"
Ce genre de commande marche tres bien (deux en rouge) si j'envoie ce message sur une machine unix. Dans le terminal les commandes unix mail décryptent très bien les caractères d'échappement couleur.
J'avais oublié de rectifier en répondant à ton premier article : ce n'est évidemment pas « les commandes unix mail » qui décryptent les séquences ANSI, mais ton terminal en mode texte.
Par contre si j'envoie vers un serveur externe : Lotus / yahoo /gmail Le message est compris comme une pièce jointe extension .dat ...
Mais... tu récupères le message depuis ce serveur externe avec le même unix mail ?
Non le serveur mail est différent :
Je ne parlais pas du serveur ici, mais du client. Pour que ça puisse avoir une chance de marcher, il faut bien sûr que tu lises le courriel dans le même terminal unix, celui qui comprendre les séquences ANSI.
Domino avec comme client Lotus contre machine linux locale
Je ne connais pas le client Lotus, mais je parierais qu'il ouvre sa propre fenêtre d'affichage au lieu d'envoyer le texte vers un tty. Dans ce cas, il n'y a aucun espoir.
Tout est fait pas defaut Je voie : Content-Type: message/rfc822
Et si tu sauves le contenu dans un fichier texte que tu affiches (commande cat) dans un simple tty, ça donne quoi ?
echo " un ^[[31m deux ^[[0m trois " | mail -s "voyons"
mon_adre...@mail.com
Ce genre de commande marche tres bien (deux en rouge) si j'envoie ce
message sur une machine unix.
Dans le terminal les commandes unix mail décryptent très bien les
caractères d'échappement couleur.
J'avais oublié de rectifier en répondant à ton premier article : ce
n'est évidemment pas « les commandes unix mail » qui décryptent les
séquences ANSI, mais ton terminal en mode texte.
Par contre si j'envoie vers un serveur externe : Lotus / yahoo /gmail
Le message est compris comme une pièce jointe extension .dat ...
Mais... tu récupères le message depuis ce serveur externe avec le même
unix mail ?
Non le serveur mail est différent :
Je ne parlais pas du serveur ici, mais du client. Pour que ça puisse
avoir une chance de marcher, il faut bien sûr que tu lises le courriel
dans le même terminal unix, celui qui comprendre les séquences ANSI.
Domino avec comme client Lotus
contre machine linux locale
Je ne connais pas le client Lotus, mais je parierais qu'il ouvre sa
propre fenêtre d'affichage au lieu d'envoyer le texte vers un tty.
Dans ce cas, il n'y a aucun espoir.
Tout est fait pas defaut
Je voie : Content-Type: message/rfc822
Et si tu sauves le contenu dans un fichier texte que tu affiches
(commande cat) dans un simple tty, ça donne quoi ?
echo " un ^[[31m deux ^[[0m trois " | mail -s "voyons"
Ce genre de commande marche tres bien (deux en rouge) si j'envoie ce message sur une machine unix. Dans le terminal les commandes unix mail décryptent très bien les caractères d'échappement couleur.
J'avais oublié de rectifier en répondant à ton premier article : ce n'est évidemment pas « les commandes unix mail » qui décryptent les séquences ANSI, mais ton terminal en mode texte.
Par contre si j'envoie vers un serveur externe : Lotus / yahoo /gmail Le message est compris comme une pièce jointe extension .dat ...
Mais... tu récupères le message depuis ce serveur externe avec le même unix mail ?
Non le serveur mail est différent :
Je ne parlais pas du serveur ici, mais du client. Pour que ça puisse avoir une chance de marcher, il faut bien sûr que tu lises le courriel dans le même terminal unix, celui qui comprendre les séquences ANSI.
Domino avec comme client Lotus contre machine linux locale
Je ne connais pas le client Lotus, mais je parierais qu'il ouvre sa propre fenêtre d'affichage au lieu d'envoyer le texte vers un tty. Dans ce cas, il n'y a aucun espoir.
Tout est fait pas defaut Je voie : Content-Type: message/rfc822
Et si tu sauves le contenu dans un fichier texte que tu affiches (commande cat) dans un simple tty, ça donne quoi ?
Nicolas George
Olivier Miakinen wrote in message <4818bfb9$:
Je ne parlais pas du serveur ici, mais du client. Pour que ça puisse avoir une chance de marcher, il faut bien sûr que tu lises le courriel dans le même terminal unix, celui qui comprendre les séquences ANSI.
Il faut aussi que le client en mode texte considéré laisse passer les séquences d'échappement directement vers le terminal, ce qui est d'assez mauvais goût, et peut constituer un trou de sécurité dans certaines circonstances.
Olivier Miakinen wrote in message <4818bfb9$1@neottia.net>:
Je ne parlais pas du serveur ici, mais du client. Pour que ça puisse
avoir une chance de marcher, il faut bien sûr que tu lises le courriel
dans le même terminal unix, celui qui comprendre les séquences ANSI.
Il faut aussi que le client en mode texte considéré laisse passer les
séquences d'échappement directement vers le terminal, ce qui est d'assez
mauvais goût, et peut constituer un trou de sécurité dans certaines
circonstances.
Je ne parlais pas du serveur ici, mais du client. Pour que ça puisse avoir une chance de marcher, il faut bien sûr que tu lises le courriel dans le même terminal unix, celui qui comprendre les séquences ANSI.
Il faut aussi que le client en mode texte considéré laisse passer les séquences d'échappement directement vers le terminal, ce qui est d'assez mauvais goût, et peut constituer un trou de sécurité dans certaines circonstances.
xtof.pernod
Olivier Miakinen wrote in message <4818bfb9$:
Je ne parlais pas du serveur ici, mais du client. Pour que ça puisse avoir une chance de marcher, il faut bien sûr que tu lises le courriel dans le même terminal unix, celui qui comprendre les séquences ANSI.
Il faut aussi que le client en mode texte considéré laisse passer les séquences d'échappement directement vers le terminal, ce qui est d'assez mauvais goût, et peut constituer un trou de sécurité dans certaines circonstances.
Ah tient ? Comment ce peut-ce ? Peut-on déclencher des commandes avec des séquences ANSI ?
Je sais que tu peux interroger le tty avec des commandes, mais la je vois pas ; tu aurais un exemple ?
Dans ce cas, tu peux pieger un ./README avec, et le premier qui fait un 'cat ./README' se ferait avoir ?..
-- christophe.
Olivier Miakinen wrote in message <4818bfb9$1@neottia.net>:
Je ne parlais pas du serveur ici, mais du client. Pour que ça puisse
avoir une chance de marcher, il faut bien sûr que tu lises le courriel
dans le même terminal unix, celui qui comprendre les séquences ANSI.
Il faut aussi que le client en mode texte considéré laisse passer les
séquences d'échappement directement vers le terminal, ce qui est d'assez
mauvais goût, et peut constituer un trou de sécurité dans certaines
circonstances.
Ah tient ? Comment ce peut-ce ?
Peut-on déclencher des commandes avec des séquences ANSI ?
Je sais que tu peux interroger le tty avec des commandes, mais la
je vois pas ; tu aurais un exemple ?
Dans ce cas, tu peux pieger un ./README avec, et le premier qui
fait un 'cat ./README' se ferait avoir ?..
Je ne parlais pas du serveur ici, mais du client. Pour que ça puisse avoir une chance de marcher, il faut bien sûr que tu lises le courriel dans le même terminal unix, celui qui comprendre les séquences ANSI.
Il faut aussi que le client en mode texte considéré laisse passer les séquences d'échappement directement vers le terminal, ce qui est d'assez mauvais goût, et peut constituer un trou de sécurité dans certaines circonstances.
Ah tient ? Comment ce peut-ce ? Peut-on déclencher des commandes avec des séquences ANSI ?
Je sais que tu peux interroger le tty avec des commandes, mais la je vois pas ; tu aurais un exemple ?
Dans ce cas, tu peux pieger un ./README avec, et le premier qui fait un 'cat ./README' se ferait avoir ?..
-- christophe.
Jean-Marc Bourguet
"xtof.pernod" writes:
Je sais que tu peux interroger le tty avec des commandes, mais la je vois pas ; tu aurais un exemple ?
On peut definir certaines touches (de memoire uniquement des touches de fonctions).
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
"xtof.pernod" <xtof.pernod@NOSPAMfree.fr> writes:
Je sais que tu peux interroger le tty avec des commandes, mais la
je vois pas ; tu aurais un exemple ?
On peut definir certaines touches (de memoire uniquement des touches de
fonctions).
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je sais que tu peux interroger le tty avec des commandes, mais la je vois pas ; tu aurais un exemple ?
On peut definir certaines touches (de memoire uniquement des touches de fonctions).
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Nicolas George
"xtof.pernod" wrote in message <481aefc4$0$874$:
Je sais que tu peux interroger le tty avec des commandes, mais la je vois pas ; tu aurais un exemple ?
Les terminaux actuels font des efforts pour éviter ces problèmes. Mais assez schématiquement, on peut interroger le titre du terminal, par exemple, et le changer. Si ce n'est pas bien fait, c'est un trou.
Dans ce cas, tu peux pieger un ./README avec, et le premier qui fait un 'cat ./README' se ferait avoir ?..
D'où l'intérêt de ne pas utiliser cat pour ça mais un vrai pager. D'ailleurs, même actuellement, un cat README peut lancer des dizaines de pages d'impression, ce n'est pas terrible non plus.
"xtof.pernod" wrote in message
<481aefc4$0$874$ba4acef3@news.orange.fr>:
Je sais que tu peux interroger le tty avec des commandes, mais la
je vois pas ; tu aurais un exemple ?
Les terminaux actuels font des efforts pour éviter ces problèmes. Mais assez
schématiquement, on peut interroger le titre du terminal, par exemple, et le
changer. Si ce n'est pas bien fait, c'est un trou.
Dans ce cas, tu peux pieger un ./README avec, et le premier qui
fait un 'cat ./README' se ferait avoir ?..
D'où l'intérêt de ne pas utiliser cat pour ça mais un vrai pager.
D'ailleurs, même actuellement, un cat README peut lancer des dizaines de
pages d'impression, ce n'est pas terrible non plus.
Je sais que tu peux interroger le tty avec des commandes, mais la je vois pas ; tu aurais un exemple ?
Les terminaux actuels font des efforts pour éviter ces problèmes. Mais assez schématiquement, on peut interroger le titre du terminal, par exemple, et le changer. Si ce n'est pas bien fait, c'est un trou.
Dans ce cas, tu peux pieger un ./README avec, et le premier qui fait un 'cat ./README' se ferait avoir ?..
D'où l'intérêt de ne pas utiliser cat pour ça mais un vrai pager. D'ailleurs, même actuellement, un cat README peut lancer des dizaines de pages d'impression, ce n'est pas terrible non plus.
Nicolas George
"xtof.pernod" wrote in message <481aefc4$0$874$:
Je sais que tu peux interroger le tty avec des commandes, mais la je vois pas ; tu aurais un exemple ?
Les terminaux actuels font des efforts pour éviter ces problèmes. Mais assez schématiquement, on peut interroger le titre du terminal, par exemple, et le changer. Si ce n'est pas bien fait, c'est un trou.
Dans ce cas, tu peux pieger un ./README avec, et le premier qui fait un 'cat ./README' se ferait avoir ?..
D'où l'intérêt de ne pas utiliser cat pour ça mais un vrai pager.
"xtof.pernod" wrote in message
<481aefc4$0$874$ba4acef3@news.orange.fr>:
Je sais que tu peux interroger le tty avec des commandes, mais la
je vois pas ; tu aurais un exemple ?
Les terminaux actuels font des efforts pour éviter ces problèmes. Mais assez
schématiquement, on peut interroger le titre du terminal, par exemple, et le
changer. Si ce n'est pas bien fait, c'est un trou.
Dans ce cas, tu peux pieger un ./README avec, et le premier qui
fait un 'cat ./README' se ferait avoir ?..
D'où l'intérêt de ne pas utiliser cat pour ça mais un vrai pager.
Je sais que tu peux interroger le tty avec des commandes, mais la je vois pas ; tu aurais un exemple ?
Les terminaux actuels font des efforts pour éviter ces problèmes. Mais assez schématiquement, on peut interroger le titre du terminal, par exemple, et le changer. Si ce n'est pas bien fait, c'est un trou.
Dans ce cas, tu peux pieger un ./README avec, et le premier qui fait un 'cat ./README' se ferait avoir ?..
D'où l'intérêt de ne pas utiliser cat pour ça mais un vrai pager.
Nicolas George
"xtof.pernod" wrote in message <481b256c$0$925$:
D'ailleurs, même actuellement, un cat README peut lancer des dizaines pages d'impression, ce n'est pas terrible non plus.
Les dégats sont limités: un (''gros'') README au hasard:
Quand je dis « impression », je parle d'impression, pas d'affichage à l'écran. Il y a des séquences d'échappement pour demander au terminal d'imprimer son contenu.
"xtof.pernod" wrote in message
<481b256c$0$925$ba4acef3@news.orange.fr>:
D'ailleurs, même actuellement, un cat README peut lancer des dizaines
pages d'impression, ce n'est pas terrible non plus.
Les dégats sont limités: un (''gros'') README au hasard:
Quand je dis « impression », je parle d'impression, pas d'affichage à
l'écran. Il y a des séquences d'échappement pour demander au terminal
d'imprimer son contenu.
D'ailleurs, même actuellement, un cat README peut lancer des dizaines pages d'impression, ce n'est pas terrible non plus.
Les dégats sont limités: un (''gros'') README au hasard:
Quand je dis « impression », je parle d'impression, pas d'affichage à l'écran. Il y a des séquences d'échappement pour demander au terminal d'imprimer son contenu.
Vincent Lefevre
Dans l'article <481b2839$0$4860$, Nicolas George <nicolas$ écrit:
Quand je dis « impression », je parle d'impression, pas d'affichage à l'écran. Il y a des séquences d'échappement pour demander au terminal d'imprimer son contenu.
Pour info, xterm avait cette fonctionnalité activée par défaut. Cela a été corrigé il y a deux ans:
Le problème des séquences d'échappement peut aussi se produire avec les noms de fichiers (ce qui est problématique, e.g. quand on est sous NFS, mais peut-être aussi quand on sauve des fichiers dont le nom est proposé par le serveur/utilisateur distant). Les utilitaires find (des findutils) et less étaient vulnérables:
Dans l'article <481b2839$0$4860$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Quand je dis « impression », je parle d'impression, pas d'affichage à
l'écran. Il y a des séquences d'échappement pour demander au terminal
d'imprimer son contenu.
Pour info, xterm avait cette fonctionnalité activée par défaut.
Cela a été corrigé il y a deux ans:
Le problème des séquences d'échappement peut aussi se produire avec
les noms de fichiers (ce qui est problématique, e.g. quand on est
sous NFS, mais peut-être aussi quand on sauve des fichiers dont le
nom est proposé par le serveur/utilisateur distant). Les utilitaires
find (des findutils) et less étaient vulnérables:
Dans l'article <481b2839$0$4860$, Nicolas George <nicolas$ écrit:
Quand je dis « impression », je parle d'impression, pas d'affichage à l'écran. Il y a des séquences d'échappement pour demander au terminal d'imprimer son contenu.
Pour info, xterm avait cette fonctionnalité activée par défaut. Cela a été corrigé il y a deux ans:
Le problème des séquences d'échappement peut aussi se produire avec les noms de fichiers (ce qui est problématique, e.g. quand on est sous NFS, mais peut-être aussi quand on sauve des fichiers dont le nom est proposé par le serveur/utilisateur distant). Les utilitaires find (des findutils) et less étaient vulnérables:
