OVH Cloud OVH Cloud

codage d'accent dans un path

77 réponses
Avatar
filh
Bonjour,

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

10 réponses

4 5 6 7 8
Avatar
blanc
Paul Gaborit wrote:

Mais ce ne sont pas des caractères d'échappement... Ne serait-ce que
parce que leur influence à une portée longue (jusqu'à la rencontre de
l'apostrophe ou du guillemet fermant correspondant). En fait ce sont,
le plus souvent, des caractères de changement de contexte
lexicographique (comme les parenthèses ou les crochets).


Pour quelle raison un échappement ne serait-il qu'à portée courte ?


La encore, tu ne parles que de C, alors que je pensais plutôt à ce qui
se passe dans un shell.


Je ne parle pas que du C... je donne un exemple en C. Mais on pourrait
prendre des exemples comme cela dans tous les langages : C, Perl,
Pyton, Jav, Javascript, sh, csh, etc.

D'ailleurs on peut prendre le même exemple en shell (ici un tcsh) :

set prompt="%S%n-%m%s[%C02]n"


si tu veux


Si par exemple tu tapes la commande :

ls *.c>truc

la commande ls cherchera à lister tous les fichiers dont le nom se
termine par .c dans le répertoire courant, et le shell enverra cette
liste dans le répertoire truc, tandis que la commande :

ls *.c>truc

cherchera à lister un fichier ou répertoire dont le nom est exactement

*.c>truc

Et de la même façon, l'antislash neutralisera ou banalisera n'importe
quel caractère (y compris lui-même) de telle sorte qu'il ne sera pas
interprété par le shell.
C'est àmha exactement une banalisation.


Certes. Il se trouve qu'ici la caractère d'échappement a pour
influence de "neutraliser" la comportement du "joker" '*' ou du
caractère de redirection '>'. Mais c'est un cas particulier spécifique
au shell qui de plus n'entre pas en contradiction avec la notion de
caractère d'échappement. Mais, et c'est pour cela que je donnais un
exemple en C, la notion de caractère d'échappement est plus générale
et, souvent, n'a pas pour rôle de "neutraliser" le caractère qui suit
mais plutôt d'échapper à son rôle habituel.


Grosse différence entre "neutraliser la fonction habituelle" et
"échapper à son rôle habituel" ;-)

Bon. Sur ce, je préfère arrêter cette discussion que je n'aurai pas le
temps de prolonger et pour laquelle on ne va pas tarder de nous accuser
d'être hors charte.

Cordialement

JPaul.
--
/==/==- Jean-Paul BLANC
/ /--/--// quelque-part (somewhere)
|/| L | en (in)
/|| = ||| FRANCE


Avatar
Vincent Lefevre
Dans l'article <1hrshmj.pq262h6u94orN%,
Une Bévue écrit:

j'ai refais la manip :

mkdir éè/ôö



ls -al 'éè'
[...]
... o??o??


Le ls fourni avec Mac OS X est buggé (j'ai le même problème). Mais avec
le ls du port coreutils de MacPorts, aucun problème.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Avatar
unbewusst.sein
Vincent Lefevre <vincent+ wrote:

Le ls fourni avec Mac OS X est buggé (j'ai le même problème). Mais avec
le ls du port coreutils de MacPorts, aucun problème.


OK, merci pour l'info !
--
Artaban de Médée

Avatar
Eric Levenez
Le 14/01/07 1:21, dans <20070114001912$, « Vincent
Lefevre » <vincent+ a écrit :

Dans l'article <1hrshmj.pq262h6u94orN%,
Une Bévue écrit:

j'ai refais la manip :

mkdir éè/ôö



ls -al 'éè'
[...]
... o??o??


Le ls fourni avec Mac OS X est buggé (j'ai le même problème). Mais avec
le ls du port coreutils de MacPorts, aucun problème.


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.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.


Avatar
unbewusst.sein
Eric Levenez wrote:

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.


impeccable :

$ mkdir -p éè/ôö
$ ls -w éè
ôö

-w : Force raw printing of non-printable characters. This is the default
when output is not to a terminal.
--
Artaban de Médée

Avatar
laurent.pertois
Une Bévue wrote:

j'ai refais la manip :

mkdir éè/ôö


ls -al 'éè'
[...]
... o??o??


Dans les réglages de l'inspecteur de ta fenêtre de Terminal, tu es bien
en UTF-8 ? (Terminal, une fenêtre, pomme-i, Display)

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Avatar
unbewusst.sein
Laurent Pertois wrote:

Dans les réglages de l'inspecteur de ta fenêtre de Terminal, tu es bien
en UTF-8 ? (Terminal, une fenêtre, pomme-i, Display)


oui, oui, mais j'avais aussi :

Inspecteur de Terminal > Emulation > Eviter les caractères non-ASCII

ne change rien en basculant à faux...

par contre ls -w c'est OK j'ai bien les accents dans ce cas.
--
Artaban de Médée

Avatar
laurent.pertois
Une Bévue wrote:

par contre ls -w c'est OK j'ai bien les accents dans ce cas.


Voui, je connais (enfin, je connaissais le -v, en fait) mais ce que je
constate ici c'est ça :

[rdaneel:~/Desktop] [19:05:12] laurent$ mkdir -p éé/ùù
[rdaneel:~/Desktop] [19:05:27] laurent$ ls éé
ùù

Je suis avec le bash par défaut, j'ai ça aussi :

LC_TYPE=fr_FR.UTF-8
__CF_USER_TEXT_ENCODING=0x1F5:0:0

Pour le dernier, je ne sais pas si ça joue vraiment et le premier est
dans mon ~/.MacOSX/environment.plist

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Avatar
jperrocheau
Laurent Pertois wrote:

Une Bévue wrote:

par contre ls -w c'est OK j'ai bien les accents dans ce cas.


Voui, je connais (enfin, je connaissais le -v, en fait) mais ce que je
constate ici c'est ça :

[rdaneel:~/Desktop] [19:05:12] laurent$ mkdir -p éé/ùù
[rdaneel:~/Desktop] [19:05:27] laurent$ ls éé
ùù


Sans mettre de -v ou -w pour ls ?

Je suis avec le bash par défaut, j'ai ça aussi :

LC_TYPE=fr_FR.UTF-8
__CF_USER_TEXT_ENCODING=0x1F5:0:0

Pour le dernier, je ne sais pas si ça joue vraiment et le premier est
dans mon ~/.MacOSX/environment.plist


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).

J'ai bien aussi "__CF_USER_TEXT_ENCODING=0x1F5:0:0" dans mon "printenv",
mais je ne sais pas d'où il vient.


--
Jacques PERROCHEAU
________________________________________________________________________
e-mail: mailto:


Avatar
laurent.pertois
Jacques Perrocheau wrote:

[rdaneel:~/Desktop] [19:05:12] laurent$ mkdir -p éé/ùù
[rdaneel:~/Desktop] [19:05:27] laurent$ ls éé
ùù


Sans mettre de -v ou -w pour ls ?


Comme tu le vois.

Et pour préciser :

[rdaneel:~] [19:07:51] laurent$ which ls
/bin/ls

Je suis avec le bash par défaut, j'ai ça aussi :

LC_TYPE=fr_FR.UTF-8
__CF_USER_TEXT_ENCODING=0x1F5:0:0

Pour le dernier, je ne sais pas si ça joue vraiment et le premier est
dans mon ~/.MacOSX/environment.plist


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...

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.


4 5 6 7 8