Auteur Sujet: Éditer un fichier de config linux sans ligne de commande  (Lu 13669 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Éditer un fichier de config linux sans ligne de commande
« Réponse #84 le: 16 mai 2013 à 00:40:30 »
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.

EMegamanu

  • Client Orange Fibre
  • *
  • Messages: 426
  • FTTH sur Villeurbanne et Oullins (69)
Éditer un fichier de config linux sans ligne de commande
« Réponse #85 le: 16 mai 2013 à 00:50:13 »
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" ?

corrector

  • Invité
Éditer un fichier de config linux sans ligne de commande
« Réponse #86 le: 16 mai 2013 à 01:23:49 »
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.

seb

  • Pau Broadband Country (64)
  • Client SFR fibre FTTH
  • *
  • Messages: 513
  • FTTH 100/50 Mbps sur Pau (64)
Éditer un fichier de config linux sans ligne de commande
« Réponse #87 le: 16 mai 2013 à 01:31:53 »
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.

corrector

  • Invité
Éditer un fichier de config linux sans ligne de commande
« Réponse #88 le: 16 mai 2013 à 01:36:58 »
seb a perdu et il le sait.

Il est tout triste.

corrector

  • Invité
cat supporte UTF8!
« Réponse #89 le: 17 mai 2013 à 06:14:41 »
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!

corrector

  • Invité
[^/] et UTF8
« Réponse #90 le: 17 mai 2013 à 09:26:01 »
  • 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.

corrector

  • Invité
c'est quoi "gérer UTF-8"
« Réponse #91 le: 17 mai 2013 à 10:15:06 »
Et pour vous c'est quoi "gérer UTF-8" ?
Gérer correctement ce cas :
zsh: Completion should handle combining accents equivalents

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

corrector

  • Invité
"Code point" vs. caractère
« Réponse #92 le: 17 mai 2013 à 10:26:01 »
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:'(

 

Mobile View