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
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
Paul Gaborit <Paul.Gaborit@invalid.invalid> 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
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
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.
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
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.
Une Bévue <unbewusst.sein@google.com.invalid> 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.
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.
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
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.
Une Bévue <unbewusst.sein@google.com.invalid> 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 :
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.
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.
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 :
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:
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:jperrocheau@mac.com
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:
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.
Jacques Perrocheau <jperrocheau@mac.com.invalid> wrote:
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.
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.
