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

0 Membres et 1 Invité sur ce sujet

seb

  • Pau Broadband Country (64)
  • Abonné SFR fibre FttH
  • *
  • Messages: 515
  • FTTH 1 Gbps sur Pau (64)
Éditer un fichier de config linux sans ligne de commande
« Réponse #72 le: 15 mai 2013 à 23:47:09 »
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.

corrector

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

EMegamanu

  • Abonné Orange Fibre
  • *
  • Messages: 416
  • FTTH sur Villeurbanne et Oullins (69)
Éditer un fichier de config linux sans ligne de commande
« Réponse #74 le: 15 mai 2013 à 23:55: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 :
Citer
...
 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...)

seb

  • Pau Broadband Country (64)
  • Abonné SFR fibre FttH
  • *
  • Messages: 515
  • FTTH 1 Gbps sur Pau (64)
Éditer un fichier de config linux sans ligne de commande
« Réponse #75 le: 16 mai 2013 à 00:12:17 »
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.

corrector

  • Invité
"Take care to avoid word splitting"
« Réponse #76 le: 16 mai 2013 à 00:15:40 »
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
Citer
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? ;)

corrector

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

corrector

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

EMegamanu

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

corrector

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

corrector

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

EMegamanu

  • Abonné Orange Fibre
  • *
  • Messages: 416
  • FTTH sur Villeurbanne et Oullins (69)
Éditer un fichier de config linux sans ligne de commande
« Réponse #82 le: 16 mai 2013 à 00:33:24 »
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é...

corrector

  • Invité
Éditer un fichier de config linux sans ligne de commande
« Réponse #83 le: 16 mai 2013 à 00:35:09 »
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"?