[Darwin] Configuration locale et caractères accentués
26 réponses
Gérald Niel
Bonjour,
Je suis tout nouveau dans le monde Mac, et j'éssais de retrouver mes
marques avec le terminal.
J'ai quelque petit soucis pour configurer les locales et afficher et
saisir les caractères huits bits.
J'ai aussi installé slrn et jed avec fink (apt-get install) et je ne les
ai pas en couleurs. De plus je souhaiterais passer à slrn-0.8.1, je ne
sais comment procéder...
Je suis preneur de toutes url utile pour apprivoiser cet environnement.
Je suis habitué à Linux et FreeBSD.
Le Mardi 21 décembre 2004 à 22:16 GMT, Matt écrivait sur fr.comp.os.mac-os.x :
Dans l'inspecteur de Terrminal.app, regarde si dans "Émulation", l'option "Éviter les caractères non ASCII" est cochée. Si elle l'est, décoche-la.
Un immense merci ! C'était ça qui foutait le bordel !
À cause de, je cite l'aide:
Configuration de terminal pour l'affichage des caractères high-bit
Choisissez Terminal > Réglages de la fenêtre. Choisissez Émulation dans le menu local Inspecteur de terminal. Sélectionnez "Éviter les caractères non ASCII". Choisissez Clavier dans le menu local Inspecteur de terminal. Désélectionnez "Utiliser touche d'option comme touche virtuelle" le cas échéant. Choisissez Affichage dans le menu local Inspecteur de terminal, puis Ünicode (UTF-8)" dans le menu local codage du jeu de caractères.
Je n'avais pas lu jusque là:
IMPORTANT Si vous utilisez un shell tcsh ou bash, veillez à sélectionner "Éviter les caractères non ASCII" dans la fenêtre Émulation de
À part la variable d'environnement $TERM, je ne vois pas ce qui cloche (essayer avec xterm-color).
Elle est fixé correctement. L'option Désactiver couleur ANSI est décoché. En utilisant screen, j'ai la couleur. Bizarre, car un ls -G est bien en couleur. Peut-être un problème avec s-lang ? Ou une mauvaise interpretation de l'aide ?...
Ne me reste plus qu'a faire un paquet avec les dernières versions de slrn et jed.
Merci encore !
Le Mardi 21 décembre 2004 à 22:16 GMT, Matt écrivait sur
fr.comp.os.mac-os.x :
Dans l'inspecteur de Terrminal.app, regarde si dans "Émulation", l'option
"Éviter les caractères non ASCII" est cochée. Si elle l'est, décoche-la.
Un immense merci !
C'était ça qui foutait le bordel !
À cause de, je cite l'aide:
Configuration de terminal pour l'affichage des caractères high-bit
Choisissez Terminal > Réglages de la fenêtre.
Choisissez Émulation dans le menu local Inspecteur de terminal.
Sélectionnez "Éviter les caractères non ASCII".
Choisissez Clavier dans le menu local Inspecteur de terminal.
Désélectionnez "Utiliser touche d'option comme touche virtuelle" le cas
échéant.
Choisissez Affichage dans le menu local Inspecteur de terminal, puis
Ünicode (UTF-8)" dans le menu local codage du jeu de caractères.
Je n'avais pas lu jusque là:
IMPORTANT Si vous utilisez un shell tcsh ou bash, veillez à
sélectionner "Éviter les caractères non ASCII" dans la fenêtre
Émulation de
À part la variable d'environnement $TERM, je ne vois pas ce qui cloche
(essayer avec xterm-color).
Elle est fixé correctement.
L'option Désactiver couleur ANSI est décoché.
En utilisant screen, j'ai la couleur. Bizarre, car un ls -G est bien
en couleur. Peut-être un problème avec s-lang ? Ou une mauvaise
interpretation de l'aide ?...
Ne me reste plus qu'a faire un paquet avec les dernières versions de
slrn et jed.
Le Mardi 21 décembre 2004 à 22:16 GMT, Matt écrivait sur fr.comp.os.mac-os.x :
Dans l'inspecteur de Terrminal.app, regarde si dans "Émulation", l'option "Éviter les caractères non ASCII" est cochée. Si elle l'est, décoche-la.
Un immense merci ! C'était ça qui foutait le bordel !
À cause de, je cite l'aide:
Configuration de terminal pour l'affichage des caractères high-bit
Choisissez Terminal > Réglages de la fenêtre. Choisissez Émulation dans le menu local Inspecteur de terminal. Sélectionnez "Éviter les caractères non ASCII". Choisissez Clavier dans le menu local Inspecteur de terminal. Désélectionnez "Utiliser touche d'option comme touche virtuelle" le cas échéant. Choisissez Affichage dans le menu local Inspecteur de terminal, puis Ünicode (UTF-8)" dans le menu local codage du jeu de caractères.
Je n'avais pas lu jusque là:
IMPORTANT Si vous utilisez un shell tcsh ou bash, veillez à sélectionner "Éviter les caractères non ASCII" dans la fenêtre Émulation de
À part la variable d'environnement $TERM, je ne vois pas ce qui cloche (essayer avec xterm-color).
Elle est fixé correctement. L'option Désactiver couleur ANSI est décoché. En utilisant screen, j'ai la couleur. Bizarre, car un ls -G est bien en couleur. Peut-être un problème avec s-lang ? Ou une mauvaise interpretation de l'aide ?...
Ne me reste plus qu'a faire un paquet avec les dernières versions de slrn et jed.
Merci encore !
Gérald Niel
Le Mardi 21 décembre 2004 à 22:16 GMT, Matt écrivait sur fr.comp.os.mac-os.x :
Je poursuis mes recherches pour la couleur...
À part la variable d'environnement $TERM, je ne vois pas ce qui cloche (essayer avec xterm-color).
Ce doit être un problème avec s-lang. Pour Jed, en fixant la variable USE_ANSI_COLORS à -1 dans le ~/.jedrc c'est bon. Je retrouve mes couleurs. Je n'ai jamais eu à le faire sous Linux et FreeBSD que ce soit dans une console ou sous X11. Bizarre... Quant-à slrn un alias slrn=screen slrn règle momentanément le problème.
Le Mardi 21 décembre 2004 à 22:16 GMT, Matt écrivait sur
fr.comp.os.mac-os.x :
Je poursuis mes recherches pour la couleur...
À part la variable d'environnement $TERM, je ne vois pas ce qui cloche
(essayer avec xterm-color).
Ce doit être un problème avec s-lang.
Pour Jed, en fixant la variable USE_ANSI_COLORS à -1 dans le ~/.jedrc
c'est bon. Je retrouve mes couleurs.
Je n'ai jamais eu à le faire sous Linux et FreeBSD que ce soit dans
une console ou sous X11. Bizarre...
Quant-à slrn un alias slrn=screen slrn règle momentanément le problème.
Le Mardi 21 décembre 2004 à 22:16 GMT, Matt écrivait sur fr.comp.os.mac-os.x :
Je poursuis mes recherches pour la couleur...
À part la variable d'environnement $TERM, je ne vois pas ce qui cloche (essayer avec xterm-color).
Ce doit être un problème avec s-lang. Pour Jed, en fixant la variable USE_ANSI_COLORS à -1 dans le ~/.jedrc c'est bon. Je retrouve mes couleurs. Je n'ai jamais eu à le faire sous Linux et FreeBSD que ce soit dans une console ou sous X11. Bizarre... Quant-à slrn un alias slrn=screen slrn règle momentanément le problème.
Gérald Niel
Le Mardi 21 décembre 2004 à 23:14 GMT, Matt écrivait sur fr.comp.os.mac-os.x :
Je n'utilise aucun des deux logiciels, tu devrais tester tin car je sais qu'il est compilé avec tout ce qui faut pour afficher des caractères 8 bits.
:-) Je l'ai déjà essayé sous Linux, pas accroché. Là, je n'ai plus de problème avec le 8 bit, c'est juste la couleur qui persite (si je n'utilise pas screen pour slrn).
@+ -- C'est vrai que je ne plais pas à tout le monde. Mais quand je vois à qui je ne plais pas, je me demande si ça me dérange vraiment. (Coluche)
Le Mardi 21 décembre 2004 à 23:14 GMT, Matt écrivait sur
fr.comp.os.mac-os.x :
Je n'utilise aucun des deux logiciels, tu devrais tester tin car je sais
qu'il est compilé avec tout ce qui faut pour afficher des caractères 8
bits.
:-)
Je l'ai déjà essayé sous Linux, pas accroché.
Là, je n'ai plus de problème avec le 8 bit, c'est juste la couleur qui
persite (si je n'utilise pas screen pour slrn).
@+
--
C'est vrai que je ne plais pas à tout le monde. Mais quand je vois à
qui je ne plais pas, je me demande si ça me dérange vraiment.
(Coluche)
Le Mardi 21 décembre 2004 à 23:14 GMT, Matt écrivait sur fr.comp.os.mac-os.x :
Je n'utilise aucun des deux logiciels, tu devrais tester tin car je sais qu'il est compilé avec tout ce qui faut pour afficher des caractères 8 bits.
:-) Je l'ai déjà essayé sous Linux, pas accroché. Là, je n'ai plus de problème avec le 8 bit, c'est juste la couleur qui persite (si je n'utilise pas screen pour slrn).
@+ -- C'est vrai que je ne plais pas à tout le monde. Mais quand je vois à qui je ne plais pas, je me demande si ça me dérange vraiment. (Coluche)
Gérald Niel
Le Mercredi 22 décembre 2004 à 00:09 GMT, Matt écrivait sur fr.comp.os.mac-os.x :
Probablement SLang. Je vais tester jed chez darwinports.
J'ai la version fink. Il va falloir que je m'habitue à tout ça... Il y a donc deux projets parallèle, c'est ça ?
Il faut faire quelque chose de spécial pour activer la coloration dans jed (je demande ça car dans vim il faut l'activer) ?
Théoriquement non (comme je l'ai dit dans ce fil je n'avais jamais rien eu de particulier à faire sous Linux et FreeBSD), mais là si. Il faut fixer (dans le ~/.jedrc par exemple) la variable:
USE_ANSI_COLORS= -1;
Et je n'ai pas trouvé pour slrn. J'utilise donc screen.
Ne me reste plus qu'a faire un paquet avec les dernières versions de slrn et jed.
Je peux te faire ça mais tout s'installera dans /opt/local
Merci pour la proposition, je vais me documenter sur les procédures de fabrication pour fink et darwinports. Ça ne devrait pas trop me poser de problème ayant l'habitude de compiler mes logiciels. Si j'ai un soucis, je suppose que ce n'est pas sur ce groupe qu'il me faudra venir quérir de l'aide ?
@+ -- C'est vrai que je ne plais pas à tout le monde. Mais quand je vois à qui je ne plais pas, je me demande si ça me dérange vraiment. (Coluche)
Le Mercredi 22 décembre 2004 à 00:09 GMT, Matt écrivait sur
fr.comp.os.mac-os.x :
Probablement SLang.
Je vais tester jed chez darwinports.
J'ai la version fink.
Il va falloir que je m'habitue à tout ça... Il y a donc deux projets
parallèle, c'est ça ?
Il faut faire quelque chose de spécial pour activer la coloration dans jed
(je demande ça car dans vim il faut l'activer) ?
Théoriquement non (comme je l'ai dit dans ce fil je n'avais jamais
rien eu de particulier à faire sous Linux et FreeBSD), mais là si.
Il faut fixer (dans le ~/.jedrc par exemple) la variable:
USE_ANSI_COLORS= -1;
Et je n'ai pas trouvé pour slrn. J'utilise donc screen.
Ne me reste plus qu'a faire un paquet avec les dernières versions de
slrn et jed.
Je peux te faire ça mais tout s'installera dans /opt/local
Merci pour la proposition, je vais me documenter sur les procédures de
fabrication pour fink et darwinports. Ça ne devrait pas trop me poser
de problème ayant l'habitude de compiler mes logiciels.
Si j'ai un soucis, je suppose que ce n'est pas sur ce groupe qu'il me
faudra venir quérir de l'aide ?
@+
--
C'est vrai que je ne plais pas à tout le monde. Mais quand je vois à
qui je ne plais pas, je me demande si ça me dérange vraiment.
(Coluche)
Le Mercredi 22 décembre 2004 à 00:09 GMT, Matt écrivait sur fr.comp.os.mac-os.x :
Probablement SLang. Je vais tester jed chez darwinports.
J'ai la version fink. Il va falloir que je m'habitue à tout ça... Il y a donc deux projets parallèle, c'est ça ?
Il faut faire quelque chose de spécial pour activer la coloration dans jed (je demande ça car dans vim il faut l'activer) ?
Théoriquement non (comme je l'ai dit dans ce fil je n'avais jamais rien eu de particulier à faire sous Linux et FreeBSD), mais là si. Il faut fixer (dans le ~/.jedrc par exemple) la variable:
USE_ANSI_COLORS= -1;
Et je n'ai pas trouvé pour slrn. J'utilise donc screen.
Ne me reste plus qu'a faire un paquet avec les dernières versions de slrn et jed.
Je peux te faire ça mais tout s'installera dans /opt/local
Merci pour la proposition, je vais me documenter sur les procédures de fabrication pour fink et darwinports. Ça ne devrait pas trop me poser de problème ayant l'habitude de compiler mes logiciels. Si j'ai un soucis, je suppose que ce n'est pas sur ce groupe qu'il me faudra venir quérir de l'aide ?
@+ -- C'est vrai que je ne plais pas à tout le monde. Mais quand je vois à qui je ne plais pas, je me demande si ça me dérange vraiment. (Coluche)
------
Gérald Niel wrote:
Bonjour,
Question HS:
Comment faire pour avoir une adresse "alussina".? Sa réputation efficacité comme antispam est-ell avérée.?
Gérald Niel <gniel@alussinan.org> wrote:
Bonjour,
Question HS:
Comment faire pour avoir une adresse "alussina".?
Sa réputation efficacité comme antispam est-ell avérée.?
C'était juste pour tester les caractères 8 bits ;)
je suis complétement hermétique à toutes ces histoires d'encodage et d'affichage à la mords-moi-le-noeud, mais j'ai quand même une question à ce sujet :
j'utilise subversion au boulot pour versionner tout un tas de documents (config serveur, notes de travail...). Et mon collègue à créé tous ces doc avec des noms genre "Procédures d'installation" (accents inside). Subversion râle, et réclame qu'on force cette variable d'environnement :
LC_CTYPE=fr_FR.ISO8859-1
Je l'ai fait dans mon .bash_profile et dans mon .MacOSX/environment.plist mais je ne sais pas si cela va avoir un impact sur le fonctionnement d'autres softs.
D'ailleurs j'ai des soucis dans le terminal (bash, terminal.app) :
$ touch tést $ ls tést <-- via la complétion tab te??st $ ls tést <-- en tapant vraiement "tést" tést
de plus, vi ne gère pas tous les caractères accentués correctement, si le tape un "à", c'est "?| " qui s'affiche alors que le cat affiche le bon caractère :
$ cat tést à
un moyen de dire à vi de faire les choses bien ? A noter que d'après bbedit, le fichier tést est en unicode, en dépit du LC_CTYPE, ça me laisse pour le moins perplexe.
dites, rassurez moi, y a des gens qui comprennent tout et qui bossent sur une harmonisation intelligente ? :)
patpro
In article <32rs3nF3nu8m1U1@individual.net>, Matt <sbehzf@syrius.org>
wrote:
C'était juste pour tester les caractères 8 bits ;)
je suis complétement hermétique à toutes ces histoires d'encodage et
d'affichage à la mords-moi-le-noeud, mais j'ai quand même une question à
ce sujet :
j'utilise subversion au boulot pour versionner tout un tas de documents
(config serveur, notes de travail...). Et mon collègue à créé tous ces
doc avec des noms genre "Procédures d'installation" (accents inside).
Subversion râle, et réclame qu'on force cette variable d'environnement :
LC_CTYPE=fr_FR.ISO8859-1
Je l'ai fait dans mon .bash_profile et dans mon
.MacOSX/environment.plist mais je ne sais pas si cela va avoir un impact
sur le fonctionnement d'autres softs.
D'ailleurs j'ai des soucis dans le terminal (bash, terminal.app) :
$ touch tést
$ ls tést <-- via la complétion tab
te??st
$ ls tést <-- en tapant vraiement "tést"
tést
de plus, vi ne gère pas tous les caractères accentués correctement, si
le tape un "à", c'est "?| " qui s'affiche alors que le cat affiche le
bon caractère :
$ cat tést
à
un moyen de dire à vi de faire les choses bien ?
A noter que d'après bbedit, le fichier tést est en unicode, en dépit du
LC_CTYPE, ça me laisse pour le moins perplexe.
dites, rassurez moi, y a des gens qui comprennent tout et qui bossent
sur une harmonisation intelligente ? :)
C'était juste pour tester les caractères 8 bits ;)
je suis complétement hermétique à toutes ces histoires d'encodage et d'affichage à la mords-moi-le-noeud, mais j'ai quand même une question à ce sujet :
j'utilise subversion au boulot pour versionner tout un tas de documents (config serveur, notes de travail...). Et mon collègue à créé tous ces doc avec des noms genre "Procédures d'installation" (accents inside). Subversion râle, et réclame qu'on force cette variable d'environnement :
LC_CTYPE=fr_FR.ISO8859-1
Je l'ai fait dans mon .bash_profile et dans mon .MacOSX/environment.plist mais je ne sais pas si cela va avoir un impact sur le fonctionnement d'autres softs.
D'ailleurs j'ai des soucis dans le terminal (bash, terminal.app) :
$ touch tést $ ls tést <-- via la complétion tab te??st $ ls tést <-- en tapant vraiement "tést" tést
de plus, vi ne gère pas tous les caractères accentués correctement, si le tape un "à", c'est "?| " qui s'affiche alors que le cat affiche le bon caractère :
$ cat tést à
un moyen de dire à vi de faire les choses bien ? A noter que d'après bbedit, le fichier tést est en unicode, en dépit du LC_CTYPE, ça me laisse pour le moins perplexe.
dites, rassurez moi, y a des gens qui comprennent tout et qui bossent sur une harmonisation intelligente ? :)
patpro
patpro ~ patrick proniewski
In article , Matt wrote:
Je l'ai fait dans mon .bash_profile et dans mon .MacOSX/environment.plist mais je ne sais pas si cela va avoir un impact sur le fonctionnement d'autres softs.
Oui, ils utiliseront cette variable.
oui mais est ce que ça ne pas pas les perturber ou faire fonctionner des trucs Apple de travers ? :)
$ ls tést <-- via la complétion tab te??st
Dans un terminal utf-8 ?
vi, je vais peut etre le passer en latin-1 pour etre cohérent avec mon LC_CTYPE, qu'en penses tu ?
un moyen de dire à vi de faire les choses bien ?
Dans vi je ne crois pas, mais dans vim, si le support multi-bit (+multi_byte) a été utilisé lors de la compilation, oui tu peux utiliser l'option "encoding" pour changer l'encodage pour le contenu du fichier.
ok, je vais aliaser vim en vi alors
A noter que d'après bbedit, le fichier tést est en unicode, en dépit du LC_CTYPE, ça me laisse pour le moins perplexe.
Sûrement parce que BBEdit se contrefout du fichier (pas la variable LC_CTYPE) ~/.MacOSX/environment.plist, ce qui est pas super super.
je pense pas, ce que je veux dire c'est que j'ouvre le fichier dans bbedit en choisissant l'encodage, et que les caractères ne sont corrects que si j'ouvre avec UTF8, alors que je m'attendais à du Latin-1. Vu que mon terminal.app est effectivement en UTF8 ça doit venir de là (mais quel SOUUUUUUUUUUUUK !)
patpro
In article <32t2vhF3m81h1U1@individual.net>, Matt <sbehzf@syrius.org>
wrote:
Je l'ai fait dans mon .bash_profile et dans mon
.MacOSX/environment.plist mais je ne sais pas si cela va avoir un impact
sur le fonctionnement d'autres softs.
Oui, ils utiliseront cette variable.
oui mais est ce que ça ne pas pas les perturber ou faire fonctionner des
trucs Apple de travers ? :)
$ ls tést <-- via la complétion tab
te??st
Dans un terminal utf-8 ?
vi, je vais peut etre le passer en latin-1 pour etre cohérent avec mon
LC_CTYPE, qu'en penses tu ?
un moyen de dire à vi de faire les choses bien ?
Dans vi je ne crois pas, mais dans vim, si le support multi-bit
(+multi_byte) a été utilisé lors de la compilation, oui tu peux utiliser
l'option "encoding" pour changer l'encodage pour le contenu du fichier.
ok, je vais aliaser vim en vi alors
A noter que d'après bbedit, le fichier tést est en unicode, en dépit du
LC_CTYPE, ça me laisse pour le moins perplexe.
Sûrement parce que BBEdit se contrefout du fichier (pas la variable
LC_CTYPE) ~/.MacOSX/environment.plist, ce qui est pas super super.
je pense pas, ce que je veux dire c'est que j'ouvre le fichier dans
bbedit en choisissant l'encodage, et que les caractères ne sont corrects
que si j'ouvre avec UTF8, alors que je m'attendais à du Latin-1. Vu que
mon terminal.app est effectivement en UTF8 ça doit venir de là (mais
quel SOUUUUUUUUUUUUK !)
Je l'ai fait dans mon .bash_profile et dans mon .MacOSX/environment.plist mais je ne sais pas si cela va avoir un impact sur le fonctionnement d'autres softs.
Oui, ils utiliseront cette variable.
oui mais est ce que ça ne pas pas les perturber ou faire fonctionner des trucs Apple de travers ? :)
$ ls tést <-- via la complétion tab te??st
Dans un terminal utf-8 ?
vi, je vais peut etre le passer en latin-1 pour etre cohérent avec mon LC_CTYPE, qu'en penses tu ?
un moyen de dire à vi de faire les choses bien ?
Dans vi je ne crois pas, mais dans vim, si le support multi-bit (+multi_byte) a été utilisé lors de la compilation, oui tu peux utiliser l'option "encoding" pour changer l'encodage pour le contenu du fichier.
ok, je vais aliaser vim en vi alors
A noter que d'après bbedit, le fichier tést est en unicode, en dépit du LC_CTYPE, ça me laisse pour le moins perplexe.
Sûrement parce que BBEdit se contrefout du fichier (pas la variable LC_CTYPE) ~/.MacOSX/environment.plist, ce qui est pas super super.
je pense pas, ce que je veux dire c'est que j'ouvre le fichier dans bbedit en choisissant l'encodage, et que les caractères ne sont corrects que si j'ouvre avec UTF8, alors que je m'attendais à du Latin-1. Vu que mon terminal.app est effectivement en UTF8 ça doit venir de là (mais quel SOUUUUUUUUUUUUK !)
patpro
patpro ~ patrick proniewski
In article , Matt wrote:
ok, je vais aliaser vim en vi alors
Sur Mac OS X, c'est déjà "fait" :
$ ls -l /usr/bin/vi lrwxr-xr-x 1 root wheel 3B 17 mai 2004 /usr/bin/vi@ -> vim
vérole :)
Oui. La réglage de l'encodage dans l'inspecteur de Terminal.app agit sur les caractères tapés et sur l'affichage; ce qui évite de jouer avec locale.
ok, merci !
patpro
In article <32t4k4F3m81h1U5@individual.net>, Matt <sbehzf@syrius.org>
wrote:
ok, je vais aliaser vim en vi alors
Sur Mac OS X, c'est déjà "fait" :
$ ls -l /usr/bin/vi
lrwxr-xr-x 1 root wheel 3B 17 mai 2004 /usr/bin/vi@ -> vim
vérole :)
Oui. La réglage de l'encodage dans l'inspecteur de Terminal.app agit sur
les caractères tapés et sur l'affichage; ce qui évite de jouer avec
locale.
$ ls -l /usr/bin/vi lrwxr-xr-x 1 root wheel 3B 17 mai 2004 /usr/bin/vi@ -> vim
vérole :)
Oui. La réglage de l'encodage dans l'inspecteur de Terminal.app agit sur les caractères tapés et sur l'affichage; ce qui évite de jouer avec locale.
ok, merci !
patpro
Gérald Niel
Le Mercredi 22 décembre 2004 à 11:12 GMT, Matt écrivait sur fr.comp.os.mac-os.x :
Est-ce qu'il nécessite une option à la compilation pour activer les couleurs ?
Je ne pense pas. Mon instinct et mes diverses rechèrches me font penser à un problème conjugué entre s-lang et le termcap.
Si oui, regarder dans le .info chez Fink pour voir les options de compilation utilisées.
C'est justement ça que je cherche, pour mettre à jour mon slrn...
Si j'ai un soucis, je suppose que ce n'est pas sur ce groupe qu'il me faudra venir quérir de l'aide ?
Non, tant que tu utilises ces gestionnaires sur Mac OS X ou (Open)Darwin, ce forum est le bon endroit.
Ok.
Sinon, tu peux toujours utiliser les listes de discussions pour chacun de ces projets.
Je préfère Usenet pour l'instant. J'apprivoise Mail, voir si il pourrait remplacer mon Mutt qui necessite fetchmail et un smtp (ou un MTA basique) local pour envoyer.
@+ -- C'est vrai que je ne plais pas à tout le monde. Mais quand je vois à qui je ne plais pas, je me demande si ça me dérange vraiment. (Coluche)
Le Mercredi 22 décembre 2004 à 11:12 GMT, Matt écrivait sur
fr.comp.os.mac-os.x :
Est-ce qu'il nécessite une option à la compilation pour activer les
couleurs ?
Je ne pense pas.
Mon instinct et mes diverses rechèrches me font penser à un problème
conjugué entre s-lang et le termcap.
Si oui, regarder dans le .info chez Fink pour voir les options de
compilation utilisées.
C'est justement ça que je cherche, pour mettre à jour mon slrn...
Si j'ai un soucis, je suppose que ce n'est pas sur ce groupe qu'il me
faudra venir quérir de l'aide ?
Non, tant que tu utilises ces gestionnaires sur Mac OS X ou (Open)Darwin,
ce forum est le bon endroit.
Ok.
Sinon, tu peux toujours utiliser les listes de discussions pour chacun de
ces projets.
Je préfère Usenet pour l'instant.
J'apprivoise Mail, voir si il pourrait remplacer mon Mutt qui
necessite fetchmail et un smtp (ou un MTA basique) local pour envoyer.
@+
--
C'est vrai que je ne plais pas à tout le monde. Mais quand je vois à
qui je ne plais pas, je me demande si ça me dérange vraiment.
(Coluche)
Le Mercredi 22 décembre 2004 à 11:12 GMT, Matt écrivait sur fr.comp.os.mac-os.x :
Est-ce qu'il nécessite une option à la compilation pour activer les couleurs ?
Je ne pense pas. Mon instinct et mes diverses rechèrches me font penser à un problème conjugué entre s-lang et le termcap.
Si oui, regarder dans le .info chez Fink pour voir les options de compilation utilisées.
C'est justement ça que je cherche, pour mettre à jour mon slrn...
Si j'ai un soucis, je suppose que ce n'est pas sur ce groupe qu'il me faudra venir quérir de l'aide ?
Non, tant que tu utilises ces gestionnaires sur Mac OS X ou (Open)Darwin, ce forum est le bon endroit.
Ok.
Sinon, tu peux toujours utiliser les listes de discussions pour chacun de ces projets.
Je préfère Usenet pour l'instant. J'apprivoise Mail, voir si il pourrait remplacer mon Mutt qui necessite fetchmail et un smtp (ou un MTA basique) local pour envoyer.
@+ -- C'est vrai que je ne plais pas à tout le monde. Mais quand je vois à qui je ne plais pas, je me demande si ça me dérange vraiment. (Coluche)
