La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux => Discussion démarrée par: cali le 10 mai 2013 à 00:18:07
-
C'est parti pour la configuration de fichier. Vous utilisez la manière que vous voulez. Perso, j'ouvre un explorateur, je trouve mon fichier à modifier, je fais un clic droit, "ouvrir en tant qu'administrateur". (Windows style yeah !)
Grosse connerie à ne pas faire. En faisant ça tu sauvegardes le fichier avec le carriage return et line feed alors que les systèmes unix utilisent le line break.
-
Je n'ai pas dit que j'éditais à partir de Windows. Toutes les manipulations sont effectuées sous Linux.
Je comparais cette approche à Windows (le clic droit > Exécuter en tant que...) parce que c'était un point commun, et que je préfère 100 fois cette méthode à celle qui est souvent conseillée sous Linux: la ligne de commande. La ligne de commande... c'est so yesterday...
-
La ligne commande, c'est généralement la seule façon pas trop pénible de faire des traitements systématiques.
Mais la ligne de commande Unix est vraiment très, très, très mal foutue contrairement à la propagande des Unixiens, et la plupart des utilitaires utilisables en ligne de commande interagissent vraiment mal surtout dans les cas pathologiques, même si GNU a fait des progrès par rapport à Unix tradi. Les utilitaires comme grep, sed, awk... forment un patchwork délirant et totalement infect, mais qui génère des "gourous" qui ne sont plus capables de voir la débilité du truc, notamment du principe fondamental de combiner des commandes avec | (connexion de flux de caractères).
Pour désigner un seul objet et faire une opération simple dessus (ouvrir, renommer, supprimer), je ne vois pas mieux que de cliquer dessus.
-
pas d'accord avec toi corrector!
la console linux est un très bon moyen d'administrer un serveur!
c'est légé, ça prend rien en ressources.
c'est sur il faut un apprentissage conséquent pour s'en servir correctement.
un exemple pour un windows serveur installé tu fais tourner quasiment 3 linux sans interface (pour la base)
tu rajoute l'interface sur les linux déjà tu en fait tourner moins.
-
butler_fr, tu fais souvent des traitements de lots en ligne de commande?
Pour cela, tu utilises un utilitaire ad hoc, ou bien tu combines des commandes avec des |, des boucles, etc.?
-
Les vrais hommes font une macro sous vi et s'aident de awk.
Les autres les regardent faire.
-
Pour cela, tu utilises un utilitaire ad hoc, ou bien tu combines des commandes avec des |, des boucles, etc.?
Cela dépends des cas comme casiment tout dans ce monde.
Souvent je peut exprimer mon besoin facilement en shell, parfois je sort un vrai language de programmation (c/python/php).
-
Ce que je reproche au shell Unix, c'est que le moindre traitement demande 6 à 10 commandes, dont la plupart juste pour pré-traiter/filtrer/reformater une sortie textuelle pour la rendre acceptable à l'étape suivante : on passe énormèment de temps à faire de la "soudure". En plus beaucoup de scripts sont très fragiles, sensibles au moindre changement de format de sortie, à un changement de locale, à un espace dans un nom de fichier... il est plus passablement difficile de faire des scripts robustes. Pour faire un script qui marche sur n'importe quel nom de fichier, il faut plein de précautions.
-
Pour faire un script qui marche sur n'importe quel nom de fichier, il faut plein de précautions.
Parce que j'ai écrit une tétrachiée de scripts shell ces quinze dernières années, et manipulé des tas de fichiers avec des noms plus cons les uns que les autres, je peux t'assurer que ton "plein de précautions" se limite généralement à protéger le nom du fichier par des guillemets, comme ceci :
commande <paramètres> "fichier"
Pour le cas vraiment tordu où celui-ci commence par des tirets et que la commande le prend pour un de ses paramètres, il suffit généralement de lui indiquer qu'on a fini de lui servir des paramètres avant de lui donner le nom du fichier à traiter :
commande <paramètres> -- "fichier"
Et pour revenir au sujet initial, l'édition d'un fichier de configuration, ça peut très bien être fait depuis un éditeur de texte graphique, que ce soit depuis le système Linux ou une machine tierce Windows.
Il suffit juste de disposer des bons outils (qui savent travailler au travers d'une connexion SSH, comprennent Unicode, et gèrent correctement les fins de lignes en fonction du système cible).
Inutile de préciser que cette bouse d'éditeur texte qu'est Notepad n'en fait pas partie ...
-
1) OK, mais c'est vachement dur de penser à protéger 100 % des cas.
C'est comme les injections SQL : c'est facile de comprendre qu'il faut échapper les paramètres, c'est plus difficile de s'assurer qu'on a échappé 100 % des paramètres sans mécanisme 100 % automatique (comme les requêtes préparées...).
2) Je ne suis pas sûr que tous les utilitaires acceptent --
Certaines commandes internes du shell par exemple n'acceptent pas -- (mais elles n'en ont pas besoin). C'est pas uniforme = c'est moins facile.
Concernant les bons outils : la dernière fois que j'ai vérifié, bash ne gérait même pas UTF8! (Et manifestement, cela a changé depuis.) Résultat : en présence de noms de fichiers UTF8 sur la ligne de commande, l'éditeur de ligne déplace le curseur en dehors de la zone. C'est complètement naze. (zsh gère UTF8 depuis longtemps, zsh rend plus facile le traitement des noms de fichiers contenant des espace, vive zsh tout ça)
-
Pour les deux premiers points : trouve-moi un cas pour lequel ça ne fonctionne pas, et on en rediscute.
Pour bash, outre le fait que je ne vois pas le rapport avec la choucroute (il était question d'éditer un fichier de configuration, et aux dernières nouvelles, un interpréteur de commandes n'est pas un éditeur de texte), je ne sais pas à quand remonte ton dernier face-à-face avec lui, mais il gère parfaitement bien Unicode :
seb@nestor:~$ echo $LANG
fr_FR.UTF-8
seb@nestor:~$ echo $SHELL
/bin/bash
seb@nestor:~$ touch ☠☠☠
seb@nestor:~$ ls -l
-rw-r--r-- 1 seb seb 0 mai 12 11:14 ☠☠☠
seb@nestor:~$ file ☠☠☠
☠☠☠: emptyPour info, j'ai utilisé la complétion de noms (tabulation) pour la commande file.
Version de bash : 4.2.37.
-
OVH a longtemps viré l'UTF-8 dans les système d'exploitation qu'il pré-installe :o
Je trouve dommage de ne pas proposer la distribution d'origine, sans les nombreuses modifs d'OVH (qui peuvent poser pb lors de la mise-à-jour).
-
Pour bash, outre le fait que je ne vois pas le rapport avec la choucroute (il était question d'éditer un fichier de configuration,
Pas dans mon message.
et aux dernières nouvelles, un interpréteur de commandes n'est pas un éditeur de texte),
Au dernière nouvelle, c'en est un. ;)
je ne sais pas à quand remonte ton dernier face-à-face avec lui
Pas assez longtemps, malheureusement. (J'essaie d'éviter ce shell qui ne comprend même pas UTF8.)
seb@nestor:~$ echo $LANG
fr_FR.UTF-8
seb@nestor:~$ echo $SHELL
/bin/bash
seb@nestor:~$ touch ☠☠☠
seb@nestor:~$ ls -l
-rw-r--r-- 1 seb seb 0 mai 12 11:14 ☠☠☠
seb@nestor:~$ file ☠☠☠
☠☠☠: empty
Tu nous fais un petit file ???
-
Au dernière nouvelle, c'en est un. ;)
Ah ?
On ne doit pas avoir la même interprétation de la notion d'éditeur de texte, alors.
Tu nous fais un petit file ???
Avec plaisir :
seb@nestor:~$ file ???
☠☠☠: empty
BMC: directory
J'ai triché tout à l'heure sur le résultat de la commande ls, il y a plein de bordel dans ma home directory :
seb@nestor:~$ ls -l
total 526820
-rw-r--r-- 1 seb seb 0 mai 12 11:14 ☠☠☠
drwxr-xr-x 3 seb seb 4096 mai 2 14:39 BMC
-rw-r--r-- 1 seb seb 24432940 mai 2 14:38 BMC_FW_Version1.3_12_07_2012.zip
-rw-r--r-- 1 seb seb 326326 mai 3 22:56 duplicity_0.6.20-3_amd64.deb
-rwxr-xr-x 1 seb seb 1905 janv. 10 00:56 flac2mp3
-rw-r--r-- 1 seb seb 513802240 mai 7 22:57 F_TS-459_20091106-3.2.0.img
-rw------- 1 seb seb 781 mai 9 12:20 mbox
-rw------- 1 seb seb 794857 mai 7 22:57 nohup.out
drwxr-xr-x 2 seb seb 4096 janv. 10 00:35 now_playing
-rw-r--r-- 1 seb seb 53947 déc. 25 20:37 output2.xls
-rw-r--r-- 1 seb seb 17164 déc. 25 19:36 output.xls
-
Pour les deux premiers points : trouve-moi un cas pour lequel ça ne fonctionne pas, et on en rediscute.
Comme je disais :
1) OK, mais c'est vachement dur de penser à protéger 100 % des cas.
C'est comme les injections SQL : c'est facile de comprendre qu'il faut échapper les paramètres, c'est plus difficile de s'assurer qu'on a échappé 100 % des paramètres sans mécanisme 100 % automatique (comme les requêtes préparées...).
Le problème : on oublie très facilement un quote, ou un --.
On peut aussi vouloir utiliser un programme qui est en fait script qui n'a pas été blindé contre les noms de fichiers bizarres.
Le problème du shell (selon moi), surtout sh/bash : ce n'est pas automatique, il faut y penser à chaque fois. (Avec zsh il y a un peu moins de quote à mettre, mais ça n'évacue pas tous les pièges.)
-
Avec plaisir :
seb@nestor:~$ file ???
☠☠☠: empty
J'ai triché tout à l'heure sur le résultat de la commande ls, il y a plein de bordel dans ma home directory :
On s'en fout, bash supporte UTF8, bravo.
-
Une fois n'est pas coutume, vais te faire deux réponses à la corrector :
Comme je disais :Le problème : on oublie très facilement un quote, ou un --.
Mauvaise habitude, changer habitude.
On peut aussi vouloir utiliser un programme qui est en fait script qui n'a pas été blindé contre les noms de fichiers bizarres.
Mauvais programme, changer programme.
Parce que c'est trop facile de dénigrer un outil quand on ne sait pas s'en servir correctement ...
Et je compléterai quand même en disant qu'aucun shell n'est parfait, et qu'au delà d'un certain niveau de complexité, on a tout intérêt à utiliser un langage plus évolué pour faire de gros traitements, ne serait-ce que parce que ce sera bien plus efficace et rapide.
Pour ma part, maintenant que je le trouve sur tous les systèmes avec lesquels je bosse, j'ai vite fait de troquer le shell pour un coup de perl.
-
Mauvaise doc de bash aussi, qui ne dit pas un mot sur le support UTF8 (ou alors vraiment bien caché).
-
Mauvaise doc de bash, ou mauvaise foi de ta part ?
Le fait que bash supporte Unicode est acquis depuis sa version 2.05b, qui date de 2002.
Ce qui ne veut pas dire pour autant que les systèmes livrés par la suite intégraient tout le nécessaire pour gérer correctement les caractères Unicode, loin de là*.
Mais en quoi est-ce un problème de bash ?
Et qu'est-ce que tu attends comme documentation, au juste, si ce n'est la manière de traiter les caractères Unicode ?
Parce que sur ce point précis, il ne faut pas chercher bien loin :
seb@nestor:~$ man bash | grep -i unicode | head -1
\uHHHH le caractère Unicode (ISO/IEC 10646) dont la valeur hexadécimale est HHHH (un à quatre chiffres hexadécimaux) ;
Je ne sais pas ce que ce shell t'a fait pour que tu le haïsses ainsi, mais ça serait pas mal que tu arrêtes de faire de la désinformation à son propos ...
* cf. exemple donné par Vivien sur les serveurs OVH.
-
Ce qui est un extrait de la norme C. N'importe quel compilateur C pourrait document la même chose.
Je ne vois pas en quoi ça prouve que le shell "supporte" Unicode, plus qu'un compilateur C, qui ne supporterait que les caractères ASCII.
-
Hé oh, faut pas essayer de me la faire à l'envers, corrector ! :o
C'est toi qui as écrit, je cite : "J'essaie d'éviter ce shell qui ne comprend même pas UTF8".
Je t'ai montré par l'exemple que ça fonctionnait parfaitement bien sur mon système, et - autant que je me souvienne - la prise en charge par bash de caractères Unicode dans les noms de fichiers fonctionnait déjà correctement à l'époque de la debian sarge (2005), puisque c'est à peu près à ce moment là que j'avais converti ceux de mes fichiers de WE8ISO8859P15 en UTF-8 (et je ne me suis jamais privé de coller des accents et autres caractères exotiques dans mes noms de fichiers !).
seb@nestor:/data/media/musique/flac$ find /data/media/musique/flac/Sigur\ Rós/
/data/media/musique/flac/Sigur Rós/
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/01. Gobbledigook.flac
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/09. Fljótavík.flac
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/08. Illgresi.flac
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/02. Inní mér syngur vitleysingur.flac
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/04. Við spilum endalaust.flac
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/07. Ára bátur.flac
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/03. Góðan daginn.flac
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/05. Festival.flac
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/Með suð í eyrum við spilum endalaust.log
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/10. Straumnes.flac
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/11. All Alright.flac
/data/media/musique/flac/Sigur Rós/Með suð í eyrum við spilum endalaust/06. Með suð í eyrum.flac
À toi d'apporter la preuve de ce que tu annonces.
-
J'annonce que la doc ne parle pas du tout du support de l'Unicode en général et de l'UTF8 en particulier.
Ce que je trouve étonnant.
-
C'est toi qui as écrit, je cite : "J'essaie d'éviter ce shell qui ne comprend même pas UTF8".
J'ai barré cette affirmation.
Je t'ai montré par l'exemple que ça fonctionnait parfaitement bien sur mon système,
OUI, mais à ma demande, pas spontanèment.
seb@nestor:/data/media/musique/flac$ find /data/media/musique/flac/Sigur\ Rós/
Commande qui ne démontre rien du tout!
Tu peux faire ça dans n'importe quel shell qui ne comprend pas UTF8 ni aucun encodage!
-
J'ai barré cette affirmation.
Non, vérifie, elle figure toujours en clair dans ton message.
OUI, mais à ma demande, pas spontanèment.
Vu que je n'ai aucun problème avec la gestion de l'Unicode par bash, je n'ai rien à te prouver spontanèment, il me semble ...
C'est comme en droit : c'est à l'accusateur d'apporter les preuves de ce qu'il affirme.
Commande qui ne démontre rien du tout!
Non, je te montrais simplement par l'exemple d'un album que j'ai une multitude de fichiers musicaux qui contiennent des caractères Unicode dans leurs noms de fichiers.
Lesquels fichiers sont très régulièrement traités par des moulinettes shell (oui, avec bash) que j'utilise déjà depuis quelques années, et qui me servent à mettre à jour leurs tags et autres joyeusetés dans le genre.
Donc je pense que si bash était incapable de traiter correctement Unicode, comme tu l'as affirmé, je serais au courant depuis le temps. ;)
-
Lesquels fichiers sont très régulièrement traités par des moulinettes shell (oui, avec bash) que j'utilise déjà depuis quelques années, et qui me servent à mettre à jour leurs tags et autres joyeusetés dans le genre.
Donc je pense que si bash était incapable de traiter correctement Unicode, comme tu l'as affirmé, je serais au courant depuis le temps. ;)
Avec tout le respect, j'ai rencontré un mec qui utilisait depuis des années bash sous GNU/linux sur système tout UTF8 (avec des incohérences de config que j'ai tout de suite vu), et il ne s'était jamais rendu compte que son bash gérait pas UTF8.
Tu m'as d'ailleurs donné plusieurs exemples qui ne démontraient en rien ce que tu avais l'air de penser qu'ils démontraient : n'importe quel shell qui ne comprend pas du tout UTF8 peut arriver à faire de la complétion de noms de fichier et de passer à find un nom en UTF8.
Je ne sais pas pourquoi chez toi bash passe en UTF8 et pas chez le bouffon précité : je crois me souvenir que ses locales étaient bien UTF8.
Je vais essayer de tirer ça au clair.
-
Tu m'as d'ailleurs donné plusieurs exemples qui ne démontraient en rien ce que tu avais l'air de penser qu'ils démontraient : n'importe quel shell qui ne comprend pas du tout UTF8 peut arriver à faire de la complétion de noms de fichier et de passer à find un nom en UTF8.
Alors je fais une nouvelle tentative :
seb@nestor:~$ for f in /data/media/musique/flac/Sigur\ Rós/Með\ suð\ í\ eyrum\ við\ spilum\ endalaust/*.flac; do t=$(printf "%s\n" $f | file -); echo "$t - $(basename "$f")"; done
/dev/stdin: UTF-8 Unicode text - 01. Gobbledigook.flac
/dev/stdin: UTF-8 Unicode text - 02. Inní mér syngur vitleysingur.flac
/dev/stdin: UTF-8 Unicode text - 03. Góðan daginn.flac
/dev/stdin: UTF-8 Unicode text - 04. Við spilum endalaust.flac
/dev/stdin: UTF-8 Unicode text - 05. Festival.flac
/dev/stdin: UTF-8 Unicode text - 06. Með suð í eyrum.flac
/dev/stdin: UTF-8 Unicode text - 07. Ára bátur.flac
/dev/stdin: UTF-8 Unicode text - 08. Illgresi.flac
/dev/stdin: UTF-8 Unicode text - 09. Fljótavík.flac
/dev/stdin: UTF-8 Unicode text - 10. Straumnes.flac
/dev/stdin: UTF-8 Unicode text - 11. All Alright.flac
(Ça fonctionne aussi sans le printf, mais je voulais forcer bash à traiter l'affichage)
Ça te convainc un peu plus ?
Moi, je considère qu'un shell qui prend de l'UTF-8 en entrée et produit encore de l'UTF-8 en sortie sait gérer l'UTF-8 correctement (c'est à dire que ses traitements sont transparents vis-à-vis de ce jeu de caractères).
Mais ce n'est peut être pas ta définition de la bonne gestion UTF-8.
Auquel cas, j'attends la tienne pour comprendre quel doute t'habite encore ...
-
Ça te convainc un peu plus ?
Absolument pas.
Tu aurais pu te contenter de
file - <<<été
cela m'aurait fait le même effet!
Je crois que on ne s'entend pas du tout sur le sens de "bash supporte UTF8" :
- tu comprends : bash est "8 bits safe"
- je veux dire : bash comprend l'encodage UTF8, il sait encoder/décoder UTF8
-
Développe.
-
Mettons :
if [[ é == ? ]]; then echo "é est un caractère"; fi
if [[ é == ?? ]]; then echo "é est 2 caractères"; fi
if [[ é == [é] ]]; then echo "é est un caractère"; fi
if [[ é == [[:alpha:]] ]]; then echo "é est alpha"; fi
-
J'y comprends rien (pour moi ça a toujours marché) mais voici ce que ça donne :
# echo $LANG
en_US
# if [[ é == ? ]]; then echo "é est un caractère"; fi
é est un caractère
# if [[ é == [é] ]]; then echo "é est un caractère"; fi
é est un caractère
# if [[ é == [[:alpha:]] ]]; then echo "é est alpha"; fi
é est alpha
-
J'y comprends rien (pour moi ça a toujours marché) mais voici ce que ça donne :
# echo $LANG
en_US
C'est surtout LC_CTYPE qui serait intéressant. Sinon, locale est censé tout afficher.
-
J'ai ça de défini :
LC_COLLATE=C
Mais aucune des variables que tu m'as cité.
-
J'ai cité des variables, moi?
Que raconte la commande locale?
-
Ah pardon je parlais de LC_CTYPE.
Ben j'ai tout à en_US.
-
echo été | wc -
-
# echo été | wc -
1 1 4 -
Même joueur joue encore.
-
echo été | xxd
-
Ubuntu 13.04 64bits :
$ echo été | xxd
0000000: c3a9 74c3 a90a ..t...
-
Il faut faire tous les tests!
-
$ echo été | wc -
1 1 6 -
$ if [[ é == ? ]]; then echo "é est un caractère"; fi
é est un caractère
$ if [[ é == ?? ]]; then echo "é est 2 caractères"; fi
$ if [[ é == [é] ]]; then echo "é est un caractère"; fi
é est un caractère
$ if [[ é == [[:alpha:]] ]]; then echo "é est alpha"; fi
é est alpha
-
Bravo!
Qu'indique locale?
-
# echo été | xxd
0000000: e974 e90a .t..
-
# echo été | xxd
0000000: e974 e90a .t..
Ah oui, quand même. Tu n'es pas du tout en UTF8.
J'y comprends rien (pour moi ça a toujours marché)
Voilà : ça marche parce que tu n'es pas en UTF8.
Comme la discussion porte sur le support UTF8 de bash, tu es un peu hors-sujet.
-
Alors je fais une nouvelle tentative :
seb@nestor:~$ for f in /data/media/musique/flac/Sigur\ Rós/Með\ suð\ í\ eyrum\ við\ spilum\ endalaust/*.flac; do t=$(printf "%s\n" $f | file -); echo "$t - $(basename "$f")"; done
(Ça fonctionne aussi sans le printf, mais je voulais forcer bash à traiter l'affichage)
Ça te convainc un peu plus ?
Moi, je considère qu'un shell qui prend de l'UTF-8 en entrée et produit encore de l'UTF-8 en sortie sait gérer l'UTF-8 correctement (c'est à dire que ses traitements sont transparents vis-à-vis de ce jeu de caractères).
Mais ce n'est peut être pas ta définition de la bonne gestion UTF-8.
Auquel cas, j'attends la tienne pour comprendre quel doute t'habite encore ...
Décomposons
for f in /data/media/musique/flac/Sigur\ Rós/Með\ suð\ í\ eyrum\ við\ spilum\ endalaust/*.flac;
do
t=$(printf "%s\n" $f | file -)
echo "$t - $(basename "$f")"
done
- /data/media/musique/flac/Sigur\ Rós/Með\ suð\ í\ eyrum\ við\ spilum\ endalaust/*.flac : globbing (englobement? englobage?) d'un chemin comportant des caractères non-ASCII encodés en UTF8 :
- MOTIF = /data/media/musique/flac/Sigur\ Rós/Með\ suð\ í\ eyrum\ við\ spilum\ endalaust/*.flac ;
décomposition de MOTIF en CHEMIN/MOTIF_SIMPLE
par motif (Perl-style) :
([^?*]*)/([^/]+)
avec CHEMIN = \1 et MOTIF_SIMPLE = \2
on obtient :
CHEMIN = /data/media/musique/flac/Sigur\ Rós/Með\ suð\ í\ eyrum\ við\ spilum\ endalaust
MOTIF = *.flac
- ouverture du répertoire CHEMIN = /data/media/musique/flac/Sigur\ Rós/Með\ suð\ í\ eyrum\ við\ spilum\ endalaust : DIR *dir = readdir("/data/media/musique/flac/Sigur\ Rós/Með\ suð\ í\ eyrum\ við\ spilum\ endalaust")
- récupération d'un élèment du répertoire : struct dirent *entry = readdir (dir);
si entry est nul : break
- recopie de entry->d_name (qui est un texte comportant des caractères non-ASCII encodés en UTF8) dans NOM_FICHIER
- englobement de NOM_FICHIER contre MOTIF_SIMPLE, sans doute par automate déterministe;
il me semble que le motif reg-exp correspondant à MOTIF_SIMPLE est (|([^.].*))\.flac autrement dit (\.flac)|([^.].*\.flac)
si pas de correspondance : continue
- concaténation de CHEMIN "/" NOM_FICHIER dans CHEMIN_FICHIER
- ajout de CHEMIN_FICHIER au résultat de l'englobement
- for f in : affectation à une variable, qui contient donc un texte comportant des caractères non-ASCII encodés en UTF8
- $f : décomposition de $f (texte comportant des caractères non-ASCII encodés en UTF8) en mots en fonction des séparateurs "Internal Field Separator" (variable spéciale $IFS)
printf "%s\n" $f | file - : passage du résultat comme arguments du programme commande interne au shell printf
Pourquoi pas faire file $f tout simplement?
- $(basename "$f") : passage d'un texte comportant des caractères non-ASCII encodés en UTF8 en argument du programme basename;
récupération du contenu émis sur le descripteur de fichier n°1 par ce processus, suppression du dernier retour à la ligne;
Pourquoi quoter $f ce coup ci et pas la ligne d'avant?
- "$t - $(basename "$f")" : fabrication d'un texte comportant des caractères non-ASCII encodés en UTF8
- echo "$t - $(basename "$f")" : copie sur le descripteur de fichier n°1 d'un texte comportant des caractères non-ASCII encodés en UTF8
Qu'est-ce que tu veux prouver?
On voit que bash ne se viande pas sur les octets dont le premier bit est à 1. Super. On ne s'en doutait pas.
On va donc pouvoir travailler sur des données en ISO-Latin-1 avec bash! 8)
-
Moi, je considère qu'un shell qui prend de l'UTF-8 en entrée et produit encore de l'UTF-8 en sortie sait gérer l'UTF-8 correctement (c'est à dire que ses traitements sont transparents vis-à-vis de ce jeu de caractères).
Pinaillage : le jeu de caractère est Unicode; UTF8 est un encodage possible d'Unicode.
Quels sont ces "traitements"?
- motif (Perl-style) :
([^?*]*)/([^/]+)
= chercher le dernier / et s'assurer qu'il n'y a pas de ? ni * avant - (|([^.].*))\.flac autrement dit
(\.flac)|([^.].*\.flac)
= le nom se termine par .flac et ne commence pas par . ou bien le nom est .flac - $f : décomposition de $f en mots en fonction des séparateurs "Internal Field Separator" (variable spéciale $IFS)
- suppression du dernier retour à la ligne
Tu pourrais aussi soutenir que linux (notamment ext2 et le VFS) supporte UTF8 à ce compte là : il traite bien les noms de fichier en UTF8.
-
Ah oui, quand même. Tu n'es pas du tout en UTF8.
Voilà : ça marche parce que tu n'es pas en UTF8.
Comme la discussion porte sur le support UTF8 de bash, tu es un peu hors-sujet.
Je comprends toujours pas. Autre exemple alors :
# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
# echo été | xxd
0000000: e974 e90a .t..
Rappel de l'ancien résultat :
# echo été | xxd
0000000: e974 e90a .t..
-
C'est l'histoire du type qui dit : "je ne parle pas français et je ne fais pas de prose". Il ment.
LC_CTYPE="en_US.UTF-8"
est un mensonge : cela ne décrit pas la réalité.
Ce n'est pas parce que tu dis un truc que ça devient vrai.
Il faut :
1) passer en UTF8;
2) ensuite annoncer aux processus que tu l'as fait via l’environnement.
-
Ah non mais j'ai rien fait, tous les paramètres sont d'origine. Tous mes autres serveurs (du RH 3/4/5, du Ubuntu, etc) affichent la même valeur et sont pourtant tous en UTF8.
J'suis lourd mais j'ai toujours pas compris. Ou alors "echo été" n'est pas le bon test.
-
Ben là tu n'es pas en UTF8, point.
Donc l’environnement ment au shell et aux autres programmes lancés par le shell. Cela ne peut pas fonctionner!
Est-ce que tu peux créer un fichier dans un éditeur graphique avec des accents, et ensuite l'afficher dans le shell?
Et inversement, créer un fichier en shell : echo été > été
et ensuite l'ouvrir via un gestionnaire de fichier graphique?
-
Sauf pour l'outil graphique où ça va pas être possible, sur une Slackware, ça donne :
$ echo été > été
$ ls -l
total 4
-rw-r--r-- 1 xx users 4 2013-05-15 14:49 été
$ cat été
été
$ vi été
reading été
(ajout de caractères accentués)
$ cat été
été
àéèçôîï
$
-
Sauf pour l'outil graphique où ça va pas être possible
Tu utilises un terminal virtuel?
-
Oui là en effet c'était une Konsole.
(c'était ça que tu voulais en fait ?)
-
Oui là en effet c'était une Konsole.
Qu'il faut donc paramétrer en mode UTF8.
(c'était ça que tu voulais en fait ?)
Non, je voulais que tu ouvres le fichier dans autre chose qu'un programme en mode console.
-
Pourquoi pas faire file $f tout simplement?
Soit, il me semblait que printf était une fonction du shell. :-[
Mais je ne sais toujours pas ce que tu entends par décoder/encoder en UTF-8, et j'attends toujours que tu développes, parce que je ne vois toujours pas dans quels cas de figure bash serait un shell inadapté.
Comme j'adore tes explications sur le fait que le shell ne voit rien de ce que je lui donne, je te laisse sur ce petit script amusant :
seb@raoul:~$ cat toto
#!/bin/bash
if [ $# -ne 2 ]
then
echo "Usage: $(basename $0) <chaine> <motif>"
echo ""
echo "Affiche la partie de chaîne située après le motif spécifié."
exit 1
fi
chaine="$1"
motif="$2"
apres=${chaine##${motif}}
if [ -z "$apres" ]
then
echo "Pas de correspondance."
else
echo "Correspondance trouvée : \"$apres\""
fi
Qui, à l'exécution, donne ceci :
seb@raoul:~$ ./toto "aßbÑcýdÅeãfŮg" "*Å"
Correspondance trouvée : "eãfŮg"
Il ne voit peut être rien, mais il comprend ce que je lui demande ...
-
Exécuté depuis Konsole sous ubuntu 13.04 (fr_FR.UTF-8)
$ sh test_utf.sh "aßbÑcýdÅeãfŮg" "*Å"
Correspondance trouvée : "eãfŮg"
(copier-coller entièrement à la souris sous Linux du navigateur vers Konsole et l'inverse pour le résultat)
Sous Slackware 13.37 (accès via ssh depuis Konsole)
$ sh test_utf.sh "aßbÑcýdÅeãfŮg" "*Å"
Correspondance trouvée : "eãfŮg"
(résultat copié-coller à la souris)
Très rigolo comme jeu en fait.
-
Soit, il me semblait que printf était une fonction du shell. :-[
Ah oui, en effet : The printf command (http://wiki.bash-hackers.org/commands/builtin/printf)
Mais je ne sais toujours pas ce que tu entends par décoder/encoder en UTF-8, et j'attends toujours que tu développes, parce que je ne vois toujours pas dans quels cas de figure bash serait un shell inadapté.
Je ne dis pas ça, je dis que tes exemples ne démontrent rien du tout.
Comme j'adore tes explications sur le fait que le shell ne voit rien de ce que je lui donne, je te laisse sur ce petit script amusant :
seb@raoul:~$ cat toto
#!/bin/bash
if [ $# -ne 2 ]
then
echo "Usage: $(basename $0) <chaine> <motif>"
echo ""
echo "Affiche la partie de chaîne située après le motif spécifié."
exit 1
fi
chaine="$1"
motif="$2"
apres=${chaine##${motif}}
if [ -z "$apres" ]
then
echo "Pas de correspondance."
else
echo "Correspondance trouvée : \"$apres\""
fi
Qui, à l'exécution, donne ceci :
seb@raoul:~$ ./toto "aßbÑcýdÅeãfŮg" "*Å"
Correspondance trouvée : "eãfŮg"
Toujours pas d'UTF8. ;)
Tu devrais essayer tes propres tests avec une locale ISO-Latin-*.
-
Exécuté depuis Konsole sous ubuntu 13.04
Avec quel codage de caractères?
-
UTF8 :)
-
echo été | xxd
-
ta console doit être en UTF8 (putty ou autre)
ton fichier doit être en UTF8
et fichiers de config doit être en UTF8 (le .conf quand tu démarre une session en mode console)
-
$ echo été | xxd
0000000: c3a9 74c3 a90a ..t...
-
Pas comme hier!
Le fichier a grossi!
Le vrai test :
if [[ é == ? ]]; then echo "é est un caractère"; fi
if [[ é == ?? ]]; then echo "é est 2 caractères"; fi
if [[ é == [é] ]]; then echo "é est un caractère"; fi
if [[ é == [[:alpha:]] ]]; then echo "é est alpha"; fi
-
Toujours pas d'UTF8. ;)
Ah bon ?
seb@raoul:~$ ./toto "aßbÑcýdÅeãfŮg" "*Å" | file -
/dev/stdin: UTF-8 Unicode text
-
Tu as testé en locale ISO-Latin-1?
-
Je ne vois pas ce que tu comptes montrer ainsi, mais ça me fait plaisir de te faire plaisir ... ;)
seb@titi:~$ locale -a
C
C.UTF-8
français
french
fr_FR
fr_FR@euro
fr_FR.iso88591
fr_FR.iso885915@euro
fr_FR.utf8
POSIX
seb@titi:~$ export LANG=fr_FR@euro
seb@titi:~$ locale
LANG=fr_FR@euro
LANGUAGE=
LC_CTYPE="fr_FR@euro"
LC_NUMERIC="fr_FR@euro"
LC_TIME="fr_FR@euro"
LC_COLLATE="fr_FR@euro"
LC_MONETARY="fr_FR@euro"
LC_MESSAGES="fr_FR@euro"
LC_PAPER="fr_FR@euro"
LC_NAME="fr_FR@euro"
LC_ADDRESS="fr_FR@euro"
LC_TELEPHONE="fr_FR@euro"
LC_MEASUREMENT="fr_FR@euro"
LC_IDENTIFICATION="fr_FR@euro"
LC_ALL=
seb@titi:~$ ./toto "aßbÑcýdÅeãf€g" "*Å"
Correspondance trouvée : "eãf€g"
seb@titi:~$ ./toto "aßbÑcýdÅeãf€g" "*Å" |file -
/dev/stdin: ISO-8859 text
Je t'ai fait du Latin-15 pour le même prix.
Et j'ai évidemment remplacé le caractère "Ů" initial par le caractère "€", puisque le premier ne fait pas partie du jeu de caractères ISO-8859-15.
Je ne dis pas ça, je dis que tes exemples ne démontrent rien du tout.
Il me semble tout de même que mes exemples montrent que bash n'est pas perturbé par les jeux de caractères utilisés (pour peu que le système soit correctement configuré, s'entend).
-
Je ne vois pas ce que tu comptes montrer ainsi, mais ça me fait plaisir de te faire plaisir ... ;)
Et je t'en remercie. :)
seb@titi:~$ locale -a
C
C.UTF-8
français
french
fr_FR
fr_FR@euro
fr_FR.iso88591
fr_FR.iso885915@euro
fr_FR.utf8
POSIX
seb@titi:~$ export LANG=fr_FR@euro
seb@titi:~$ locale
LANG=fr_FR@euro
LANGUAGE=
LC_CTYPE="fr_FR@euro"
LC_NUMERIC="fr_FR@euro"
LC_TIME="fr_FR@euro"
LC_COLLATE="fr_FR@euro"
LC_MONETARY="fr_FR@euro"
LC_MESSAGES="fr_FR@euro"
LC_PAPER="fr_FR@euro"
LC_NAME="fr_FR@euro"
LC_ADDRESS="fr_FR@euro"
LC_TELEPHONE="fr_FR@euro"
LC_MEASUREMENT="fr_FR@euro"
LC_IDENTIFICATION="fr_FR@euro"
LC_ALL=
seb@titi:~$ ./toto "aßbÑcýdÅeãf€g" "*Å"
Correspondance trouvée : "eãf€g"
seb@titi:~$ ./toto "aßbÑcýdÅeãf€g" "*Å" |file -
/dev/stdin: ISO-8859 text
Je t'ai fait du Latin-15 pour le même prix.
Et j'ai évidemment remplacé le caractère "Ů" initial par le caractère "€", puisque le premier ne fait pas partie du jeu de caractères ISO-8859-15.
Pardon, ce n'est pas du tout ce que je voulais dire.
Ce que je propose, ce de ne rien changer (sauf l’environnement), de rester en terminal UTF8, de garder la même séquence UTF8, de mentir au shell via LC_CTYPE (oui, cémal).
-
Bah si tu racontes volontairement des conneries au shell, il ne faut pas t'attendre à ce qu'il réagisse correctement.
L'émulateur Konsole depuis lequel je travaille est resté configuré en UTF-8 :
seb@titi:~$ zsh
seb@titi ~ % export LC_CTYPE=fr_FR@euro
seb@titi ~ % if [[ é == ? ]]; then echo "é est un caractère"; fi
seb@titi ~ % if [[ é == ?? ]]; then echo "é est 2 caractères"; fi
é est 2 caractères
seb@titi ~ % if [[ é == [é] ]]; then echo "é est un caractère"; fi
seb@titi ~ % if [[ é == [[:alpha:]] ]]; then echo "é est alpha"; fi
seb@titi ~ % echo été | xxd
0000000: c3a9 74c3 a90a ..t...
seb@titi ~ % cat test.utf8
aßbÑcýdÅeãfŮg
seb@titi ~ % cat test.latin15
a�b�c�d�e�f�g
Qu'est-ce qu'on en conclue ?
Que zsh ne gère correctement ni UTF-8, ni Latin15 ? ;)
Pour ma part, je considère qu'il y a juste une erreur dans l'interface chaise-clavier ...
-
Non!
On en conclut que
- zsh tient compte bien de l'environnement : $LC_CTYPE détermine bien le comportement de zsh
- qu'on pourrait conclure de ce test que zsh supporte réellement UTF8!
Tu viens de démontrer que le test que je propose est bon.
Est-ce que tes tests sont bons? Est-ce qu'ils montrent bien que $LC_CTYPE détermine le comportement de bash?
-
Est-ce que tes tests sont bons?
Exactement les mêmes résultats foireux pour bash dans les mêmes conditions :
seb@titi:~$ export LC_CTYPE=fr_FR@euro
seb@titi:~$ if [[ é == ? ]]; then echo "é est un caractère"; fi
seb@titi:~$ if [[ é == ?? ]]; then echo "é est 2 caractères"; fi
é est 2 caractères
seb@titi:~$ if [[ é == [é] ]]; then echo "é est un caractère"; fi
seb@titi:~$ if [[ é == [[:alpha:]] ]]; then echo "é est alpha"; fi
seb@titi:~$ echo été | xxd
0000000: c3a9 74c3 a90a ..t...
seb@titi:~$ cat test.utf8
aßbÑcýdÅeãfŮg
seb@titi:~$ cat test.latin15
a�b�c�d�e�f�g
Satisfait ?
-
Je suis satisfait que tu ai démontré la pertinence de mon test.
Je te rappelle que tes tests sont :
seb@raoul:~$ cat toto
#!/bin/bash
if [ $# -ne 2 ]
then
echo "Usage: $(basename $0) <chaine> <motif>"
echo ""
echo "Affiche la partie de chaîne située après le motif spécifié."
exit 1
fi
chaine="$1"
motif="$2"
apres=${chaine##${motif}}
if [ -z "$apres" ]
then
echo "Pas de correspondance."
else
echo "Correspondance trouvée : \"$apres\""
fi
Qui, à l'exécution, donne ceci :
seb@raoul:~$ ./toto "aßbÑcýdÅeãfŮg" "*Å"
Correspondance trouvée : "eãfŮg"
seb@nestor:~$ for f in /data/media/musique/flac/Sigur\ Rós/Með\ suð\ í\ eyrum\ við\ spilum\ endalaust/*.flac; do t=$(printf "%s\n" $f | file -); echo "$t - $(basename "$f")"; done
/dev/stdin: UTF-8 Unicode text - 01. Gobbledigook.flac
/dev/stdin: UTF-8 Unicode text - 02. Inní mér syngur vitleysingur.flac
/dev/stdin: UTF-8 Unicode text - 03. Góðan daginn.flac
/dev/stdin: UTF-8 Unicode text - 04. Við spilum endalaust.flac
/dev/stdin: UTF-8 Unicode text - 05. Festival.flac
/dev/stdin: UTF-8 Unicode text - 06. Með suð í eyrum.flac
/dev/stdin: UTF-8 Unicode text - 07. Ára bátur.flac
/dev/stdin: UTF-8 Unicode text - 08. Illgresi.flac
/dev/stdin: UTF-8 Unicode text - 09. Fljótavík.flac
/dev/stdin: UTF-8 Unicode text - 10. Straumnes.flac
/dev/stdin: UTF-8 Unicode text - 11. All Alright.flac
-
Je suis satisfait que tu ai démontré la pertinence de mon test.
C'est toi qui le trouve pertinent, pas moi.
Qu'est-ce que tu veux prouver?
On voit que bash ne se viande pas sur les octets dont le premier bit est à 1. Super. On ne s'en doutait pas.
On va donc pouvoir travailler sur des données en ISO-Latin-1 avec bash! 8)
Et toi, qu'est-ce que tu veux prouver ?
Tu dis au shell : "Hé, mec, on bosse avec des caractères codés sur un octet" et tu lui balances des caractères qui le sont sur deux octets ou plus.
Du coup, il croit voir passer deux caractères ou plus. Super. On ne s'en doutait pas.
-
C'est toi qui le trouve pertinent, pas moi.
Mon test ne passe pas. Le résultat du test dépend des paramètres. Mon test teste quelque chose.
Le test de mon test est donc concluant.
Mon test est pertinent par rapport à ce qu'il teste.
Et toi, qu'est-ce que tu veux prouver ?
Que tes tests ne marchent pas. Ils ne testent rien. Ils ne sont pas pertinents.
Essaie, pour voir.
Super. On ne s'en doutait pas.
C'est bien mon commentaire en voyant les résultats positifs de tes 2 tests.
-
Que tes tests ne marchent pas. Ils ne testent rien. Ils ne sont pas pertinents.
Je te laisse te tirer la nouille sur la théorie.
En pratique, j'ai basculé mon système en UTF8 en 2005, n'ai jamais utilisé que bash, et n'ai jamais eu de problème.
-
Je te laisse te tirer la nouille sur la théorie.
En pratique, tes tests ne démontrent rien, voilà. Ce n'est pas de "la théorie". Ce sont tes tests.
Autrement dit : tes tests sont du tirage de nouille improductif.
En pratique, j'ai basculé mon système en UTF8 en 2005, n'ai jamais utilisé que bash, et n'ai jamais eu de problème.
Le fait que tu n'ai pas eu de problème n'est pas un argument fort puisque ta as proposé des tests qui ne démontrent rien, ce qu'apparemment tu préfères ne pas tester par toi-même.
-
Je ne sais pas trop ce que vous racontez... Bahs gère Unicode (et donc UTF-8), c'est même indiqué dans la documentation...
Un man bash donne ceci :
...
Words of the form $'string' are treated specially. The word expands to string, with backslash-escaped characters replaced as specified by the ANSI C standard. Back-
slash escape sequences, if present, are decoded as follows:
\a alert (bell)
\b backspace
\e
\E an escape character
\f form feed
\n new line
\r carriage return
\t horizontal tab
\v vertical tab
\\ backslash
\' single quote
\" double quote
\nnn the eight-bit character whose value is the octal value nnn (one to three digits)
\xHH the eight-bit character whose value is the hexadecimal value HH (one or two hex digits)
\uHHHH the Unicode (ISO/IEC 10646) character whose value is the hexadecimal value HHHH (one to four hex digits)
\UHHHHHHHH
the Unicode (ISO/IEC 10646) character whose value is the hexadecimal value HHHHHHHH (one to eight hex digits)
\cx a control-x character
...
Edit: Et puis tenez, je vous propose aussi une méthode de test du tant qu'on y est.
var1="abcdef"
var2="àbcdéf"
echo ${#var1}
echo ${#var2}
Si les deux echo n'affichent pas 6 chacun mais respectivement 6 et 8, c'est qu'il y a vraisemblablement un soucis dans la gestion de l'utf-8.
(c'est un problème qu'on rencontrait il y a quelques années avec PHP5, et qui doit être encore présent j'imagine...)
-
En pratique, tes tests ne démontrent rien, voilà. Ce n'est pas de "la théorie". Ce sont tes tests.
Et les tiens n'ont fait que confirmer que les caractères Unicode sont codés sur plus d'un octet, et qu'un shell normalement constitué les interprète bien quand il est correctement configuré, et mal quand il ne l'est pas. La belle affaire.
Autrement dit : tes tests sont du tirage de nouille improductif.
Improductivité qui n'est liée qu'à ton entêtement à mettre en doute la parole des gens qui te disent que ça fonctionne pour eux.
Le fait que tu n'ai pas eu de problème n'est pas un argument fort puisque ta as proposé des tests qui ne démontrent rien, ce qu'apparemment tu préfères ne pas tester par toi-même.
Je ne suis pas ta chose, corrector, j'ai d'autres choses bien plus intéressantes à faire dans la vie que de te convaincre de choses que tu ne veux pas admettre.
La prochaine fois, tu te monteras une VM et tu nous apporteras la preuve de ce que tu annonces, parce que tout ceci est parti - je te le rappelle - du fait que tu as dénigré bash en affirmant qu'il ne supportait pas correctement Unicode.
-
seb@nestor:~$ for f in /data/media/musique/flac/Sigur\ Rós/Með\ suð\ í\ eyrum\ við\ spilum\ endalaust/*.flac; do t=$(printf "%s\n" $f | file -); echo "$t - $(basename "$f")"; done
The printf command (http://wiki.bash-hackers.org/commands/builtin/printf)
If more arguments than format specifiers are present, then the format string is re-used until the last argument is interpreted.
Donc si $f est composé de deux mots, la commande équivaut à printf "%s\n%s\n" $f
C'était le résultat voulu? ;)
-
Je ne sais pas trop ce que vous racontez... Bahs gère Unicode (et donc UTF-8), c'est même indiqué dans la documentation...
Un man bash donne ceci :
Je ne vois comment tu passes de "accepte les code-point Unicode en syntaxe C" à gère UTF8!
-
Et les tiens n'ont fait que confirmer que les caractères Unicode sont codés sur plus d'un octet, et qu'un shell normalement constitué les interprète bien quand il est correctement configuré, et mal quand il ne l'est pas. La belle affaire.
Voilà : mes tests fonctionnent.
Improductivité qui n'est liée qu'à ton entêtement à mettre en doute la parole des gens qui te disent que ça fonctionne pour eux.
N'importe quoi.
Je ne suis pas ta chose, corrector, j'ai d'autres choses bien plus intéressantes à faire dans la vie que de te convaincre de choses que tu ne veux pas admettre.
En clair, tu ne veux plus jouer.
Tu voulais jouer, mais tout d'un coup ça ne t'amuse plus du tout.
Bizarre.
Bien sûr, ce n'est pas lié au fait que tu as l'impression de perdre.
La prochaine fois, tu te monteras une VM et tu nous apporteras la preuve de ce que tu annonces,
J'ai amplement démontré ce que j'avance.
parce que tout ceci est parti - je te le rappelle - du fait que tu as dénigré bash en affirmant qu'il ne supportait pas correctement Unicode.
Tu tentes une feinte, pour impressionner le public.
La discussion du message 15 au 75 est uniquement liée à ton entêtement.
-
Je ne vois comment tu passes de "accepte les code-point Unicode en syntaxe C" à gère UTF8!
Et les points de code de 1 à 4 octets tu les encodes comment si ce n'est en UTF-8, ou ses cousins UTF-16 et UTF-32 ?
-
Mauvaise doc de bash, ou mauvaise foi de ta part ?
Le fait que bash supporte Unicode est acquis depuis sa version 2.05b, qui date de 2002.
Ce qui ne veut pas dire pour autant que les systèmes livrés par la suite intégraient tout le nécessaire pour gérer correctement les caractères Unicode, loin de là*.
Mais en quoi est-ce un problème de bash ?
Et qu'est-ce que tu attends comme documentation, au juste, si ce n'est la manière de traiter les caractères Unicode ?
Parce que sur ce point précis, il ne faut pas chercher bien loin :
seb@nestor:~$ man bash | grep -i unicode | head -1
\uHHHH le caractère Unicode (ISO/IEC 10646) dont la valeur hexadécimale est HHHH (un à quatre chiffres hexadécimaux) ;
Désolé, mais si la doc signifie que bash supporte UTF8, alors elle signifie aussi que les jeux de caractères plus petits ne sont plus supportés.
C'est clairement une interprétation délirante de la doc.
Donc, la doc ne dit rien sur le support des encodages Unicode.
Donc, la doc est insuffisante.
-
Et les points de code de 1 à 4 octets tu les encodes comment si ce n'est en UTF-8, ou ses cousins UTF-16 et UTF-32 ?
Tu veux donc dire qu'il faut nécessairement que bash travaille en UTF8 dès que la syntaxe Unicode du C est utilisée.
C'est arbitraire.
\u00xy se code très bien en iso-latin-1.
UTF-8, ou ses cousins UTF-16 et UTF-32 ?
Alors, bash utilise lequel des 3?
Comment le savoir à partir de cette doc?
-
Désolé, mais si la doc signifie que bash supporte UTF8, alors elle signifie aussi que les jeux de caractères plus petits ne sont plus supportés.
C'est clairement une interprétation délirante de la doc.
Donc, la doc ne dit rien sur le support des encodages Unicode.
Donc, la doc est insuffisante.
C'est votre interprétation qui parait délirante...
Voilà : mes tests fonctionnent.
Ne le prenez pas mal, mais je ne vois pas non plus en quoi ces tests fonctionnent.
Dans l'esprit ça me fait plus penser à ce que font certains charlatans qui essayent de démontrer que leur lessive est plus saine que la concurrente car elle ne rend pas l'eau trouble contrairement à celle du marché...
-
C'est votre interprétation qui parait délirante...
Non, c'est votre interprétation qui est délirante.
Parce que "mon interprétation" est précisèment la votre.
Ne le prenez pas mal, mais je ne vois pas non plus en quoi ces tests fonctionnent.
Dans l'esprit ça me fait plus penser à ce que font certains charlatans qui essayent de démontrer que leur lessive est plus saine que la concurrente car elle ne rend pas l'eau trouble contrairement à celle du marché...
Qu'appelez-vous un test qui "fonctionne"?
-
Je ne sais pas trop ce que vous racontez... Bahs gère Unicode (et donc UTF-8), c'est même indiqué dans la documentation...
Un man bash donne ceci :
\uHHHH the Unicode (ISO/IEC 10646) character whose value is the hexadecimal value HHHH (one to four hex digits)
\UHHHHHHHH
the Unicode (ISO/IEC 10646) character whose value is the hexadecimal value HHHHHHHH (one to eight hex digits)
Ce qui propose TOUT compilateur ISO C 90.
Et RIEN n'oblige un compilateur ISO C 90 à supporter plus que ASCII, ou même plus que EBCDIC.
-
Tu veux donc dire qu'il faut nécessairement que bash travaille en UTF8 dès que la syntaxe Unicode du C est utilisée.
C'est arbitraire.
\u00xy se code très bien en iso-latin-1.
Alors, bash utilise lequel des 3?
Comment le savoir à partir de cette doc?
Heureusement que l'on peut encore encoder des caractères de 1 octet en latin1. D'ailleurs sur les 7 premiers bits c'est commun à ASCII, que ce soit Latin1 ou UTF8 (enfin si je me souviens bien de mes cours d'architecture des ordinateurs)
Quant à l'encodage utilisé, ça dépend de comment est configuré l'environnement de vos locales...
La doc parle d'afficher des caractères jusqu'à 4 octets à partir de leur code en valeur hexadécimal... ce à quoi est dévoué UTF-8.
Puisque vous aimez les tests, je vous en ai proposé un aussi. Vous l'avez essayé ?
Sur ma machine qui est configurée en utf-8 aucun problème.
Sur un accès ssh de de ma fac configuré en latin9, il y a un problème au comptage. :)
Ce que j'en déduis : la moulinette qui a derrière cette commande interne au shell prend en compte de l'encodage défini dans l'environnement pour déterminer si un octet à lui seul défini un caractère, ou est juste un composé d'un groupe de 2 à 4 octets.
Et pour vous c'est quoi "gérer UTF-8" ?
-
Heureusement que l'on peut encore encoder des caractères de 1 octet en latin1. D'ailleurs sur les 7 premiers bits c'est commun à ASCII, que ce soit Latin1 ou UTF8 (enfin si je me souviens bien de mes cours d'architecture des ordinateurs)
Quant à l'encodage utilisé, ça dépend de comment est configuré l'environnement de vos locales...
Mais rien dans la doc citée ne dit qu'il y a une locale UTF8 supportée par le shell.
Et pour vous c'est quoi "gérer UTF-8" ?
À minima, c'est passer vos tests et les miens mentionnés dans ce topic :
if [[ é == ? ]]; then echo "é est un caractère"; fi
if [[ é == ?? ]]; then echo "é est 2 caractères"; fi
if [[ é == [é] ]]; then echo "é est un caractère"; fi
if [[ é == [[:alpha:]] ]]; then echo "é est alpha"; fi
var1="abcdef"
var2="àbcdéf"
echo ${#var1}
echo ${#var2}
Pour vraiment gérer UTF8 et Unicode, il faudrait :
- rejeter les séquences non valides
- gérer tous les cas correctement, y compris les combinants
ce qui est juste ... vraiment gore.
-
En clair, tu ne veux plus jouer.
Tu voulais jouer, mais tout d'un coup ça ne t'amuse plus du tout.
Bizarre.
Bien sûr, ce n'est pas lié au fait que tu as l'impression de perdre.
Je n'ai nullement l'impression de perdre, étant donné que j'ai déjà gagné :
On s'en fout, bash supporte UTF8, bravo.
Mais depuis que tu l'as admis, tu ne cherches plus à faire que de la rhétorique.
Et je sais pertinemment que quand tu te lances là dedans, il faut que tu aies le dernier mot, donc je laisse tomber.
Je vois que tu as trouvé un nouveau copain pour jouer, donc je ne devrai pas trop te manquer.
-
seb a perdu et il le sait.
Il est tout triste.
-
printf "%s\n" $f | file -
(...)
/dev/stdin: UTF-8 Unicode text
Je propose le test suivant pour cat :
echo "Inní mér syngur vitleysingur" | cat | file -
Conclusion : cat supporte UTF8!
-
- motif (Perl-style) :
([^?*]*)/([^/]+)
= chercher le dernier / et s'assurer qu'il n'y a pas de ? ni * avant
- (|([^.].*))\.flac autrement dit (\.flac)|([^.].*\.flac)
= le nom se termine par .flac et ne commence pas par . ou bien le nom est .flac
On voit plusieurs motifs (en gras) :
- un symbole ASCII isolé ou un texte ASCII
- "tous les caractères sauf ceux-ci" : [^.] et [^?*]
UTF8 a été conçu pour avoir ces propriétés :
- les caractères ASCII sont codés tels quels : donc l'ASCII est de l'UTF8
- un octet dont la valeur est celle d'un caractère ASCII code toujours le "code point" de ce caractère ASCII : dans un texte codé en UTF8, un octet codant la valeur ASCII d'un symbole / représente toujours ce symbole, un octet codant la valeur ASCII de a représente toujours le "code point" "a minuscule".
Donc l'automate reconnaissant le motif Unicode [^?*] en UTF8 est le même que l'automate reconnaissant ce même motif dans un "ASCII étendu" quelconque (codage de caractère un octet qui est un sur-ensemble de l'ASCII).
De même, le motif Unicode \.flac se compile en UTF8 de la même façon que le motif ASCII-étendu \.flac.
-
Et pour vous c'est quoi "gérer UTF-8" ?
Gérer correctement ce cas :
zsh: Completion should handle combining accents equivalents (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374913)
Package: zsh
Version: 4.3.2-12
Severity: minor
Hi,
If I create a directory named héhé (e with combining acute accent),
and then try to complete hé into it (here é is the precombined form),
libreadline does not take care that é (e with combining acute accent) is
equivalent to é (the precombined "e with acute accent" character).
libreadline should use some unicode normal form on completion.
Samuel
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (900, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Versions of packages zsh depends on:
ii debconf [debconf-2.0] 1.5.2 Debian configuration management sy
ii libc6 2.3.6-15 GNU C Library: Shared libraries
ii libncurses5 5.5-2 Shared libraries for terminal hand
Versions of packages zsh recommends:
ii libcap1 1:1.10-14 support for getting/setting POSIX.
ii libpcre3 6.4-2 Perl 5 Compatible Regular Expressi
-
UTF8 a été conçu pour avoir ces propriétés :
- les caractères ASCII sont codés tels quels : donc l'ASCII est de l'UTF8
- un octet dont la valeur est celle d'un caractère ASCII code toujours le "code point" de ce caractère ASCII : dans un texte codé en UTF8, un octet codant la valeur ASCII d'un symbole / représente toujours ce symbole, un octet codant la valeur ASCII de a représente toujours le "code point" "a minuscule".
Le "code point" mais pas forcèment le caractère!
Par exemple : la séquence de code point Unicode "e combining-acute-accent" signifie "é", donc en Unicode le motif "e" ne correspond pas au motif ASCII "e" et les automates ne sont pas les mêmes : le motif correspondant est :
e$|eNOT(COMBI)
où :
NOT(COMBI) = complèmentaire de COMBI
COMBI = motif qui reconnait tous les combining-diacritics.
En clair :
- il faut lire le caractère suivant et faire du backtracking, parce que celui qui a pondu ça est une andouille
- Unicode, c'est un cauchemar. :'(