J'ai là des fichiers "texte" qui doivent théoriquement être en ascii,
et pas en iso-machin ou utf-42.
Quel est le moyen le plus simple, dans un Unix "générique", et en
utilisant les outils de base, de détecter si ce fichier contient
autre chose que du vrai ascii ?
tTh.
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
Dans fr.comp.os.unix Nicolas George nous expliquait:
Tonton Th , dans le message <4cc2b45f$0$12073$, a écrit :
Éventuellement en remplaçant la locale par C...
Avoir autre chose, à part à la rigueur dans LC_CTYPE et éventuellement dans LC_MESSAGES si on est mauvais en anglais, c'est de toutes façons du suicide.
Gnîîî ? Pour quelles raisons ? Je ne sais pas si mes choix sont judicieux mais quelques arguments m'aideraient. Les messages en anglais ne me gênent aucunement mais il faut bien que quelqu'un lise les versions localisées ;-)
La plupart de ces locales sont ignorées par quasiment tous les programmes. Je dirais que le plus gênant dans cette liste est LC_NUMERIC. Tu risques de te retrouver avec la séparation des nombres décimaux qui sera parfois une virgule et parfois un point, de façon incohérente.
Doug713705 wrote:
Dans fr.comp.os.unix Nicolas George nous expliquait:
Tonton Th , dans le message <4cc2b45f$0$12073$426a74cc@news.free.fr>, a
écrit :
Éventuellement
en remplaçant la locale par C...
Avoir autre chose, à part à la rigueur dans LC_CTYPE et éventuellement dans
LC_MESSAGES si on est mauvais en anglais, c'est de toutes façons du suicide.
Gnîîî ? Pour quelles raisons ?
Je ne sais pas si mes choix sont judicieux mais quelques arguments
m'aideraient.
Les messages en anglais ne me gênent aucunement mais il faut bien que
quelqu'un lise les versions localisées ;-)
La plupart de ces locales sont ignorées par quasiment tous les
programmes. Je dirais que le plus gênant dans cette liste est
LC_NUMERIC. Tu risques de te retrouver avec la séparation des nombres
décimaux qui sera parfois une virgule et parfois un point, de façon
incohérente.
Dans fr.comp.os.unix Nicolas George nous expliquait:
Tonton Th , dans le message <4cc2b45f$0$12073$, a écrit :
Éventuellement en remplaçant la locale par C...
Avoir autre chose, à part à la rigueur dans LC_CTYPE et éventuellement dans LC_MESSAGES si on est mauvais en anglais, c'est de toutes façons du suicide.
Gnîîî ? Pour quelles raisons ? Je ne sais pas si mes choix sont judicieux mais quelques arguments m'aideraient. Les messages en anglais ne me gênent aucunement mais il faut bien que quelqu'un lise les versions localisées ;-)
La plupart de ces locales sont ignorées par quasiment tous les programmes. Je dirais que le plus gênant dans cette liste est LC_NUMERIC. Tu risques de te retrouver avec la séparation des nombres décimaux qui sera parfois une virgule et parfois un point, de façon incohérente.
Nicolas George
Erwan David , dans le message , a écrit :
Dans LC_CTIME aussi. J'ai horreur qu'on m'indique 3:00 PM...
Pour le coup, LC_TIME, c'est du suicide : des scripts qui parsent la sortie de date, il y en a des paquets.
Erwan David , dans le message <m2k4l9eyr5.fsf@rail.eu.org>, a écrit :
Dans LC_CTIME aussi. J'ai horreur qu'on m'indique 3:00 PM...
Pour le coup, LC_TIME, c'est du suicide : des scripts qui parsent la sortie
de date, il y en a des paquets.
Dans LC_CTIME aussi. J'ai horreur qu'on m'indique 3:00 PM...
Pour le coup, LC_TIME, c'est du suicide : des scripts qui parsent la sortie de date, il y en a des paquets.
Nicolas George
Doug713705 , dans le message <i9uu5e$1h8$, a écrit :
Gnîîî ? Pour quelles raisons ?
Je prends un seul exemple : certaines versions de Caml utilisaient utilisaient les fonctions de la libc pour parser les nombres. Or si on utilise Gtk+ avec, il activait les locales, et alors le séparateur décimal devenait la virgule. Du coup, « let pi = 3.14 » devenait équivalent, dans l'interpréteur, à « let pi = 3.0 ».
Doug713705 , dans le message <i9uu5e$1h8$1@talisker.lacave.net>, a
écrit :
Gnîîî ? Pour quelles raisons ?
Je prends un seul exemple : certaines versions de Caml utilisaient
utilisaient les fonctions de la libc pour parser les nombres. Or si on
utilise Gtk+ avec, il activait les locales, et alors le séparateur décimal
devenait la virgule. Du coup, « let pi = 3.14 » devenait équivalent, dans
l'interpréteur, à « let pi = 3.0 ».
Doug713705 , dans le message <i9uu5e$1h8$, a écrit :
Gnîîî ? Pour quelles raisons ?
Je prends un seul exemple : certaines versions de Caml utilisaient utilisaient les fonctions de la libc pour parser les nombres. Or si on utilise Gtk+ avec, il activait les locales, et alors le séparateur décimal devenait la virgule. Du coup, « let pi = 3.14 » devenait équivalent, dans l'interpréteur, à « let pi = 3.0 ».
Lucas Levrel
Le 23 octobre 2010, Nicolas George a écrit :
Du coup, « let pi = 3.14 » devenait équivalent, dans l'interpréteur, à « let pi = 3.0 ».
En même temps, prendre 3,14 pour pi c'est déjà chercher les emmerdes :-)
Mais l'interpréteur ne râle pas sur le .14 ? Qu'est-ce qu'il en fait ?
-- LL
Le 23 octobre 2010, Nicolas George a écrit :
Du coup, « let pi = 3.14 » devenait équivalent, dans
l'interpréteur, à « let pi = 3.0 ».
En même temps, prendre 3,14 pour pi c'est déjà chercher les emmerdes :-)
Mais l'interpréteur ne râle pas sur le .14 ? Qu'est-ce qu'il en fait ?
Du coup, « let pi = 3.14 » devenait équivalent, dans l'interpréteur, à « let pi = 3.0 ».
En même temps, prendre 3,14 pour pi c'est déjà chercher les emmerdes :-)
Mais l'interpréteur ne râle pas sur le .14 ? Qu'est-ce qu'il en fait ?
-- LL
Nicolas George
Lucas Levrel , dans le message , a écrit :
Mais l'interpréteur ne râle pas sur le .14 ? Qu'est-ce qu'il en fait ?
Ce n'était pas prévu. Le lexer a lexé 3.14, l'a soumis à strtod ou sscanf, qui a lu 3. Comme aucune erreur n'était possible, aucune erreur n'était vérifiée.
Lucas Levrel , dans le message
<alpine.LNX.2.00.1010232151450.3234@electron.libre>, a écrit :
Mais l'interpréteur ne râle pas sur le .14 ? Qu'est-ce qu'il en fait ?
Ce n'était pas prévu. Le lexer a lexé 3.14, l'a soumis à strtod ou sscanf,
qui a lu 3. Comme aucune erreur n'était possible, aucune erreur n'était
vérifiée.
Mais l'interpréteur ne râle pas sur le .14 ? Qu'est-ce qu'il en fait ?
Ce n'était pas prévu. Le lexer a lexé 3.14, l'a soumis à strtod ou sscanf, qui a lu 3. Comme aucune erreur n'était possible, aucune erreur n'était vérifiée.
Jacques Lav!gnotte
Le 23-10-2010, Tonton Th a écrit :
Quel est le moyen le plus simple, dans un Unix "générique", et en utilisant les outils de base, de détecter si ce fichier contient autre chose que du vrai ascii ?
od -xc file
tTh.
J.
Le 23-10-2010, Tonton Th <tth@la.bas.invalid> a écrit :
Quel est le moyen le plus simple, dans un Unix "générique", et en
utilisant les outils de base, de détecter si ce fichier contient
autre chose que du vrai ascii ?
Quel est le moyen le plus simple, dans un Unix "générique", et en utilisant les outils de base, de détecter si ce fichier contient autre chose que du vrai ascii ?
od -xc file
tTh.
J.
Doug713705
Le 23/10/2010 18:16 dans fr.comp.os.unix Marc nous expliquait:
La plupart de ces locales sont ignorées par quasiment tous les programmes. Je dirais que le plus gênant dans cette liste est LC_NUMERIC. Tu risques de te retrouver avec la séparation des nombres décimaux qui sera parfois une virgule et parfois un point, de façon incohérente.
Ahah ! Ça explique certaines choses ! Inkscape me posait un problème de ce genre lors de la définition des dimensions du document pour lesquelles il voulait absolument une virgule en lieu et place d'un point comme il se doit en informatique.
Avec LC_NUMERIC=C je n'ai plus ce problème.
Merci à toi et NG.
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) Usenet-fr ? Mais qu'est-ce que c'est ? Pour en savoir plus : http://www.dougwise.org/wiki
Le 23/10/2010 18:16 dans fr.comp.os.unix Marc nous expliquait:
La plupart de ces locales sont ignorées par quasiment tous les
programmes. Je dirais que le plus gênant dans cette liste est
LC_NUMERIC. Tu risques de te retrouver avec la séparation des nombres
décimaux qui sera parfois une virgule et parfois un point, de façon
incohérente.
Ahah ! Ça explique certaines choses !
Inkscape me posait un problème de ce genre lors de la définition des
dimensions du document pour lesquelles il voulait absolument une
virgule en lieu et place d'un point comme il se doit en informatique.
Avec LC_NUMERIC=C je n'ai plus ce problème.
Merci à toi et NG.
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Usenet-fr ? Mais qu'est-ce que c'est ?
Pour en savoir plus : http://www.dougwise.org/wiki
Le 23/10/2010 18:16 dans fr.comp.os.unix Marc nous expliquait:
La plupart de ces locales sont ignorées par quasiment tous les programmes. Je dirais que le plus gênant dans cette liste est LC_NUMERIC. Tu risques de te retrouver avec la séparation des nombres décimaux qui sera parfois une virgule et parfois un point, de façon incohérente.
Ahah ! Ça explique certaines choses ! Inkscape me posait un problème de ce genre lors de la définition des dimensions du document pour lesquelles il voulait absolument une virgule en lieu et place d'un point comme il se doit en informatique.
Avec LC_NUMERIC=C je n'ai plus ce problème.
Merci à toi et NG.
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) Usenet-fr ? Mais qu'est-ce que c'est ? Pour en savoir plus : http://www.dougwise.org/wiki
Vincent Lefevre
Dans l'article <4cc29a7c$0$5343$, Damien Wyart écrit:
* Tonton Th in fr.comp.os.unix: > Quel est le moyen le plus simple, dans un Unix "générique", et en > utilisant les outils de base, de détecter si ce fichier contient autre > chose que du vrai ascii ?
Avec "file", sous Linux, cela fonctionne bien.
J'allais dire "pas du tout". Mais je viens de découvrir l'option --mime-encoding. Et l'encodage est donné aussi avec "file -i". Exactement ce qu'il me fallait pour lesspipe! Car "file fichier.tex" seul n'indique jamais l'encodage (contrairement aux fichiers texte génériques) et c'était bien embêtant.
Note: ça fonctionne aussi sous Mac OS X, avec le "file" de MacPorts, qui est le même que celui de Linux.
Sous Maemo 5, qui n'a que la version 4.12 de file, l'option --mime-encoding n'existe pas, mais l'option -i semble bien donner l'encodage. Donc je dirais: privilégier -i.
Dans l'article <4cc29a7c$0$5343$426a34cc@news.free.fr>,
Damien Wyart <damien.wyart@free.fr> écrit:
* Tonton Th <tth@la.bas.invalid> in fr.comp.os.unix:
> Quel est le moyen le plus simple, dans un Unix "générique", et en
> utilisant les outils de base, de détecter si ce fichier contient autre
> chose que du vrai ascii ?
Avec "file", sous Linux, cela fonctionne bien.
J'allais dire "pas du tout". Mais je viens de découvrir l'option
--mime-encoding. Et l'encodage est donné aussi avec "file -i".
Exactement ce qu'il me fallait pour lesspipe! Car "file fichier.tex"
seul n'indique jamais l'encodage (contrairement aux fichiers texte
génériques) et c'était bien embêtant.
Note: ça fonctionne aussi sous Mac OS X, avec le "file" de MacPorts,
qui est le même que celui de Linux.
Sous Maemo 5, qui n'a que la version 4.12 de file, l'option
--mime-encoding n'existe pas, mais l'option -i semble bien donner
l'encodage. Donc je dirais: privilégier -i.
Dans l'article <4cc29a7c$0$5343$, Damien Wyart écrit:
* Tonton Th in fr.comp.os.unix: > Quel est le moyen le plus simple, dans un Unix "générique", et en > utilisant les outils de base, de détecter si ce fichier contient autre > chose que du vrai ascii ?
Avec "file", sous Linux, cela fonctionne bien.
J'allais dire "pas du tout". Mais je viens de découvrir l'option --mime-encoding. Et l'encodage est donné aussi avec "file -i". Exactement ce qu'il me fallait pour lesspipe! Car "file fichier.tex" seul n'indique jamais l'encodage (contrairement aux fichiers texte génériques) et c'était bien embêtant.
Note: ça fonctionne aussi sous Mac OS X, avec le "file" de MacPorts, qui est le même que celui de Linux.
Sous Maemo 5, qui n'a que la version 4.12 de file, l'option --mime-encoding n'existe pas, mais l'option -i semble bien donner l'encodage. Donc je dirais: privilégier -i.
