je voudrais avoir "écran infos imprimante/"
comment je peux faire ?
(je precise que ca ne marche pas de taper "\314\201cr"+tab )
--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
C'est canal par canal que se font les conventions. Je pense qu'il va falloir que je me mette à perl :-(
Je sais pas si c'est relevant a la question, mais avec GNU screen on peut changer l'encoding de la fenetre en cours a la volee et avoir des fenetres d'encoding different.
-- Stephane
2004-10-14, 15:16(+02), Erwan David:
[....]
C'est canal par canal que se font les conventions. Je pense qu'il va
falloir que je me mette à perl :-(
Je sais pas si c'est relevant a la question, mais avec GNU
screen on peut changer l'encoding de la fenetre en cours a la
volee et avoir des fenetres d'encoding different.
C'est canal par canal que se font les conventions. Je pense qu'il va falloir que je me mette à perl :-(
Je sais pas si c'est relevant a la question, mais avec GNU screen on peut changer l'encoding de la fenetre en cours a la volee et avoir des fenetres d'encoding different.
-- Stephane
Nicolas George
Erwan David wrote in message :
C'ets pas une question de gérer ou pas c'est une question que je vais sur des channels où on n'envoie *pas* d'UTF-8. ALors je peux avoir de l'UTF-8 de mon côté ça marchera, mais j'emmerderai le monde.
Erwan David wrote in message <85oej5h5ub.fsf@bretagne.rail.eu.org>:
C'ets pas une question de gérer ou pas c'est une question que je vais
sur des channels où on n'envoie *pas* d'UTF-8. ALors je peux avoir de
l'UTF-8 de mon côté ça marchera, mais j'emmerderai le monde.
C'ets pas une question de gérer ou pas c'est une question que je vais sur des channels où on n'envoie *pas* d'UTF-8. ALors je peux avoir de l'UTF-8 de mon côté ça marchera, mais j'emmerderai le monde.
(LC_CTYPE, en fait, LANG lui fournit une valeur par défaut, mais personnellement j'évite, parce que ça contamine LC_NUMERIC et LC_COLLATE qui peuvent mettre gravement la zone)
Pas très fréquent, la dernière fois que j'ai eu un problème avec ça, c'était il y a 10 ans avec Emacs, j'avais envoyé des patchs et c'était corrigé.
Il y a un hack possible pour automatiquement détecter l'encodage du terminal. Le principe est d'envoyer au terminal un caractère qui lui fera bouger le curseur de deux cases en encodage mono-octets, et d'une seule en UTF-8, puis de réclamer avec la séquence d'échappement idoine qu'il signale la position du curseur. C'est asez laid sur le concept, mais ça ne marche pas mal du tout.
L'autre solution consiste à déviner d'où vient le ssh, maintenir de tables des machines et des terminaux les plus souvent utilisés avec les encodages de chacun, ça ne marche pas terrible et ça ne marche de toute façon plus dès qu'on empile les ssh.
Même si c'est sale, c'est plutôt une bonne idée. Avec zsh 4.2 (mais pas 4.0) et un terminal type VT100, ça donne quelque chose comme ça (ça marche avec xterm et screen mais pas le terminal de FreeBSD), il faudrait l'adapter pour entrer dans le .zshrc en le faisant dépendre de $TERM :
case "$column" in 2) printf "multi bytes charactersn" ;; 3) printf "single byte charactersn" ;; *) printf "unknown encoding or unsuported terminaln"; exit 1; esac
Nicolas George <nicolas$george@salle-s.org> écrit:
(LC_CTYPE, en fait, LANG lui fournit une valeur par défaut, mais
personnellement j'évite, parce que ça contamine LC_NUMERIC et LC_COLLATE qui
peuvent mettre gravement la zone)
Pas très fréquent, la dernière fois que j'ai eu un problème avec ça,
c'était il y a 10 ans avec Emacs, j'avais envoyé des patchs et c'était
corrigé.
Il y a un hack possible pour automatiquement détecter l'encodage du
terminal. Le principe est d'envoyer au terminal un caractère qui lui fera
bouger le curseur de deux cases en encodage mono-octets, et d'une seule en
UTF-8, puis de réclamer avec la séquence d'échappement idoine qu'il signale
la position du curseur. C'est asez laid sur le concept, mais ça ne marche
pas mal du tout.
L'autre solution consiste à déviner d'où vient le ssh, maintenir de
tables des machines et des terminaux les plus souvent utilisés avec
les encodages de chacun, ça ne marche pas terrible et ça ne marche
de toute façon plus dès qu'on empile les ssh.
Même si c'est sale, c'est plutôt une bonne idée. Avec zsh 4.2 (mais
pas 4.0) et un terminal type VT100, ça donne quelque chose comme ça
(ça marche avec xterm et screen mais pas le terminal de FreeBSD), il
faudrait l'adapter pour entrer dans le .zshrc en le faisant dépendre
de $TERM :
(LC_CTYPE, en fait, LANG lui fournit une valeur par défaut, mais personnellement j'évite, parce que ça contamine LC_NUMERIC et LC_COLLATE qui peuvent mettre gravement la zone)
Pas très fréquent, la dernière fois que j'ai eu un problème avec ça, c'était il y a 10 ans avec Emacs, j'avais envoyé des patchs et c'était corrigé.
Il y a un hack possible pour automatiquement détecter l'encodage du terminal. Le principe est d'envoyer au terminal un caractère qui lui fera bouger le curseur de deux cases en encodage mono-octets, et d'une seule en UTF-8, puis de réclamer avec la séquence d'échappement idoine qu'il signale la position du curseur. C'est asez laid sur le concept, mais ça ne marche pas mal du tout.
L'autre solution consiste à déviner d'où vient le ssh, maintenir de tables des machines et des terminaux les plus souvent utilisés avec les encodages de chacun, ça ne marche pas terrible et ça ne marche de toute façon plus dès qu'on empile les ssh.
Même si c'est sale, c'est plutôt une bonne idée. Avec zsh 4.2 (mais pas 4.0) et un terminal type VT100, ça donne quelque chose comme ça (ça marche avec xterm et screen mais pas le terminal de FreeBSD), il faudrait l'adapter pour entrer dans le .zshrc en le faisant dépendre de $TERM :
case "$column" in 2) printf "multi bytes charactersn" ;; 3) printf "single byte charactersn" ;; *) printf "unknown encoding or unsuported terminaln"; exit 1; esac
Nicolas George
Laurent Wacrenier wrote in message :
Pas très fréquent, la dernière fois que j'ai eu un problème avec ça, c'était il y a 10 ans avec Emacs, j'avais envoyé des patchs et c'était corrigé.
Il y a eu, beaucoup plus récemment, un problème avec OCaml : le lexer reconnaissait les nombres flottants avec un point, naturellement, mais utilisait ensuite la libc pour les convertir, et ça cassait dans le toplevel lablgtk, parce que Gtk+ fait un setlocale à l'initialisation.
D'une manière générale, il y a plein de programmes mal fichus dont les auteurs ont copié-collé un setlocale qu'ils ne comprennent pas et risquent de casser de manière plus ou moins imprévisible parce qu'ils auraient dû surtout ne pas le faire. Évidemment, pour les gros bons projets, c'est plus rare.
Si on ajoute à ça que les traductions françaises des logiciels donnent souvent l'impression que leur auteur ne connaît ni le français, ni l'anglais, ni le programme qu'il traduit¹, je préfère régler LC_CTYPE et laisser tout le reste en C.
L'autre solution consiste à déviner d'où vient le ssh, maintenir de tables des machines et des terminaux les plus souvent utilisés avec les encodages de chacun, ça ne marche pas terrible et ça ne marche de toute façon plus dès qu'on empile les ssh.
Oui, bien sûr, à titre personnel c'est le mieux. Mais quand il faut faire une config pour deux-cent personnes dont les trois-quarts ne comprennent rien à l'informatique, ce n'est pas envisageable. Et même comme ça, ils vont probablement se demander pourquoi les accents sont bizarres dans pine quand ils se loguent depuis le Terminal.app de leur mac.
Même si c'est sale, c'est plutôt une bonne idée. Avec zsh 4.2 (mais pas 4.0) et un terminal type VT100, ça donne quelque chose comme ça (ça marche avec xterm et screen mais pas le terminal de FreeBSD), il faudrait l'adapter pour entrer dans le .zshrc en le faisant dépendre de $TERM :
J'ai fait un peu le même genre, mais en utilisant $terminfo pour adapter un peu mieux les séquences au terminal. Et surtout, j'utilise un bindkey plutôt qu'un read, ce qui fait que ça doit marcher même si l'utilisateur a commencé à taper en aveugle avant que la détection soit lancée. D'ailleurs j'ai réussi à faire segfaulter zsh comme ça, avec un bindkey qui se dé-bindkey lui-même...
1 : vous n'avez jamais tapé « df » avec LC_MESSAGES en français sur une Debian Woody ? Allez, je vous le donne en exclusivité :
Système de fichiers 1k-blocs Utilisé la capacité disponible% Monté sur /dev/hda1 3557744 964856 2412160 29% /
Joli n'est-ce pas ? « la capacité disponible% », ça a un petit air de « la pelouse forbidden » qu'on voit parfois dans _Pépé le putois_.
Laurent Wacrenier wrote in message
<slrncmt3l6.5q7.lwa@victor.teaser.fr>:
Pas très fréquent, la dernière fois que j'ai eu un problème avec ça,
c'était il y a 10 ans avec Emacs, j'avais envoyé des patchs et c'était
corrigé.
Il y a eu, beaucoup plus récemment, un problème avec OCaml : le lexer
reconnaissait les nombres flottants avec un point, naturellement, mais
utilisait ensuite la libc pour les convertir, et ça cassait dans le toplevel
lablgtk, parce que Gtk+ fait un setlocale à l'initialisation.
D'une manière générale, il y a plein de programmes mal fichus dont les
auteurs ont copié-collé un setlocale qu'ils ne comprennent pas et risquent
de casser de manière plus ou moins imprévisible parce qu'ils auraient dû
surtout ne pas le faire. Évidemment, pour les gros bons projets, c'est plus
rare.
Si on ajoute à ça que les traductions françaises des logiciels donnent
souvent l'impression que leur auteur ne connaît ni le français, ni
l'anglais, ni le programme qu'il traduit¹, je préfère régler LC_CTYPE et
laisser tout le reste en C.
L'autre solution consiste à déviner d'où vient le ssh, maintenir de
tables des machines et des terminaux les plus souvent utilisés avec
les encodages de chacun, ça ne marche pas terrible et ça ne marche
de toute façon plus dès qu'on empile les ssh.
Oui, bien sûr, à titre personnel c'est le mieux. Mais quand il faut faire
une config pour deux-cent personnes dont les trois-quarts ne comprennent
rien à l'informatique, ce n'est pas envisageable. Et même comme ça, ils vont
probablement se demander pourquoi les accents sont bizarres dans pine quand
ils se loguent depuis le Terminal.app de leur mac.
Même si c'est sale, c'est plutôt une bonne idée. Avec zsh 4.2 (mais
pas 4.0) et un terminal type VT100, ça donne quelque chose comme ça
(ça marche avec xterm et screen mais pas le terminal de FreeBSD), il
faudrait l'adapter pour entrer dans le .zshrc en le faisant dépendre
de $TERM :
J'ai fait un peu le même genre, mais en utilisant $terminfo pour adapter un
peu mieux les séquences au terminal. Et surtout, j'utilise un bindkey plutôt
qu'un read, ce qui fait que ça doit marcher même si l'utilisateur a commencé
à taper en aveugle avant que la détection soit lancée. D'ailleurs j'ai
réussi à faire segfaulter zsh comme ça, avec un bindkey qui se dé-bindkey
lui-même...
1 : vous n'avez jamais tapé « df » avec LC_MESSAGES en français sur une
Debian Woody ? Allez, je vous le donne en exclusivité :
Système de fichiers 1k-blocs Utilisé la capacité disponible% Monté sur
/dev/hda1 3557744 964856 2412160 29% /
Joli n'est-ce pas ? « la capacité disponible% », ça a un petit air de « la
pelouse forbidden » qu'on voit parfois dans _Pépé le putois_.
Pas très fréquent, la dernière fois que j'ai eu un problème avec ça, c'était il y a 10 ans avec Emacs, j'avais envoyé des patchs et c'était corrigé.
Il y a eu, beaucoup plus récemment, un problème avec OCaml : le lexer reconnaissait les nombres flottants avec un point, naturellement, mais utilisait ensuite la libc pour les convertir, et ça cassait dans le toplevel lablgtk, parce que Gtk+ fait un setlocale à l'initialisation.
D'une manière générale, il y a plein de programmes mal fichus dont les auteurs ont copié-collé un setlocale qu'ils ne comprennent pas et risquent de casser de manière plus ou moins imprévisible parce qu'ils auraient dû surtout ne pas le faire. Évidemment, pour les gros bons projets, c'est plus rare.
Si on ajoute à ça que les traductions françaises des logiciels donnent souvent l'impression que leur auteur ne connaît ni le français, ni l'anglais, ni le programme qu'il traduit¹, je préfère régler LC_CTYPE et laisser tout le reste en C.
L'autre solution consiste à déviner d'où vient le ssh, maintenir de tables des machines et des terminaux les plus souvent utilisés avec les encodages de chacun, ça ne marche pas terrible et ça ne marche de toute façon plus dès qu'on empile les ssh.
Oui, bien sûr, à titre personnel c'est le mieux. Mais quand il faut faire une config pour deux-cent personnes dont les trois-quarts ne comprennent rien à l'informatique, ce n'est pas envisageable. Et même comme ça, ils vont probablement se demander pourquoi les accents sont bizarres dans pine quand ils se loguent depuis le Terminal.app de leur mac.
Même si c'est sale, c'est plutôt une bonne idée. Avec zsh 4.2 (mais pas 4.0) et un terminal type VT100, ça donne quelque chose comme ça (ça marche avec xterm et screen mais pas le terminal de FreeBSD), il faudrait l'adapter pour entrer dans le .zshrc en le faisant dépendre de $TERM :
J'ai fait un peu le même genre, mais en utilisant $terminfo pour adapter un peu mieux les séquences au terminal. Et surtout, j'utilise un bindkey plutôt qu'un read, ce qui fait que ça doit marcher même si l'utilisateur a commencé à taper en aveugle avant que la détection soit lancée. D'ailleurs j'ai réussi à faire segfaulter zsh comme ça, avec un bindkey qui se dé-bindkey lui-même...
1 : vous n'avez jamais tapé « df » avec LC_MESSAGES en français sur une Debian Woody ? Allez, je vous le donne en exclusivité :
Système de fichiers 1k-blocs Utilisé la capacité disponible% Monté sur /dev/hda1 3557744 964856 2412160 29% /
Joli n'est-ce pas ? « la capacité disponible% », ça a un petit air de « la pelouse forbidden » qu'on voit parfois dans _Pépé le putois_.
Laurent Wacrenier
Laurent Wacrenier écrit:
On est d'accord, cela dit, il semble que ça doive changer en 10.4, en tous cas pas mal d'outils vont s'adapter aux spécificités de l'OS.
En attendant, le "ls" de GNU (fileutils) affiche les caractères UTF-8 proprement. Mais il n'a pas d'option spécifiques comme "-o".
En regardant de plus près, le "ls" de macos interprète mal les locales (les noms des fichiers sont analysés octet par octet). Ça doit pouvoir se patcher mais quid des noms de fichier non utf-8 ? Sinon, l'option "-v" désactive toute substitution (attention aux fichiers "Iconr" par ci par là)
Laurent Wacrenier <lwa@teaser> écrit:
On est d'accord, cela dit, il semble que ça doive changer en 10.4, en
tous cas pas mal d'outils vont s'adapter aux spécificités de l'OS.
En attendant, le "ls" de GNU (fileutils) affiche les caractères UTF-8
proprement. Mais il n'a pas d'option spécifiques comme "-o".
En regardant de plus près, le "ls" de macos interprète mal les locales
(les noms des fichiers sont analysés octet par octet). Ça doit pouvoir
se patcher mais quid des noms de fichier non utf-8 ? Sinon, l'option
"-v" désactive toute substitution (attention aux fichiers "Iconr" par
ci par là)
On est d'accord, cela dit, il semble que ça doive changer en 10.4, en tous cas pas mal d'outils vont s'adapter aux spécificités de l'OS.
En attendant, le "ls" de GNU (fileutils) affiche les caractères UTF-8 proprement. Mais il n'a pas d'option spécifiques comme "-o".
En regardant de plus près, le "ls" de macos interprète mal les locales (les noms des fichiers sont analysés octet par octet). Ça doit pouvoir se patcher mais quid des noms de fichier non utf-8 ? Sinon, l'option "-v" désactive toute substitution (attention aux fichiers "Iconr" par ci par là)
drkm
Nicolas George <nicolas$ writes:
Laurent Wacrenier wrote in message :
Pas très fréquent, la dernière fois que j'ai eu un problème avec ça, c'était il y a 10 ans avec Emacs, j'avais envoyé des patchs et c'était corrigé.
Il y a eu, beaucoup plus récemment, un problème avec OCaml : le lexer reconnaissait les nombres flottants avec un point, naturellement, mais utilisait ensuite la libc pour les convertir, et ça cassait dans le toplevel lablgtk, parce que Gtk+ fait un setlocale à l'initialisation.
J'ai trouvé un bug tout à fait similaire dans GNU Emacs il y a moins d'un an (2004-02, de mémoire). Mais le setlocale() fautif se trouvait dans les sources propres d'Emacs. Glups !
D'une manière générale, il y a plein de programmes mal fichus dont les auteurs ont copié-collé un setlocale qu'ils ne comprennentpas
Et je ne trouve pas pour autant Emacs « mal fichu » (bien que sur ce coup-là, quand même) ;-)
--drkm
Nicolas George <nicolas$george@salle-s.org> writes:
Laurent Wacrenier wrote in message
<slrncmt3l6.5q7.lwa@victor.teaser.fr>:
Pas très fréquent, la dernière fois que j'ai eu un problème avec ça,
c'était il y a 10 ans avec Emacs, j'avais envoyé des patchs et c'était
corrigé.
Il y a eu, beaucoup plus récemment, un problème avec OCaml : le lexer
reconnaissait les nombres flottants avec un point, naturellement, mais
utilisait ensuite la libc pour les convertir, et ça cassait dans le toplevel
lablgtk, parce que Gtk+ fait un setlocale à l'initialisation.
J'ai trouvé un bug tout à fait similaire dans GNU Emacs il y a moins
d'un an (2004-02, de mémoire). Mais le setlocale() fautif se trouvait
dans les sources propres d'Emacs. Glups !
D'une manière générale, il y a plein de programmes mal fichus dont les
auteurs ont copié-collé un setlocale qu'ils ne comprennentpas
Et je ne trouve pas pour autant Emacs « mal fichu » (bien que sur ce
coup-là, quand même) ;-)
Pas très fréquent, la dernière fois que j'ai eu un problème avec ça, c'était il y a 10 ans avec Emacs, j'avais envoyé des patchs et c'était corrigé.
Il y a eu, beaucoup plus récemment, un problème avec OCaml : le lexer reconnaissait les nombres flottants avec un point, naturellement, mais utilisait ensuite la libc pour les convertir, et ça cassait dans le toplevel lablgtk, parce que Gtk+ fait un setlocale à l'initialisation.
J'ai trouvé un bug tout à fait similaire dans GNU Emacs il y a moins d'un an (2004-02, de mémoire). Mais le setlocale() fautif se trouvait dans les sources propres d'Emacs. Glups !
D'une manière générale, il y a plein de programmes mal fichus dont les auteurs ont copié-collé un setlocale qu'ils ne comprennentpas
Et je ne trouve pas pour autant Emacs « mal fichu » (bien que sur ce coup-là, quand même) ;-)
