J'ai un pb alakon : je récupère un nom qui contient des accents en iso
latin, et je voudrais faire un fichier avec ce nom... il faut que je
recode en quoi pour que ça marche avec OSX ?
Apparament un é est codé avec e\341\201 (en octal) mais c'est quoi comme
codage ?
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
J'ai mis le premier "LC_TYPE=fr_FR.UTF-8" comme toi, cela ne change rien, il faut mettre -v ou -w pour afficher les caractères accentués (bash sous Mac OS X 10.4.8).
Bon, nous voilà face à un nouveau mystère...
bon moi aussi j'ai le "__CF_USER_TEXT_ENCODING=0x1F6:0:91" donc pas la même valeur que vous, je ne sais pas + que vous d'où ça vient...
par contre je n'ai pas : "LC_TYPE=fr_FR.UTF-8" mais : LC_CTYPE=fr_FR.UTF-8 et, franchement je ne me souviens plus pourquoi j'ai choisi cette forme, sans doute une directive pour compilo ???
donc j'ai ajouté :
export LC_TYPE=$LC_CTYPE
mais ça ne change rien, il faut bien le -w avec ls pour avoir les accents.
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls alors que mkdir roule tout seul avec les accents, sans doute qqc d'historique...
m'enfin ma recherche d'info sur ce sujet est purement "académique" vu que je n'utilise jamais les accents dans un nom de dossier|fichier... -- Artaban de Médée
J'ai mis le premier "LC_TYPE=fr_FR.UTF-8" comme toi, cela ne change
rien, il faut mettre -v ou -w pour afficher les caractères accentués
(bash sous Mac OS X 10.4.8).
Bon, nous voilà face à un nouveau mystère...
bon moi aussi j'ai le "__CF_USER_TEXT_ENCODING=0x1F6:0:91"
donc pas la même valeur que vous, je ne sais pas + que vous d'où ça
vient...
par contre je n'ai pas : "LC_TYPE=fr_FR.UTF-8" mais :
LC_CTYPE=fr_FR.UTF-8
et, franchement je ne me souviens plus pourquoi j'ai choisi cette forme,
sans doute une directive pour compilo ???
donc j'ai ajouté :
export LC_TYPE=$LC_CTYPE
mais ça ne change rien, il faut bien le -w avec ls pour avoir les
accents.
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls
alors que mkdir roule tout seul avec les accents, sans doute qqc
d'historique...
m'enfin ma recherche d'info sur ce sujet est purement "académique" vu
que je n'utilise jamais les accents dans un nom de dossier|fichier...
--
Artaban de Médée
J'ai mis le premier "LC_TYPE=fr_FR.UTF-8" comme toi, cela ne change rien, il faut mettre -v ou -w pour afficher les caractères accentués (bash sous Mac OS X 10.4.8).
Bon, nous voilà face à un nouveau mystère...
bon moi aussi j'ai le "__CF_USER_TEXT_ENCODING=0x1F6:0:91" donc pas la même valeur que vous, je ne sais pas + que vous d'où ça vient...
par contre je n'ai pas : "LC_TYPE=fr_FR.UTF-8" mais : LC_CTYPE=fr_FR.UTF-8 et, franchement je ne me souviens plus pourquoi j'ai choisi cette forme, sans doute une directive pour compilo ???
donc j'ai ajouté :
export LC_TYPE=$LC_CTYPE
mais ça ne change rien, il faut bien le -w avec ls pour avoir les accents.
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls alors que mkdir roule tout seul avec les accents, sans doute qqc d'historique...
m'enfin ma recherche d'info sur ce sujet est purement "académique" vu que je n'utilise jamais les accents dans un nom de dossier|fichier... -- Artaban de Médée
Eric Levenez
Le 15/01/07 9:04, dans <1hrz3aq.1e07nox1sf2ga7N%, « Une Bévue » a écrit :
mais ça ne change rien, il faut bien le -w avec ls pour avoir les accents.
Oui, bien sûr. Quelque soit l'encodage utilisé ou voulu, ls sans ce -w fait une interprétation.
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls alors que mkdir roule tout seul avec les accents, sans doute qqc d'historique...
Avant, le ls sortait en binaire par défaut, mais à cause de problème de terminaux (qui pouvait planter sur certains caractères), la sortie de ls a été filtrée. Il aurait fallu le faire pour TOUTES les commandes unix, ce qui aurait rendu inutilisable le système. Là le ls a sa fonction d'origine quand il n'est pas dans un shell interactif (genre "ls | cat"). C'est mieux que rien.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 15/01/07 9:04, dans
<1hrz3aq.1e07nox1sf2ga7N%unbewusst.sein@google.com.invalid>, « Une Bévue »
<unbewusst.sein@google.com.invalid> a écrit :
mais ça ne change rien, il faut bien le -w avec ls pour avoir les
accents.
Oui, bien sûr. Quelque soit l'encodage utilisé ou voulu, ls sans ce -w fait
une interprétation.
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls
alors que mkdir roule tout seul avec les accents, sans doute qqc
d'historique...
Avant, le ls sortait en binaire par défaut, mais à cause de problème de
terminaux (qui pouvait planter sur certains caractères), la sortie de ls a
été filtrée. Il aurait fallu le faire pour TOUTES les commandes unix, ce qui
aurait rendu inutilisable le système. Là le ls a sa fonction d'origine quand
il n'est pas dans un shell interactif (genre "ls | cat"). C'est mieux que
rien.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 15/01/07 9:04, dans <1hrz3aq.1e07nox1sf2ga7N%, « Une Bévue » a écrit :
mais ça ne change rien, il faut bien le -w avec ls pour avoir les accents.
Oui, bien sûr. Quelque soit l'encodage utilisé ou voulu, ls sans ce -w fait une interprétation.
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls alors que mkdir roule tout seul avec les accents, sans doute qqc d'historique...
Avant, le ls sortait en binaire par défaut, mais à cause de problème de terminaux (qui pouvait planter sur certains caractères), la sortie de ls a été filtrée. Il aurait fallu le faire pour TOUTES les commandes unix, ce qui aurait rendu inutilisable le système. Là le ls a sa fonction d'origine quand il n'est pas dans un shell interactif (genre "ls | cat"). C'est mieux que rien.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <C1CFAB6F.9AC98%, Eric Levenez écrit:
Le ls de Mac OS X n'est pas buggé. Je n'ai pas suivi la discussion, mais je pense que vous oubliez simplement de mettre l'option -w.
Les caractères en question sont imprimables, donc l'option -w devrait être inutile. Le ls est tout de même buggé pour cette raison (mais le bug est au niveau de la détection des caractères imprimables).
Dans l'article <C1CFAB6F.9AC98%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le ls de Mac OS X n'est pas buggé. Je n'ai pas suivi la discussion,
mais je pense que vous oubliez simplement de mettre l'option -w.
Les caractères en question sont imprimables, donc l'option -w devrait
être inutile. Le ls est tout de même buggé pour cette raison (mais le
bug est au niveau de la détection des caractères imprimables).
Dans l'article <C1CFAB6F.9AC98%, Eric Levenez écrit:
Le ls de Mac OS X n'est pas buggé. Je n'ai pas suivi la discussion, mais je pense que vous oubliez simplement de mettre l'option -w.
Les caractères en question sont imprimables, donc l'option -w devrait être inutile. Le ls est tout de même buggé pour cette raison (mais le bug est au niveau de la détection des caractères imprimables).
Dans l'article <C1D12A60.9AEBE%, Eric Levenez écrit:
Le 15/01/07 9:04, dans <1hrz3aq.1e07nox1sf2ga7N%, « Une Bévue » a écrit :
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls alors que mkdir roule tout seul avec les accents, sans doute qqc d'historique...
mkdir n'affiche rien, contrairement à ls.
Avant, le ls sortait en binaire par défaut, mais à cause de problème de terminaux (qui pouvait planter sur certains caractères),
Ils ne devraient pas planter. En revanche, ils peuvent se retrouver dans un état qui nécessiterait un reset pour pouvoir les utiliser de nouveau. Il peuvent même provoquer une impression (ça m'est arrivé, mais pas avec ls[*]).
la sortie de ls a été filtrée. Il aurait fallu le faire pour TOUTES les commandes unix, ce qui aurait rendu inutilisable le système. Là le ls a sa fonction d'origine quand il n'est pas dans un shell interactif (genre "ls | cat"). C'est mieux que rien.
Mais ça veut aussi dire que l'option -w est dangereuse quand la sortie se fait sur un terminal. Mieux vaut utiliser le ls des coreutils, qui sait mieux reconnaître les caractères imprimables.
Dans l'article <C1D12A60.9AEBE%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le 15/01/07 9:04, dans
<1hrz3aq.1e07nox1sf2ga7N%unbewusst.sein@google.com.invalid>, « Une Bévue »
<unbewusst.sein@google.com.invalid> a écrit :
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls
alors que mkdir roule tout seul avec les accents, sans doute qqc
d'historique...
mkdir n'affiche rien, contrairement à ls.
Avant, le ls sortait en binaire par défaut, mais à cause de problème de
terminaux (qui pouvait planter sur certains caractères),
Ils ne devraient pas planter. En revanche, ils peuvent se retrouver dans
un état qui nécessiterait un reset pour pouvoir les utiliser de nouveau.
Il peuvent même provoquer une impression (ça m'est arrivé, mais pas avec
ls[*]).
la sortie de ls a été filtrée. Il aurait fallu le faire pour TOUTES
les commandes unix, ce qui aurait rendu inutilisable le système. Là
le ls a sa fonction d'origine quand il n'est pas dans un shell
interactif (genre "ls | cat"). C'est mieux que rien.
Mais ça veut aussi dire que l'option -w est dangereuse quand la sortie
se fait sur un terminal. Mieux vaut utiliser le ls des coreutils, qui
sait mieux reconnaître les caractères imprimables.
Dans l'article <C1D12A60.9AEBE%, Eric Levenez écrit:
Le 15/01/07 9:04, dans <1hrz3aq.1e07nox1sf2ga7N%, « Une Bévue » a écrit :
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls alors que mkdir roule tout seul avec les accents, sans doute qqc d'historique...
mkdir n'affiche rien, contrairement à ls.
Avant, le ls sortait en binaire par défaut, mais à cause de problème de terminaux (qui pouvait planter sur certains caractères),
Ils ne devraient pas planter. En revanche, ils peuvent se retrouver dans un état qui nécessiterait un reset pour pouvoir les utiliser de nouveau. Il peuvent même provoquer une impression (ça m'est arrivé, mais pas avec ls[*]).
la sortie de ls a été filtrée. Il aurait fallu le faire pour TOUTES les commandes unix, ce qui aurait rendu inutilisable le système. Là le ls a sa fonction d'origine quand il n'est pas dans un shell interactif (genre "ls | cat"). C'est mieux que rien.
Mais ça veut aussi dire que l'option -w est dangereuse quand la sortie se fait sur un terminal. Mieux vaut utiliser le ls des coreutils, qui sait mieux reconnaître les caractères imprimables.
Le 16/01/07 4:06, dans <20070116023617$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C1D12A60.9AEBE%, Eric Levenez écrit:
Le 15/01/07 9:04, dans <1hrz3aq.1e07nox1sf2ga7N%, « Une Bévue » a écrit :
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls alors que mkdir roule tout seul avec les accents, sans doute qqc d'historique...
mkdir n'affiche rien, contrairement à ls.
Effectivement ce n'est pas un bon exemple, mais mkdir affiche quand même le nom des fichiers. Pour cela i suffit de le lancer 2 fois avec les mêmes paramètres : la seconde fois ce sera une erreur avec le nom du fichier brut.
Avant, le ls sortait en binaire par défaut, mais à cause de problème de terminaux (qui pouvait planter sur certains caractères),
Ils ne devraient pas planter.
Bien sûr. Aucun programme ou équipement ne devrait planter.
la sortie de ls a été filtrée. Il aurait fallu le faire pour TOUTES les commandes unix, ce qui aurait rendu inutilisable le système. Là le ls a sa fonction d'origine quand il n'est pas dans un shell interactif (genre "ls | cat"). C'est mieux que rien.
Mais ça veut aussi dire que l'option -w est dangereuse quand la sortie se fait sur un terminal.
Tout est potentiellement dangereux. L'option -w ne l'est pas si l'on reste sur HFS+ avec un shell UTF-8. C'est l'option par défaut chez moi. Sur Linux ou un autre système, cela est différent à cause de l'encodage des caractères dans le filesystem.
Mieux vaut utiliser le ls des coreutils, qui sait mieux reconnaître les caractères imprimables.
Je préfère utiliser ce qui est en standard et qui marche très bien.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 16/01/07 4:06, dans <20070116023617$61c0@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C1D12A60.9AEBE%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le 15/01/07 9:04, dans
<1hrz3aq.1e07nox1sf2ga7N%unbewusst.sein@google.com.invalid>, « Une Bévue »
<unbewusst.sein@google.com.invalid> a écrit :
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls
alors que mkdir roule tout seul avec les accents, sans doute qqc
d'historique...
mkdir n'affiche rien, contrairement à ls.
Effectivement ce n'est pas un bon exemple, mais mkdir affiche quand même le
nom des fichiers. Pour cela i suffit de le lancer 2 fois avec les mêmes
paramètres : la seconde fois ce sera une erreur avec le nom du fichier brut.
Avant, le ls sortait en binaire par défaut, mais à cause de problème de
terminaux (qui pouvait planter sur certains caractères),
Ils ne devraient pas planter.
Bien sûr. Aucun programme ou équipement ne devrait planter.
la sortie de ls a été filtrée. Il aurait fallu le faire pour TOUTES
les commandes unix, ce qui aurait rendu inutilisable le système. Là
le ls a sa fonction d'origine quand il n'est pas dans un shell
interactif (genre "ls | cat"). C'est mieux que rien.
Mais ça veut aussi dire que l'option -w est dangereuse quand la sortie
se fait sur un terminal.
Tout est potentiellement dangereux. L'option -w ne l'est pas si l'on reste
sur HFS+ avec un shell UTF-8. C'est l'option par défaut chez moi. Sur Linux
ou un autre système, cela est différent à cause de l'encodage des caractères
dans le filesystem.
Mieux vaut utiliser le ls des coreutils, qui
sait mieux reconnaître les caractères imprimables.
Je préfère utiliser ce qui est en standard et qui marche très bien.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 16/01/07 4:06, dans <20070116023617$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C1D12A60.9AEBE%, Eric Levenez écrit:
Le 15/01/07 9:04, dans <1hrz3aq.1e07nox1sf2ga7N%, « Une Bévue » a écrit :
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls alors que mkdir roule tout seul avec les accents, sans doute qqc d'historique...
mkdir n'affiche rien, contrairement à ls.
Effectivement ce n'est pas un bon exemple, mais mkdir affiche quand même le nom des fichiers. Pour cela i suffit de le lancer 2 fois avec les mêmes paramètres : la seconde fois ce sera une erreur avec le nom du fichier brut.
Avant, le ls sortait en binaire par défaut, mais à cause de problème de terminaux (qui pouvait planter sur certains caractères),
Ils ne devraient pas planter.
Bien sûr. Aucun programme ou équipement ne devrait planter.
la sortie de ls a été filtrée. Il aurait fallu le faire pour TOUTES les commandes unix, ce qui aurait rendu inutilisable le système. Là le ls a sa fonction d'origine quand il n'est pas dans un shell interactif (genre "ls | cat"). C'est mieux que rien.
Mais ça veut aussi dire que l'option -w est dangereuse quand la sortie se fait sur un terminal.
Tout est potentiellement dangereux. L'option -w ne l'est pas si l'on reste sur HFS+ avec un shell UTF-8. C'est l'option par défaut chez moi. Sur Linux ou un autre système, cela est différent à cause de l'encodage des caractères dans le filesystem.
Mieux vaut utiliser le ls des coreutils, qui sait mieux reconnaître les caractères imprimables.
Je préfère utiliser ce qui est en standard et qui marche très bien.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
unbewusst.sein
Eric Levenez wrote:
Là le ls a sa fonction d'origine quand il n'est pas dans un shell interactif (genre "ls | cat"). C'est mieux que rien.
ah oui mais c'est bien sûr, quand on pipe la sortie n'étant pas le term on est en bin.
j'ai bien :
$ ls éè | cat ôö
(après un mkdir -p éè/ôö)
merci pour cette précision ! -- Artaban de Médée
Eric Levenez <news@levenez.com> wrote:
Là le ls a sa fonction d'origine quand
il n'est pas dans un shell interactif (genre "ls | cat"). C'est mieux que
rien.
ah oui mais c'est bien sûr, quand on pipe la sortie n'étant pas le term
on est en bin.
Là le ls a sa fonction d'origine quand il n'est pas dans un shell interactif (genre "ls | cat"). C'est mieux que rien.
ah oui mais c'est bien sûr, quand on pipe la sortie n'étant pas le term on est en bin.
j'ai bien :
$ ls éè | cat ôö
(après un mkdir -p éè/ôö)
merci pour cette précision ! -- Artaban de Médée
Vincent Lefevre
Dans l'article <C1D22EBD.9B062%, Eric Levenez écrit:
Le 16/01/07 4:06, dans <20070116023617$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C1D12A60.9AEBE%, Eric Levenez écrit:
Le 15/01/07 9:04, dans <1hrz3aq.1e07nox1sf2ga7N%, « Une Bévue » a écrit :
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls alors que mkdir roule tout seul avec les accents, sans doute qqc d'historique...
mkdir n'affiche rien, contrairement à ls.
Effectivement ce n'est pas un bon exemple, mais mkdir affiche quand même le nom des fichiers. Pour cela i suffit de le lancer 2 fois avec les mêmes paramètres : la seconde fois ce sera une erreur avec le nom du fichier brut.
Disons que c'est un problème lié à l'affichage uniquement. Mais ce qui est création/ouverture du fichier ne pose aucun problème.
Mais ça veut aussi dire que l'option -w est dangereuse quand la sortie se fait sur un terminal.
Tout est potentiellement dangereux. L'option -w ne l'est pas si l'on reste sur HFS+ avec un shell UTF-8.
Si, si, elle est potientiellement dangereuse même sur HFS+ en UTF-8. N'oublie pas que les séquences d'échappement, c'est de l'ASCII en général. Essaie ceci:
Dans l'article <C1D22EBD.9B062%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le 16/01/07 4:06, dans <20070116023617$61c0@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C1D12A60.9AEBE%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le 15/01/07 9:04, dans
<1hrz3aq.1e07nox1sf2ga7N%unbewusst.sein@google.com.invalid>, « Une Bévue »
<unbewusst.sein@google.com.invalid> a écrit :
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls
alors que mkdir roule tout seul avec les accents, sans doute qqc
d'historique...
mkdir n'affiche rien, contrairement à ls.
Effectivement ce n'est pas un bon exemple, mais mkdir affiche quand
même le nom des fichiers. Pour cela i suffit de le lancer 2 fois
avec les mêmes paramètres : la seconde fois ce sera une erreur avec
le nom du fichier brut.
Disons que c'est un problème lié à l'affichage uniquement. Mais ce qui
est création/ouverture du fichier ne pose aucun problème.
Mais ça veut aussi dire que l'option -w est dangereuse quand la sortie
se fait sur un terminal.
Tout est potentiellement dangereux. L'option -w ne l'est pas si l'on
reste sur HFS+ avec un shell UTF-8.
Si, si, elle est potientiellement dangereuse même sur HFS+ en UTF-8.
N'oublie pas que les séquences d'échappement, c'est de l'ASCII en
général. Essaie ceci:
Dans l'article <C1D22EBD.9B062%, Eric Levenez écrit:
Le 16/01/07 4:06, dans <20070116023617$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C1D12A60.9AEBE%, Eric Levenez écrit:
Le 15/01/07 9:04, dans <1hrz3aq.1e07nox1sf2ga7N%, « Une Bévue » a écrit :
je trouve tout de même "bizarre" qu'il ait été choisi ce -w pour ls alors que mkdir roule tout seul avec les accents, sans doute qqc d'historique...
mkdir n'affiche rien, contrairement à ls.
Effectivement ce n'est pas un bon exemple, mais mkdir affiche quand même le nom des fichiers. Pour cela i suffit de le lancer 2 fois avec les mêmes paramètres : la seconde fois ce sera une erreur avec le nom du fichier brut.
Disons que c'est un problème lié à l'affichage uniquement. Mais ce qui est création/ouverture du fichier ne pose aucun problème.
Mais ça veut aussi dire que l'option -w est dangereuse quand la sortie se fait sur un terminal.
Tout est potentiellement dangereux. L'option -w ne l'est pas si l'on reste sur HFS+ avec un shell UTF-8.
Si, si, elle est potientiellement dangereuse même sur HFS+ en UTF-8. N'oublie pas que les séquences d'échappement, c'est de l'ASCII en général. Essaie ceci:
