OpenOffice et noms de fichiers avec caractere non ASCII

Vincent Lefevre

04/03/2007 à 22:47

Dans l'article <1hugrdf.11now6hxyvpayN%,
JPaul écrit:

Non. Je suis encore à la 2.0.4 récupérée il me semble aussi sur le site
officiel. Je vais mettre à jour et refaire le test.

J'avais le même problème avec les 2.0.x.

J'ai également le problème en tapant dans un shell UTF-8:

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice é.odt

(où le é est en NFC) et avec:

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice *.odt

(le *.odt est remplacé par é.odt avec un é en NFD). Dans les deux
cas, l'erreur indique que la chaîne UTF-8 est interprétée comme de
l'ISO-8859-1.

Mais si je lance

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice é.odt

dans un shell en ISO-8859-1 (donc avec un é encodé en ISO-8859-1),
alors là, le fichier est bien ouvert (alors qu'il ne devrait pas
l'être).

D'autre part, quand je lance une des commandes ci-dessus, j'obtiens
à chaque fois:

I18N: Operating system doesn't support locale ""

C'est bizarre. Et setlocale (LC_ALL, "") fonctionne bien sur ma machine.

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

blanc

05/03/2007 à 08:13

Vincent Lefevre <vincent+ wrote:

J'ai également le problème en tapant dans un shell UTF-8:

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/
soffice é.odt

ton DISPLAY=:0 me laisse penser que le Mac n'est pas la machine locale.
Quel type de machine as-tu en local, et quel type d'émulateur de
terminal utilises-tu ?

(où le é est en NFC) et avec:

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/
soffice *.odt

(le *.odt est remplacé par é.odt avec un é en NFD).

Que veux-tu dire par NFC et NFD ?

Dans les deux
cas, l'erreur indique que la chaîne UTF-8 est interprétée comme de
l'ISO-8859-1.

Mais si je lance

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/
soffice é.odt

dans un shell en ISO-8859-1

Comment changes-tu le charset de ton shell ?
et de quel shell s'agit-il ?

As-tu essayé de changer le charset du Terminal proprement dit dans
Terminal --> Réglages de la fenêtre --> Affichage --> Encodage...

(donc avec un é encodé en ISO-8859-1),
alors là, le fichier est bien ouvert (alors qu'il ne devrait pas
l'être).

D'autre part, quand je lance une des commandes ci-dessus, j'obtiens
à chaque fois:

I18N: Operating system doesn't support locale ""

C'est bizarre. Et setlocale (LC_ALL, "") fonctionne bien sur ma machine.

Amha ton problème vient du fait que tu n'es pas en local sur le mac, et
qu'il y a une mauvaise transcription de charset entre ta machine locale
et le mac. Les réponses aux diverses questions que je pose devraient,
j'espère, nous permettre de cerner davantage le pb et donc de
progresser.

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

Vincent Lefevre

06/03/2007 à 04:07

Dans l'article <1huhsd2.1f0i17c1k01evoN%,
JPaul écrit:

Vincent Lefevre <vincent+ wrote:

J'ai également le problème en tapant dans un shell UTF-8:

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/
soffice é.odt

ton DISPLAY=:0 me laisse penser que le Mac n'est pas la machine locale.

Au contraire, un DISPLAY=:0 indique quasiment toujours la machine locale.
Si c'était distant, cela aurait été quelque chose du style DISPLAY=:10
(pour du X forwarding avec SSH).

Quel type de machine as-tu en local, et quel type d'émulateur de
terminal utilises-tu ?

Parfois iTerm, parfois (u)xterm. Dans iTerm, la variable DISPLAY n'est
pas définie. Donc j'ai l'habitude de le préciser. Il faudrait d'ailleurs
que je mette à jour mes scripts pour que la valeur de DISPLAY soit
changée automatiquement dans mes shells lorsque je lance ou quitte le
serveur X.

(où le é est en NFC) et avec:

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/
soffice *.odt

(le *.odt est remplacé par é.odt avec un é en NFD).

Que veux-tu dire par NFC et NFD ?

L'URL suivante <http://unicode.org/reports/tr15/> a été citée dans
l'enfilade "Question shell, bash vs tcsh". Cela indique les deux
façons d'écrire le "é" en Unicode (Mac OS X étant généralement
capable de faire la conversion adéquate pour utiliser le NFD de
HFS+).

Comment changes-tu le charset de ton shell ?

Par mon .zshenv (l'algo est en gros: si charset actuel = ASCII, alors
on change en ISO-8859-1, sinon on le laisse tel quel).

et de quel shell s'agit-il ?

zsh

As-tu essayé de changer le charset du Terminal proprement dit dans
Terminal --> Réglages de la fenêtre --> Affichage --> Encodage...

Le charset du terminal est ISO-8859-1 pour iTerm (il doit correspondre
à LC_CTYPE, sinon ça pose évidemment des problèmes). Donc dans mes
sessions iTerm, j'ai toujours du ISO-8859-1 (bon, sauf parfois à
l'intérieur de sessions screen où il m'arrive d'avoir de l'UTF-8, mais
c'est screen qui s'occupe de la conversion pour l'affichage dans le
terminal, et je n'ai jamais eu de problème avec). Dans (u)xterm, il
est également toujours à la bonne valeur (mon algo est compatible avec
ce que fait xterm).

Et puis de toute façon, OpenOffice ne s'occupe pas du terminal
(d'ailleurs il peut être lancé via les menus). Donc même avec un
terminal mal configuré, OpenOffice devrait fonctionner correctement
tant que le nom du fichier est écrit en UTF-8. Ici, c'est l'inverse
qui se produit: OpenOffice n'accepte que les noms de fichiers écrits
en ISO-8859-1, même lorsqu'il est lancé avec des locales UTF-8.

Amha ton problème vient du fait que tu n'es pas en local sur le mac, et
qu'il y a une mauvaise transcription de charset entre ta machine locale
et le mac. Les réponses aux diverses questions que je pose devraient,
j'espère, nous permettre de cerner davantage le pb et donc de
progresser.

Si, je suis en local.

Autre précision: ceci fonctionne bien:

prunille:~> cat > é.sh
echo OK
sleep 10
prunille:~> chmod 755 é.sh
prunille:~> xterm -e é.sh

(où tous les "é" sont écrits en NFC). Mais

prunille:~> /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice é.sh

me dit que le fichier n'existe pas.

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

Dans l'article <1huhsd2.1f0i17c1k01evoN%blanc@empty.org>,
JPaul <blanc@empty.org> écrit:

Vincent Lefevre <vincent+news@vinc17.org> wrote:

J'ai également le problème en tapant dans un shell UTF-8:

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/
soffice é.odt

ton DISPLAY=:0 me laisse penser que le Mac n'est pas la machine locale.

Au contraire, un DISPLAY=:0 indique quasiment toujours la machine locale.
Si c'était distant, cela aurait été quelque chose du style DISPLAY=:10
(pour du X forwarding avec SSH).

Quel type de machine as-tu en local, et quel type d'émulateur de
terminal utilises-tu ?

Parfois iTerm, parfois (u)xterm. Dans iTerm, la variable DISPLAY n'est
pas définie. Donc j'ai l'habitude de le préciser. Il faudrait d'ailleurs
que je mette à jour mes scripts pour que la valeur de DISPLAY soit
changée automatiquement dans mes shells lorsque je lance ou quitte le
serveur X.

(où le é est en NFC) et avec:

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/
soffice *.odt

(le *.odt est remplacé par é.odt avec un é en NFD).

Que veux-tu dire par NFC et NFD ?

L'URL suivante <http://unicode.org/reports/tr15/> a été citée dans
l'enfilade "Question shell, bash vs tcsh". Cela indique les deux
façons d'écrire le "é" en Unicode (Mac OS X étant généralement
capable de faire la conversion adéquate pour utiliser le NFD de
HFS+).

Comment changes-tu le charset de ton shell ?

Par mon .zshenv (l'algo est en gros: si charset actuel = ASCII, alors
on change en ISO-8859-1, sinon on le laisse tel quel).

et de quel shell s'agit-il ?

zsh

As-tu essayé de changer le charset du Terminal proprement dit dans
Terminal --> Réglages de la fenêtre --> Affichage --> Encodage...

Le charset du terminal est ISO-8859-1 pour iTerm (il doit correspondre
à LC_CTYPE, sinon ça pose évidemment des problèmes). Donc dans mes
sessions iTerm, j'ai toujours du ISO-8859-1 (bon, sauf parfois à
l'intérieur de sessions screen où il m'arrive d'avoir de l'UTF-8, mais
c'est screen qui s'occupe de la conversion pour l'affichage dans le
terminal, et je n'ai jamais eu de problème avec). Dans (u)xterm, il
est également toujours à la bonne valeur (mon algo est compatible avec
ce que fait xterm).

Et puis de toute façon, OpenOffice ne s'occupe pas du terminal
(d'ailleurs il peut être lancé via les menus). Donc même avec un
terminal mal configuré, OpenOffice devrait fonctionner correctement
tant que le nom du fichier est écrit en UTF-8. Ici, c'est l'inverse
qui se produit: OpenOffice n'accepte que les noms de fichiers écrits
en ISO-8859-1, même lorsqu'il est lancé avec des locales UTF-8.

Amha ton problème vient du fait que tu n'es pas en local sur le mac, et
qu'il y a une mauvaise transcription de charset entre ta machine locale
et le mac. Les réponses aux diverses questions que je pose devraient,
j'espère, nous permettre de cerner davantage le pb et donc de
progresser.

Si, je suis en local.

Autre précision: ceci fonctionne bien:

prunille:~> cat > é.sh
echo OK
sleep 10
prunille:~> chmod 755 é.sh
prunille:~> xterm -e é.sh

(où tous les "é" sont écrits en NFC). Mais

prunille:~> /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice é.sh

me dit que le fichier n'existe pas.

--
Vincent Lefèvre <vincent@vinc17.org> - 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)

Vous avez filtré cet utilisateur ! Consultez son message

Dans l'article <1huhsd2.1f0i17c1k01evoN%,
JPaul écrit:

Vincent Lefevre <vincent+ wrote:

J'ai également le problème en tapant dans un shell UTF-8:

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/
soffice é.odt

ton DISPLAY=:0 me laisse penser que le Mac n'est pas la machine locale.

Au contraire, un DISPLAY=:0 indique quasiment toujours la machine locale.
Si c'était distant, cela aurait été quelque chose du style DISPLAY=:10
(pour du X forwarding avec SSH).

Quel type de machine as-tu en local, et quel type d'émulateur de
terminal utilises-tu ?

Parfois iTerm, parfois (u)xterm. Dans iTerm, la variable DISPLAY n'est
pas définie. Donc j'ai l'habitude de le préciser. Il faudrait d'ailleurs
que je mette à jour mes scripts pour que la valeur de DISPLAY soit
changée automatiquement dans mes shells lorsque je lance ou quitte le
serveur X.

(où le é est en NFC) et avec:

DISPLAY=:0 /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/
soffice *.odt

(le *.odt est remplacé par é.odt avec un é en NFD).

Que veux-tu dire par NFC et NFD ?

L'URL suivante <http://unicode.org/reports/tr15/> a été citée dans
l'enfilade "Question shell, bash vs tcsh". Cela indique les deux
façons d'écrire le "é" en Unicode (Mac OS X étant généralement
capable de faire la conversion adéquate pour utiliser le NFD de
HFS+).

Comment changes-tu le charset de ton shell ?

Par mon .zshenv (l'algo est en gros: si charset actuel = ASCII, alors
on change en ISO-8859-1, sinon on le laisse tel quel).

et de quel shell s'agit-il ?

zsh

As-tu essayé de changer le charset du Terminal proprement dit dans
Terminal --> Réglages de la fenêtre --> Affichage --> Encodage...

Le charset du terminal est ISO-8859-1 pour iTerm (il doit correspondre
à LC_CTYPE, sinon ça pose évidemment des problèmes). Donc dans mes
sessions iTerm, j'ai toujours du ISO-8859-1 (bon, sauf parfois à
l'intérieur de sessions screen où il m'arrive d'avoir de l'UTF-8, mais
c'est screen qui s'occupe de la conversion pour l'affichage dans le
terminal, et je n'ai jamais eu de problème avec). Dans (u)xterm, il
est également toujours à la bonne valeur (mon algo est compatible avec
ce que fait xterm).

Et puis de toute façon, OpenOffice ne s'occupe pas du terminal
(d'ailleurs il peut être lancé via les menus). Donc même avec un
terminal mal configuré, OpenOffice devrait fonctionner correctement
tant que le nom du fichier est écrit en UTF-8. Ici, c'est l'inverse
qui se produit: OpenOffice n'accepte que les noms de fichiers écrits
en ISO-8859-1, même lorsqu'il est lancé avec des locales UTF-8.

Amha ton problème vient du fait que tu n'es pas en local sur le mac, et
qu'il y a une mauvaise transcription de charset entre ta machine locale
et le mac. Les réponses aux diverses questions que je pose devraient,
j'espère, nous permettre de cerner davantage le pb et donc de
progresser.

Si, je suis en local.

Autre précision: ceci fonctionne bien:

prunille:~> cat > é.sh
echo OK
sleep 10
prunille:~> chmod 755 é.sh
prunille:~> xterm -e é.sh

(où tous les "é" sont écrits en NFC). Mais

prunille:~> /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice é.sh

me dit que le fichier n'existe pas.

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

blanc

06/03/2007 à 19:16

Vincent Lefevre <vincent+ wrote:

Dans l'article <1huhsd2.1f0i17c1k01evoN%,
JPaul écrit:

ton DISPLAY=:0 me laisse penser que le Mac n'est pas la machine locale.

Au contraire, un DISPLAY=:0 indique quasiment toujours la machine locale.
Si c'était distant, cela aurait été quelque chose du style DISPLAY=:10
(pour du X forwarding avec SSH).

Perso je n'ai jamais eu besoin de définir DISPLAY en local. Je comprends
que tu dois le faire si iTerm ne le fait pas par défaut.

Quel type de machine as-tu en local, et quel type d'émulateur de
terminal utilises-tu ?

Parfois iTerm, parfois (u)xterm. Dans iTerm, la variable DISPLAY n'est
pas définie. Donc j'ai l'habitude de le préciser. Il faudrait d'ailleurs
que je mette à jour mes scripts pour que la valeur de DISPLAY soit
changée automatiquement dans mes shells lorsque je lance ou quitte le
serveur X.

Donc si je comprends bien, tu n'utilises pas du tout l'application
Terminal fournie par Apple ?

Comment changes-tu le charset de ton shell ?

Par mon .zshenv (l'algo est en gros: si charset actuel = ASCII, alors
on change en ISO-8859-1, sinon on le laisse tel quel).

Ok.

et de quel shell s'agit-il ?

zsh

Comme moi. Mais je ne change pas le charset dans .zshenv. J'ai peut-être
tord...

As-tu essayé de changer le charset du Terminal proprement dit dans
Terminal --> Réglages de la fenêtre --> Affichage --> Encodage...

Le charset du terminal est ISO-8859-1 pour iTerm (il doit correspondre
à LC_CTYPE, sinon ça pose évidemment des problèmes). Donc dans mes
sessions iTerm, j'ai toujours du ISO-8859-1 (bon, sauf parfois à
l'intérieur de sessions screen où il m'arrive d'avoir de l'UTF-8, mais
c'est screen qui s'occupe de la conversion pour l'affichage dans le
terminal, et je n'ai jamais eu de problème avec). Dans (u)xterm, il
est également toujours à la bonne valeur (mon algo est compatible avec
ce que fait xterm).

Ma question concernait l'appli Terminal d'Apple. J'aimerais bien que tu
fasses un essai avec cette appli, en faisant le réglage de charset comme
indiqué ci-dessus.

Et puis de toute façon, OpenOffice ne s'occupe pas du terminal
(d'ailleurs il peut être lancé via les menus). Donc même avec un
terminal mal configuré, OpenOffice devrait fonctionner correctement
tant que le nom du fichier est écrit en UTF-8. Ici, c'est l'inverse
qui se produit: OpenOffice n'accepte que les noms de fichiers écrits
en ISO-8859-1, même lorsqu'il est lancé avec des locales UTF-8.

Amha le terminal intervient quand même dans la traduction de ce que tu
tapes au clavier vers les caractères de la ligne de commande, d'une
part. Dans l'affichage de la ligne de commande, d'autre part.
Ensuite le shell intervient dans l'interprétation de cette ligne de
commande et l'envoi des arguments vers l'application.
Donc le charset du terminal et le charset du shell sont tous deux
importants. Je pense que tu minimises l'importance de celui du terminal.

Autre précision: ceci fonctionne bien:

prunille:~> cat > é.sh
echo OK
sleep 10
prunille:~> chmod 755 é.sh
prunille:~> xterm -e é.sh

(où tous les "é" sont écrits en NFC). Mais

prunille:~>
/Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice é.sh

me dit que le fichier n'existe pas.

Je viens de refaire ces commandes chez moi, et ça marche très bien,
pourvu que je règle le Terminal en UTF-8

JPaul.

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

Vincent Lefevre <vincent+news@vinc17.org> wrote:

Dans l'article <1huhsd2.1f0i17c1k01evoN%blanc@empty.org>,
JPaul <blanc@empty.org> écrit:

ton DISPLAY=:0 me laisse penser que le Mac n'est pas la machine locale.

Au contraire, un DISPLAY=:0 indique quasiment toujours la machine locale.
Si c'était distant, cela aurait été quelque chose du style DISPLAY=:10
(pour du X forwarding avec SSH).

Perso je n'ai jamais eu besoin de définir DISPLAY en local. Je comprends
que tu dois le faire si iTerm ne le fait pas par défaut.

Quel type de machine as-tu en local, et quel type d'émulateur de
terminal utilises-tu ?

Parfois iTerm, parfois (u)xterm. Dans iTerm, la variable DISPLAY n'est
pas définie. Donc j'ai l'habitude de le préciser. Il faudrait d'ailleurs
que je mette à jour mes scripts pour que la valeur de DISPLAY soit
changée automatiquement dans mes shells lorsque je lance ou quitte le
serveur X.

Donc si je comprends bien, tu n'utilises pas du tout l'application
Terminal fournie par Apple ?

Comment changes-tu le charset de ton shell ?

Par mon .zshenv (l'algo est en gros: si charset actuel = ASCII, alors
on change en ISO-8859-1, sinon on le laisse tel quel).

Ok.

et de quel shell s'agit-il ?

zsh

Comme moi. Mais je ne change pas le charset dans .zshenv. J'ai peut-être
tord...

As-tu essayé de changer le charset du Terminal proprement dit dans
Terminal --> Réglages de la fenêtre --> Affichage --> Encodage...

Le charset du terminal est ISO-8859-1 pour iTerm (il doit correspondre
à LC_CTYPE, sinon ça pose évidemment des problèmes). Donc dans mes
sessions iTerm, j'ai toujours du ISO-8859-1 (bon, sauf parfois à
l'intérieur de sessions screen où il m'arrive d'avoir de l'UTF-8, mais
c'est screen qui s'occupe de la conversion pour l'affichage dans le
terminal, et je n'ai jamais eu de problème avec). Dans (u)xterm, il
est également toujours à la bonne valeur (mon algo est compatible avec
ce que fait xterm).

Ma question concernait l'appli Terminal d'Apple. J'aimerais bien que tu
fasses un essai avec cette appli, en faisant le réglage de charset comme
indiqué ci-dessus.

Et puis de toute façon, OpenOffice ne s'occupe pas du terminal
(d'ailleurs il peut être lancé via les menus). Donc même avec un
terminal mal configuré, OpenOffice devrait fonctionner correctement
tant que le nom du fichier est écrit en UTF-8. Ici, c'est l'inverse
qui se produit: OpenOffice n'accepte que les noms de fichiers écrits
en ISO-8859-1, même lorsqu'il est lancé avec des locales UTF-8.

Amha le terminal intervient quand même dans la traduction de ce que tu
tapes au clavier vers les caractères de la ligne de commande, d'une
part. Dans l'affichage de la ligne de commande, d'autre part.
Ensuite le shell intervient dans l'interprétation de cette ligne de
commande et l'envoi des arguments vers l'application.
Donc le charset du terminal et le charset du shell sont tous deux
importants. Je pense que tu minimises l'importance de celui du terminal.

Autre précision: ceci fonctionne bien:

prunille:~> cat > é.sh
echo OK
sleep 10
prunille:~> chmod 755 é.sh
prunille:~> xterm -e é.sh

(où tous les "é" sont écrits en NFC). Mais

prunille:~>
/Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice é.sh

me dit que le fichier n'existe pas.

Je viens de refaire ces commandes chez moi, et ça marche très bien,
pourvu que je règle le Terminal en UTF-8

JPaul.

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

Vous avez filtré cet utilisateur ! Consultez son message

Vincent Lefevre <vincent+ wrote:

Dans l'article <1huhsd2.1f0i17c1k01evoN%,
JPaul écrit:

ton DISPLAY=:0 me laisse penser que le Mac n'est pas la machine locale.

Au contraire, un DISPLAY=:0 indique quasiment toujours la machine locale.
Si c'était distant, cela aurait été quelque chose du style DISPLAY=:10
(pour du X forwarding avec SSH).

Perso je n'ai jamais eu besoin de définir DISPLAY en local. Je comprends
que tu dois le faire si iTerm ne le fait pas par défaut.

Quel type de machine as-tu en local, et quel type d'émulateur de
terminal utilises-tu ?

Parfois iTerm, parfois (u)xterm. Dans iTerm, la variable DISPLAY n'est
pas définie. Donc j'ai l'habitude de le préciser. Il faudrait d'ailleurs
que je mette à jour mes scripts pour que la valeur de DISPLAY soit
changée automatiquement dans mes shells lorsque je lance ou quitte le
serveur X.

Donc si je comprends bien, tu n'utilises pas du tout l'application
Terminal fournie par Apple ?

Comment changes-tu le charset de ton shell ?

Par mon .zshenv (l'algo est en gros: si charset actuel = ASCII, alors
on change en ISO-8859-1, sinon on le laisse tel quel).

Ok.

et de quel shell s'agit-il ?

zsh

Comme moi. Mais je ne change pas le charset dans .zshenv. J'ai peut-être
tord...

As-tu essayé de changer le charset du Terminal proprement dit dans
Terminal --> Réglages de la fenêtre --> Affichage --> Encodage...

Le charset du terminal est ISO-8859-1 pour iTerm (il doit correspondre
à LC_CTYPE, sinon ça pose évidemment des problèmes). Donc dans mes
sessions iTerm, j'ai toujours du ISO-8859-1 (bon, sauf parfois à
l'intérieur de sessions screen où il m'arrive d'avoir de l'UTF-8, mais
c'est screen qui s'occupe de la conversion pour l'affichage dans le
terminal, et je n'ai jamais eu de problème avec). Dans (u)xterm, il
est également toujours à la bonne valeur (mon algo est compatible avec
ce que fait xterm).

Ma question concernait l'appli Terminal d'Apple. J'aimerais bien que tu
fasses un essai avec cette appli, en faisant le réglage de charset comme
indiqué ci-dessus.

Et puis de toute façon, OpenOffice ne s'occupe pas du terminal
(d'ailleurs il peut être lancé via les menus). Donc même avec un
terminal mal configuré, OpenOffice devrait fonctionner correctement
tant que le nom du fichier est écrit en UTF-8. Ici, c'est l'inverse
qui se produit: OpenOffice n'accepte que les noms de fichiers écrits
en ISO-8859-1, même lorsqu'il est lancé avec des locales UTF-8.

Amha le terminal intervient quand même dans la traduction de ce que tu
tapes au clavier vers les caractères de la ligne de commande, d'une
part. Dans l'affichage de la ligne de commande, d'autre part.
Ensuite le shell intervient dans l'interprétation de cette ligne de
commande et l'envoi des arguments vers l'application.
Donc le charset du terminal et le charset du shell sont tous deux
importants. Je pense que tu minimises l'importance de celui du terminal.

Autre précision: ceci fonctionne bien:

prunille:~> cat > é.sh
echo OK
sleep 10
prunille:~> chmod 755 é.sh
prunille:~> xterm -e é.sh

(où tous les "é" sont écrits en NFC). Mais

prunille:~>
/Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice é.sh

me dit que le fichier n'existe pas.

Je viens de refaire ces commandes chez moi, et ça marche très bien,
pourvu que je règle le Terminal en UTF-8

JPaul.

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

Vincent Lefevre

06/03/2007 à 21:31

Dans l'article <1hukhlg.10xogzqxo73hkN%,
JPaul écrit:

Perso je n'ai jamais eu besoin de définir DISPLAY en local. Je comprends
que tu dois le faire si iTerm ne le fait pas par défaut.

Bizarre, parce que Terminal ne la définit pas non plus (ce qui est
normal, d'ailleurs). Tu as peut-être un fichier d'init qui le fait.

Donc si je comprends bien, tu n'utilises pas du tout l'application
Terminal fournie par Apple ?

Non, sauf pour certains tests.

Ma question concernait l'appli Terminal d'Apple. J'aimerais bien que tu
fasses un essai avec cette appli, en faisant le réglage de charset comme
indiqué ci-dessus.

Quel intérêt? En tout cas, j'ai exactement le même problème avec.
Mais ce n'est pas étonnant.

Et puis de toute façon, OpenOffice ne s'occupe pas du terminal
(d'ailleurs il peut être lancé via les menus). Donc même avec un
terminal mal configuré, OpenOffice devrait fonctionner correctement
tant que le nom du fichier est écrit en UTF-8. Ici, c'est l'inverse
qui se produit: OpenOffice n'accepte que les noms de fichiers écrits
en ISO-8859-1, même lorsqu'il est lancé avec des locales UTF-8.

Amha le terminal intervient quand même dans la traduction de ce que tu
tapes au clavier vers les caractères de la ligne de commande, d'une
part.

D'abord, mes terminaux sont correctement configurés. Et ensuite,
le terminal n'intervient pas. C'est l'essentiel.

Dans l'affichage de la ligne de commande, d'autre part.

Idem.

Ensuite le shell intervient dans l'interprétation de cette ligne de
commande et l'envoi des arguments vers l'application.

Assez peu. Changer l'encodage ne changera pas la façon dont le shell
interprète la ligne de commande.

Donc le charset du terminal et le charset du shell sont tous deux
importants. Je pense que tu minimises l'importance de celui du terminal.

Non. Le "touch é.odt" ne fonctionnerait pas si le terminal n'était
pas en UTF-8, de toute façon. Et puis le shell n'a pas de charset.

Autre précision: ceci fonctionne bien:

prunille:~> cat > é.sh
echo OK
sleep 10
prunille:~> chmod 755 é.sh
prunille:~> xterm -e é.sh

(où tous les "é" sont écrits en NFC). Mais

prunille:~>
/Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice é.sh

me dit que le fichier n'existe pas.

Je viens de refaire ces commandes chez moi, et ça marche très bien,
pourvu que je règle le Terminal en UTF-8

Pas chez moi, avec un Terminal en UTF-8.

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

Dans l'article <1hukhlg.10xogzqxo73hkN%blanc@empty.org>,
JPaul <blanc@empty.org> écrit:

Perso je n'ai jamais eu besoin de définir DISPLAY en local. Je comprends
que tu dois le faire si iTerm ne le fait pas par défaut.

Bizarre, parce que Terminal ne la définit pas non plus (ce qui est
normal, d'ailleurs). Tu as peut-être un fichier d'init qui le fait.

Donc si je comprends bien, tu n'utilises pas du tout l'application
Terminal fournie par Apple ?

Non, sauf pour certains tests.

Ma question concernait l'appli Terminal d'Apple. J'aimerais bien que tu
fasses un essai avec cette appli, en faisant le réglage de charset comme
indiqué ci-dessus.

Quel intérêt? En tout cas, j'ai exactement le même problème avec.
Mais ce n'est pas étonnant.

Et puis de toute façon, OpenOffice ne s'occupe pas du terminal
(d'ailleurs il peut être lancé via les menus). Donc même avec un
terminal mal configuré, OpenOffice devrait fonctionner correctement
tant que le nom du fichier est écrit en UTF-8. Ici, c'est l'inverse
qui se produit: OpenOffice n'accepte que les noms de fichiers écrits
en ISO-8859-1, même lorsqu'il est lancé avec des locales UTF-8.

Amha le terminal intervient quand même dans la traduction de ce que tu
tapes au clavier vers les caractères de la ligne de commande, d'une
part.

D'abord, mes terminaux sont correctement configurés. Et ensuite,
le terminal n'intervient pas. C'est l'essentiel.

Dans l'affichage de la ligne de commande, d'autre part.

Idem.

Ensuite le shell intervient dans l'interprétation de cette ligne de
commande et l'envoi des arguments vers l'application.

Assez peu. Changer l'encodage ne changera pas la façon dont le shell
interprète la ligne de commande.

Donc le charset du terminal et le charset du shell sont tous deux
importants. Je pense que tu minimises l'importance de celui du terminal.

Non. Le "touch é.odt" ne fonctionnerait pas si le terminal n'était
pas en UTF-8, de toute façon. Et puis le shell n'a pas de charset.

Autre précision: ceci fonctionne bien:

prunille:~> cat > é.sh
echo OK
sleep 10
prunille:~> chmod 755 é.sh
prunille:~> xterm -e é.sh

(où tous les "é" sont écrits en NFC). Mais

prunille:~>
/Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice é.sh

me dit que le fichier n'existe pas.

Je viens de refaire ces commandes chez moi, et ça marche très bien,
pourvu que je règle le Terminal en UTF-8

Pas chez moi, avec un Terminal en UTF-8.

--
Vincent Lefèvre <vincent@vinc17.org> - 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)

Vous avez filtré cet utilisateur ! Consultez son message

Dans l'article <1hukhlg.10xogzqxo73hkN%,
JPaul écrit:

Perso je n'ai jamais eu besoin de définir DISPLAY en local. Je comprends
que tu dois le faire si iTerm ne le fait pas par défaut.

Bizarre, parce que Terminal ne la définit pas non plus (ce qui est
normal, d'ailleurs). Tu as peut-être un fichier d'init qui le fait.

Donc si je comprends bien, tu n'utilises pas du tout l'application
Terminal fournie par Apple ?

Non, sauf pour certains tests.

Ma question concernait l'appli Terminal d'Apple. J'aimerais bien que tu
fasses un essai avec cette appli, en faisant le réglage de charset comme
indiqué ci-dessus.

Quel intérêt? En tout cas, j'ai exactement le même problème avec.
Mais ce n'est pas étonnant.

Et puis de toute façon, OpenOffice ne s'occupe pas du terminal
(d'ailleurs il peut être lancé via les menus). Donc même avec un
terminal mal configuré, OpenOffice devrait fonctionner correctement
tant que le nom du fichier est écrit en UTF-8. Ici, c'est l'inverse
qui se produit: OpenOffice n'accepte que les noms de fichiers écrits
en ISO-8859-1, même lorsqu'il est lancé avec des locales UTF-8.

Amha le terminal intervient quand même dans la traduction de ce que tu
tapes au clavier vers les caractères de la ligne de commande, d'une
part.

D'abord, mes terminaux sont correctement configurés. Et ensuite,
le terminal n'intervient pas. C'est l'essentiel.

Dans l'affichage de la ligne de commande, d'autre part.

Idem.

Ensuite le shell intervient dans l'interprétation de cette ligne de
commande et l'envoi des arguments vers l'application.

Assez peu. Changer l'encodage ne changera pas la façon dont le shell
interprète la ligne de commande.

Donc le charset du terminal et le charset du shell sont tous deux
importants. Je pense que tu minimises l'importance de celui du terminal.

Non. Le "touch é.odt" ne fonctionnerait pas si le terminal n'était
pas en UTF-8, de toute façon. Et puis le shell n'a pas de charset.

Autre précision: ceci fonctionne bien:

prunille:~> cat > é.sh
echo OK
sleep 10
prunille:~> chmod 755 é.sh
prunille:~> xterm -e é.sh

(où tous les "é" sont écrits en NFC). Mais

prunille:~>
/Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice é.sh

me dit que le fichier n'existe pas.

Je viens de refaire ces commandes chez moi, et ça marche très bien,
pourvu que je règle le Terminal en UTF-8

Pas chez moi, avec un Terminal en UTF-8.

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

blanc

06/03/2007 à 23:07

Vincent Lefevre <vincent+ wrote:

Bizarre, parce que Terminal ne la définit pas non plus (ce qui est
normal, d'ailleurs). Tu as peut-être un fichier d'init qui le fait.

Non, mais en fait je lance rarement des applis X11 avec le Terminal.
Je suis très partisan du double clic sur le document que je veux ouvrir.

Ma question concernait l'appli Terminal d'Apple. J'aimerais bien que tu
fasses un essai avec cette appli, en faisant le réglage de charset comme
indiqué ci-dessus.

Quel intérêt?

L'intérêt d'essayer même les choses qui paraissent abracadabrantes (et
en fait pour moi cet essai ne l'est pas) quand je ne comprends pas
pourquoi quelque chose ne marche pas.

En tout cas, j'ai exactement le même problème avec.
Mais ce n'est pas étonnant.

Si, c'est étonnant, car chez moi ça marche. Or nous avions une
différence d'utilisation qui aurait pu expliquer le phénomène.

Et puis de toute façon, OpenOffice ne s'occupe pas du terminal
(d'ailleurs il peut être lancé via les menus). Donc même avec un
terminal mal configuré, OpenOffice devrait fonctionner correctement
tant que le nom du fichier est écrit en UTF-8. Ici, c'est l'inverse
qui se produit: OpenOffice n'accepte que les noms de fichiers écrits
en ISO-8859-1, même lorsqu'il est lancé avec des locales UTF-8.

Amha le terminal intervient quand même dans la traduction de ce que tu
tapes au clavier vers les caractères de la ligne de commande, d'une
part.

D'abord, mes terminaux sont correctement configurés. Et ensuite,
le terminal n'intervient pas. C'est l'essentiel.

Pas vraiment d'accord avec toi.

Je viens de refaire ces commandes chez moi, et ça marche très bien,
pourvu que je règle le Terminal en UTF-8

Pas chez moi, avec un Terminal en UTF-8.

Je crois qu'il ne reste plus que l'exorciste ;-)

Désolè :-/

JPaul.

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

Vincent Lefevre <vincent+news@vinc17.org> wrote:

Bizarre, parce que Terminal ne la définit pas non plus (ce qui est
normal, d'ailleurs). Tu as peut-être un fichier d'init qui le fait.

Non, mais en fait je lance rarement des applis X11 avec le Terminal.
Je suis très partisan du double clic sur le document que je veux ouvrir.

Ma question concernait l'appli Terminal d'Apple. J'aimerais bien que tu
fasses un essai avec cette appli, en faisant le réglage de charset comme
indiqué ci-dessus.

Quel intérêt?

L'intérêt d'essayer même les choses qui paraissent abracadabrantes (et
en fait pour moi cet essai ne l'est pas) quand je ne comprends pas
pourquoi quelque chose ne marche pas.

En tout cas, j'ai exactement le même problème avec.
Mais ce n'est pas étonnant.

Si, c'est étonnant, car chez moi ça marche. Or nous avions une
différence d'utilisation qui aurait pu expliquer le phénomène.

Et puis de toute façon, OpenOffice ne s'occupe pas du terminal
(d'ailleurs il peut être lancé via les menus). Donc même avec un
terminal mal configuré, OpenOffice devrait fonctionner correctement
tant que le nom du fichier est écrit en UTF-8. Ici, c'est l'inverse
qui se produit: OpenOffice n'accepte que les noms de fichiers écrits
en ISO-8859-1, même lorsqu'il est lancé avec des locales UTF-8.

Amha le terminal intervient quand même dans la traduction de ce que tu
tapes au clavier vers les caractères de la ligne de commande, d'une
part.

D'abord, mes terminaux sont correctement configurés. Et ensuite,
le terminal n'intervient pas. C'est l'essentiel.

Pas vraiment d'accord avec toi.

Je viens de refaire ces commandes chez moi, et ça marche très bien,
pourvu que je règle le Terminal en UTF-8

Pas chez moi, avec un Terminal en UTF-8.

Je crois qu'il ne reste plus que l'exorciste ;-)

Désolè :-/

JPaul.

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

Vincent Lefevre

07/03/2007 à 01:41

J'ai trouvé l'origine du bug, les explications (enfin, une partie) dans
le message...

Dans l'article <1hukt0b.udks981jwv7u5N%,
JPaul écrit:

Vincent Lefevre <vincent+ wrote:

Bizarre, parce que Terminal ne la définit pas non plus (ce qui est
normal, d'ailleurs). Tu as peut-être un fichier d'init qui le fait.

Non, mais en fait je lance rarement des applis X11 avec le Terminal.
Je suis très partisan du double clic sur le document que je veux ouvrir.

Dans ce cas, il y a un wrapper qui fait ce qu'il faut. Enfin, quelque
chose du genre.

Ma question concernait l'appli Terminal d'Apple. J'aimerais bien
que tu fasses un essai avec cette appli, en faisant le réglage
de charset comme indiqué ci-dessus.

Quel intérêt?

L'intérêt d'essayer même les choses qui paraissent abracadabrantes (et
en fait pour moi cet essai ne l'est pas) quand je ne comprends pas
pourquoi quelque chose ne marche pas.

En tout cas, j'ai exactement le même problème avec.
Mais ce n'est pas étonnant.

Si, c'est étonnant, car chez moi ça marche.

Quand je disais ce n'est pas étonnant, c'est parce que le comportement
est tout à fait cohérent avec ce que j'obtiens depuis iTerm ou xterm.
Le fait que ça marche chez toi et pas chez moi est dû à autre chose,
mais certainement pas au terminal (d'ailleurs, via le Finder, c'est
pareil, et aucun terminal n'intervient).

Or nous avions une différence d'utilisation qui aurait pu expliquer
le phénomène.

Enfin, moi je savais que non (puisque le terminal n'intervenait pas
au niveau de l'erreur et je savais très bien comment mes caractères
étaient encodés).

Bon, j'ai identifié le bug... Tout d'abord, quelques infos: avec un
fichier blah_é.odt et un

ktrace -di /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice blah_*.odt

j'obtiens dans le dump:

12182 soffice.bin CALL getattrlist(0xf0100690,0xf00fe9e0,0xf00fe690,0x334,0x4)
12182 soffice.bin NAMI "/Users/vinc17/blah_e<C3><8C><C2><81>.odt"
12182 soffice.bin RET getattrlist -1 errno 2 No such file or directory
12182 soffice.bin CALL access(0x5afaa6c,0)
12182 soffice.bin NAMI "/Users/vinc17/blah_e<C3><8C><C2><81>.odt"
12182 soffice.bin RET access -1 errno 2 No such file or directory

au lieu de "/Users/vinc17/blah_e<CC><81>.odt". En gros, OpenOffice a
considéré le nom du fichier comme étant écrit en ISO-8859-1 et a fait
une transformation en UTF-8 (<CC> -> <C3><8C> et <81> -> <C2><81>).
C'était ce que j'avais déjà observé (cf mon message du Sun, 4 Mar 2007
21:47:49 +0000). Maintenant le message

I18N: Operating system doesn't support locale ""

peut être lié au problème. Voyons dans le dump...

12182 soffice.bin NAMI "/usr/share/locale/=EUR/LC_COLLATE"
12182 soffice.bin RET open -1 errno 2 No such file or directory
12182 soffice.bin CALL write(0x2,0xf01013a0,0x31)
12182 soffice.bin GIO fd 2 wrote 49 bytes
"I18N: Operating system doesn't support locale ""
"

Évidemment, je n'ai rien à f... du =EUR. D'où l'erreur
sur ma machine. Ensuite OpenOffice fait bien ensuite:

12182 soffice.bin NAMI "/usr/share/locale/en_US.UTF-8/LC_COLLATE"

(qui correspond à mes locales), mais je suppose qu'OpenOffice est déjà
perturbé. Dans mes préférences système, je change la monnaie de l'Euro
en "British Pound Sterling", et là, je n'ai plus ce message d'erreur,
et le fichier blah_é.odt est bien ouvert!!!

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

J'ai trouvé l'origine du bug, les explications (enfin, une partie) dans
le message...

Dans l'article <1hukt0b.udks981jwv7u5N%blanc@empty.org>,
JPaul <blanc@empty.org> écrit:

Vincent Lefevre <vincent+news@vinc17.org> wrote:

Bizarre, parce que Terminal ne la définit pas non plus (ce qui est
normal, d'ailleurs). Tu as peut-être un fichier d'init qui le fait.

Non, mais en fait je lance rarement des applis X11 avec le Terminal.
Je suis très partisan du double clic sur le document que je veux ouvrir.

Dans ce cas, il y a un wrapper qui fait ce qu'il faut. Enfin, quelque
chose du genre.

Ma question concernait l'appli Terminal d'Apple. J'aimerais bien
que tu fasses un essai avec cette appli, en faisant le réglage
de charset comme indiqué ci-dessus.

Quel intérêt?

L'intérêt d'essayer même les choses qui paraissent abracadabrantes (et
en fait pour moi cet essai ne l'est pas) quand je ne comprends pas
pourquoi quelque chose ne marche pas.

En tout cas, j'ai exactement le même problème avec.
Mais ce n'est pas étonnant.

Si, c'est étonnant, car chez moi ça marche.

Quand je disais ce n'est pas étonnant, c'est parce que le comportement
est tout à fait cohérent avec ce que j'obtiens depuis iTerm ou xterm.
Le fait que ça marche chez toi et pas chez moi est dû à autre chose,
mais certainement pas au terminal (d'ailleurs, via le Finder, c'est
pareil, et aucun terminal n'intervient).

Or nous avions une différence d'utilisation qui aurait pu expliquer
le phénomène.

Enfin, moi je savais que non (puisque le terminal n'intervenait pas
au niveau de l'erreur et je savais très bien comment mes caractères
étaient encodés).

Bon, j'ai identifié le bug... Tout d'abord, quelques infos: avec un
fichier blah_é.odt et un

ktrace -di /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice blah_*.odt

j'obtiens dans le dump:

12182 soffice.bin CALL getattrlist(0xf0100690,0xf00fe9e0,0xf00fe690,0x334,0x4)
12182 soffice.bin NAMI "/Users/vinc17/blah_e<C3><8C><C2><81>.odt"
12182 soffice.bin RET getattrlist -1 errno 2 No such file or directory
12182 soffice.bin CALL access(0x5afaa6c,0)
12182 soffice.bin NAMI "/Users/vinc17/blah_e<C3><8C><C2><81>.odt"
12182 soffice.bin RET access -1 errno 2 No such file or directory

au lieu de "/Users/vinc17/blah_e<CC><81>.odt". En gros, OpenOffice a
considéré le nom du fichier comme étant écrit en ISO-8859-1 et a fait
une transformation en UTF-8 (<CC> -> <C3><8C> et <81> -> <C2><81>).
C'était ce que j'avais déjà observé (cf mon message du Sun, 4 Mar 2007
21:47:49 +0000). Maintenant le message

I18N: Operating system doesn't support locale ""

peut être lié au problème. Voyons dans le dump...

12182 soffice.bin NAMI "/usr/share/locale/en_GB@currency=EUR/LC_COLLATE"
12182 soffice.bin RET open -1 errno 2 No such file or directory
12182 soffice.bin CALL write(0x2,0xf01013a0,0x31)
12182 soffice.bin GIO fd 2 wrote 49 bytes
"I18N: Operating system doesn't support locale ""
"

Évidemment, je n'ai rien à f... du en_GB@currency=EUR. D'où l'erreur
sur ma machine. Ensuite OpenOffice fait bien ensuite:

12182 soffice.bin NAMI "/usr/share/locale/en_US.UTF-8/LC_COLLATE"

(qui correspond à mes locales), mais je suppose qu'OpenOffice est déjà
perturbé. Dans mes préférences système, je change la monnaie de l'Euro
en "British Pound Sterling", et là, je n'ai plus ce message d'erreur,
et le fichier blah_é.odt est bien ouvert!!!

--
Vincent Lefèvre <vincent@vinc17.org> - 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)

Vous avez filtré cet utilisateur ! Consultez son message

J'ai trouvé l'origine du bug, les explications (enfin, une partie) dans
le message...

Dans l'article <1hukt0b.udks981jwv7u5N%,
JPaul écrit:

Vincent Lefevre <vincent+ wrote:

Bizarre, parce que Terminal ne la définit pas non plus (ce qui est
normal, d'ailleurs). Tu as peut-être un fichier d'init qui le fait.

Non, mais en fait je lance rarement des applis X11 avec le Terminal.
Je suis très partisan du double clic sur le document que je veux ouvrir.

Dans ce cas, il y a un wrapper qui fait ce qu'il faut. Enfin, quelque
chose du genre.

Ma question concernait l'appli Terminal d'Apple. J'aimerais bien
que tu fasses un essai avec cette appli, en faisant le réglage
de charset comme indiqué ci-dessus.

Quel intérêt?

L'intérêt d'essayer même les choses qui paraissent abracadabrantes (et
en fait pour moi cet essai ne l'est pas) quand je ne comprends pas
pourquoi quelque chose ne marche pas.

En tout cas, j'ai exactement le même problème avec.
Mais ce n'est pas étonnant.

Si, c'est étonnant, car chez moi ça marche.

Quand je disais ce n'est pas étonnant, c'est parce que le comportement
est tout à fait cohérent avec ce que j'obtiens depuis iTerm ou xterm.
Le fait que ça marche chez toi et pas chez moi est dû à autre chose,
mais certainement pas au terminal (d'ailleurs, via le Finder, c'est
pareil, et aucun terminal n'intervient).

Or nous avions une différence d'utilisation qui aurait pu expliquer
le phénomène.

Enfin, moi je savais que non (puisque le terminal n'intervenait pas
au niveau de l'erreur et je savais très bien comment mes caractères
étaient encodés).

Bon, j'ai identifié le bug... Tout d'abord, quelques infos: avec un
fichier blah_é.odt et un

ktrace -di /Applications/OpenOffice.org 2.1.app/Contents/MacOS/program/soffice blah_*.odt

j'obtiens dans le dump:

12182 soffice.bin CALL getattrlist(0xf0100690,0xf00fe9e0,0xf00fe690,0x334,0x4)
12182 soffice.bin NAMI "/Users/vinc17/blah_e<C3><8C><C2><81>.odt"
12182 soffice.bin RET getattrlist -1 errno 2 No such file or directory
12182 soffice.bin CALL access(0x5afaa6c,0)
12182 soffice.bin NAMI "/Users/vinc17/blah_e<C3><8C><C2><81>.odt"
12182 soffice.bin RET access -1 errno 2 No such file or directory

au lieu de "/Users/vinc17/blah_e<CC><81>.odt". En gros, OpenOffice a
considéré le nom du fichier comme étant écrit en ISO-8859-1 et a fait
une transformation en UTF-8 (<CC> -> <C3><8C> et <81> -> <C2><81>).
C'était ce que j'avais déjà observé (cf mon message du Sun, 4 Mar 2007
21:47:49 +0000). Maintenant le message

I18N: Operating system doesn't support locale ""

peut être lié au problème. Voyons dans le dump...

12182 soffice.bin NAMI "/usr/share/locale/=EUR/LC_COLLATE"
12182 soffice.bin RET open -1 errno 2 No such file or directory
12182 soffice.bin CALL write(0x2,0xf01013a0,0x31)
12182 soffice.bin GIO fd 2 wrote 49 bytes
"I18N: Operating system doesn't support locale ""
"

Évidemment, je n'ai rien à f... du =EUR. D'où l'erreur
sur ma machine. Ensuite OpenOffice fait bien ensuite:

12182 soffice.bin NAMI "/usr/share/locale/en_US.UTF-8/LC_COLLATE"

(qui correspond à mes locales), mais je suppose qu'OpenOffice est déjà
perturbé. Dans mes préférences système, je change la monnaie de l'Euro
en "British Pound Sterling", et là, je n'ai plus ce message d'erreur,
et le fichier blah_é.odt est bien ouvert!!!

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

blanc

07/03/2007 à 14:02

Vincent Lefevre <vincent+ wrote:

12182 soffice.bin NAMI "/usr/share/locale/=EUR/LC_COLLATE"
12182 soffice.bin RET open -1 errno 2 No such file or directory
12182 soffice.bin CALL write(0x2,0xf01013a0,0x31)
12182 soffice.bin GIO fd 2 wrote 49 bytes
"I18N: Operating system doesn't support locale ""
"

Évidemment, je n'ai rien à f... du =EUR. D'où l'erreur
sur ma machine. Ensuite OpenOffice fait bien ensuite:

12182 soffice.bin NAMI "/usr/share/locale/en_US.UTF-8/LC_COLLATE"

(qui correspond à mes locales), mais je suppose qu'OpenOffice est déjà
perturbé. Dans mes préférences système, je change la monnaie de l'Euro
en "British Pound Sterling", et là, je n'ai plus ce message d'erreur,
et le fichier blah_é.odt est bien ouvert!!!

Vraiment curieux que la définition de la monnaie influe sur le charset
!...
Bon. Alors j'ai fait la même manip pour voir ce que j'avais perso. Voici
le résultat du dump, après avoir fgreppé la chaîne /locale/ :
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_COLLATE"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_CTYPE"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_MONETARY"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_NUMERIC"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_TIME"
16830 soffice.bin NAMI
"/usr/share/locale/fr_FR.UTF-8/LC_MESSAGES/LC_MESSAGES"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/locale.alias"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/locale.dir"
16830 soffice.bin NAMI
"/usr/X11R6/lib/X11/locale/en_US.UTF-8/XLC_LOCALE"
16830 soffice.bin NAMI
"/usr/X11R6/lib/X11/locale/en_US.UTF-8/XLC_LOCALE"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/compose.dir"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/compose.dir"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/share/locale/fr/cups_fr"
16830 soffice.bin NAMI "/usr/share/locale/fr/cups_fr"

(les lignes qui ne commencent pas par 16830 sont du au pliage de lignes
de MacSoup)

Et si je comprends bien les lignes avec fr_FR, je ne vois pas pourquoi
j'ai aussi des lignes avec en_US...

JPaul.

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

Vincent Lefevre <vincent+news@vinc17.org> wrote:

12182 soffice.bin NAMI "/usr/share/locale/en_GB@currency=EUR/LC_COLLATE"
12182 soffice.bin RET open -1 errno 2 No such file or directory
12182 soffice.bin CALL write(0x2,0xf01013a0,0x31)
12182 soffice.bin GIO fd 2 wrote 49 bytes
"I18N: Operating system doesn't support locale ""
"

Évidemment, je n'ai rien à f... du en_GB@currency=EUR. D'où l'erreur
sur ma machine. Ensuite OpenOffice fait bien ensuite:

12182 soffice.bin NAMI "/usr/share/locale/en_US.UTF-8/LC_COLLATE"

(qui correspond à mes locales), mais je suppose qu'OpenOffice est déjà
perturbé. Dans mes préférences système, je change la monnaie de l'Euro
en "British Pound Sterling", et là, je n'ai plus ce message d'erreur,
et le fichier blah_é.odt est bien ouvert!!!

Vraiment curieux que la définition de la monnaie influe sur le charset
!...
Bon. Alors j'ai fait la même manip pour voir ce que j'avais perso. Voici
le résultat du dump, après avoir fgreppé la chaîne /locale/ :
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_COLLATE"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_CTYPE"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_MONETARY"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_NUMERIC"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_TIME"
16830 soffice.bin NAMI
"/usr/share/locale/fr_FR.UTF-8/LC_MESSAGES/LC_MESSAGES"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/locale.alias"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/locale.dir"
16830 soffice.bin NAMI
"/usr/X11R6/lib/X11/locale/en_US.UTF-8/XLC_LOCALE"
16830 soffice.bin NAMI
"/usr/X11R6/lib/X11/locale/en_US.UTF-8/XLC_LOCALE"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/compose.dir"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/compose.dir"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/share/locale/fr/cups_fr"
16830 soffice.bin NAMI "/usr/share/locale/fr/cups_fr"

(les lignes qui ne commencent pas par 16830 sont du au pliage de lignes
de MacSoup)

Et si je comprends bien les lignes avec fr_FR, je ne vois pas pourquoi
j'ai aussi des lignes avec en_US...

JPaul.

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

Vous avez filtré cet utilisateur ! Consultez son message

Vincent Lefevre <vincent+ wrote:

12182 soffice.bin NAMI "/usr/share/locale/=EUR/LC_COLLATE"
12182 soffice.bin RET open -1 errno 2 No such file or directory
12182 soffice.bin CALL write(0x2,0xf01013a0,0x31)
12182 soffice.bin GIO fd 2 wrote 49 bytes
"I18N: Operating system doesn't support locale ""
"

Évidemment, je n'ai rien à f... du =EUR. D'où l'erreur
sur ma machine. Ensuite OpenOffice fait bien ensuite:

12182 soffice.bin NAMI "/usr/share/locale/en_US.UTF-8/LC_COLLATE"

(qui correspond à mes locales), mais je suppose qu'OpenOffice est déjà
perturbé. Dans mes préférences système, je change la monnaie de l'Euro
en "British Pound Sterling", et là, je n'ai plus ce message d'erreur,
et le fichier blah_é.odt est bien ouvert!!!

Vraiment curieux que la définition de la monnaie influe sur le charset
!...
Bon. Alors j'ai fait la même manip pour voir ce que j'avais perso. Voici
le résultat du dump, après avoir fgreppé la chaîne /locale/ :
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_COLLATE"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_CTYPE"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_MONETARY"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_NUMERIC"
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_TIME"
16830 soffice.bin NAMI
"/usr/share/locale/fr_FR.UTF-8/LC_MESSAGES/LC_MESSAGES"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/locale.alias"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/locale.dir"
16830 soffice.bin NAMI
"/usr/X11R6/lib/X11/locale/en_US.UTF-8/XLC_LOCALE"
16830 soffice.bin NAMI
"/usr/X11R6/lib/X11/locale/en_US.UTF-8/XLC_LOCALE"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/compose.dir"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/compose.dir"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose"
16830 soffice.bin NAMI "/usr/share/locale/fr/cups_fr"
16830 soffice.bin NAMI "/usr/share/locale/fr/cups_fr"

(les lignes qui ne commencent pas par 16830 sont du au pliage de lignes
de MacSoup)

Et si je comprends bien les lignes avec fr_FR, je ne vois pas pourquoi
j'ai aussi des lignes avec en_US...

JPaul.

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

Vincent Lefevre

07/03/2007 à 15:19

Dans l'article <1huly1k.13pj6v21e9hgl4N%,
JPaul écrit:

Bon. Alors j'ai fait la même manip pour voir ce que j'avais perso.
Voici le résultat du dump, après avoir fgreppé la chaîne /locale/ :
16830 soffice.bin NAMI "/usr/share/locale/fr_FR.UTF-8/LC_COLLATE"

Tiens, il va chercher de l'UTF-8 directement. J'ai l'impression que
pour Mac OS X (ou OpenOffice?):

_ Français (dans les préférences système) implique UTF-8, ce qui est
AMHA une meilleure solution à long terme que ISO-8859-15, mais c'est
peut-être aussi pour le support de l'apostrophe courbe (qui n'est
réellement qu'un guillemet fermant d'après la définition d'Unicode),
parce qu'elle n'existe pas dans le jeu de caractères ISO-8859-15.

_ Anglais (dans les préférences système) implique ISO-8859-1, qui est
suffisant pour les Anglais (ils n'ont pas de caractères accentués,
mais ISO-8859-1 est nécessaire pour leur monnaie £); cependant, si
on spécifie l'Euro comme monnaie, alors ça pose problème, si bien
que Mac OS X (ou OpenOffice?) choisit =EUR (ce qui
est idiot, car cette locale ne fait pas partie de Mac OS X, alors
que en_GB.UTF-8 en fait partie).

Et si je comprends bien les lignes avec fr_FR, je ne vois pas
pourquoi j'ai aussi des lignes avec en_US...

Les fichiers en question sont dans /usr/X11R6/lib/X11/locale/, alors
je suppose que c'est un truc lié à X (pour le support de la touche
Compose?). Je ne sais pas ce qui intervient ici (config du serveur X,
locales du serveur X?).

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

blanc

10/03/2007 à 16:19

Vincent Lefevre <vincent+ wrote:

Et si je comprends bien les lignes avec fr_FR, je ne vois pas
pourquoi j'ai aussi des lignes avec en_US...

Les fichiers en question sont dans /usr/X11R6/lib/X11/locale/, alors
je suppose que c'est un truc lié à X (pour le support de la touche
Compose?).

C'est vrai, je n'avais pas réalisé que c'est associé à X11. Peut-être
que ma version de X11 est mal configurée. Il faut que je regarde ça

JPaul.

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

OpenOffice et noms de fichiers avec caractere non ASCII

10 réponses

Veuillez sélectionner un problème