10.2.8 fraichement installé
je liste les fichiers à la racine de mon home, et ça me sort ça :
[Manet:~] manet% ls -l
total 112
drwx------ 7 manet staff 238 Nov 28 11:46 Desktop
drwx------ 16 manet staff 544 Nov 26 11:14 Documents
ls: ./Envoyer l???enregistrement: No such file or directory
lrwxr-xr-x 1 manet staff 55 Nov 27 11:10 Envoyer
l???enregistrement
drwx------ 29 manet staff 986 Nov 27 16:11 Library
(ensuite, c'est normal)
c'est quoi cette ligne blanche suivie de xxx -> no such file ?
j'ai essayé de réparer sans succès.
--
Philippe Manet
Le 30/11/03 23:16, dans , « Eric Jacoboni » a écrit :
Éric Lévénez writes:
Hein ? N'importe quoi.
Toi même...
Ah ?
Cela fait des dizaines d'années qu'unix marchent bien avec tous les accents possibles en 8 bits.
Oui, et ? Moi je ne supporte pas la connerie et, pourtant, il y a des cons, je le sais... Pour ta gouverne, ce groupe est francophone et je n'utilise pas le verbe "supporter" comme une traduction du verbe anglais "to support". Donc, je maintiens ce que j'ai dit.
Tu as le droit de te tromper.
Il n'y a que 2 caractères interdits dans un nom de fichier; c'est NUL (0) et "/" (séparateur de répertoire). Le problème vient surtout des utilisateurs des shells qui pensent que l'on n'a pas d'espace dans les noms ou pas de caractères spéciaux.
Il n'empêche que les espaces dans les noms de fichiers font plus chier le monde qu'autre chose quand on utilise les commandes en ligne.
Le monde = qui ?
Tu peux aussi nous expliquer que le caractère '*' est tout a fait admis et qu'il ne pose jamais de problème au pauvre débutant en ligne de commande, non ?
Le débutant a toujours des problèmes sur tout, même sur la touche Entrée.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 30/11/03 23:16, dans <m2k75ho63a.fsf@mac.scrogneugneu.org>, « Eric
Jacoboni » <jaco@teaser.fr> a écrit :
Éric Lévénez <news@levenez.com> writes:
Hein ? N'importe quoi.
Toi même...
Ah ?
Cela fait des dizaines d'années qu'unix marchent bien
avec tous les accents possibles en 8 bits.
Oui, et ? Moi je ne supporte pas la connerie et, pourtant, il y a des
cons, je le sais... Pour ta gouverne, ce groupe est francophone et
je n'utilise pas le verbe "supporter" comme une traduction du verbe
anglais "to support". Donc, je maintiens ce que j'ai dit.
Tu as le droit de te tromper.
Il n'y a que 2 caractères interdits dans un nom de fichier; c'est
NUL (0) et "/" (séparateur de répertoire). Le problème vient surtout
des utilisateurs des shells qui pensent que l'on n'a pas d'espace
dans les noms ou pas de caractères spéciaux.
Il n'empêche que les espaces dans les noms de fichiers font plus chier
le monde qu'autre chose quand on utilise les commandes en ligne.
Le monde = qui ?
Tu peux aussi nous expliquer que le caractère '*' est tout a fait
admis et qu'il ne pose jamais de problème au pauvre débutant en ligne
de commande, non ?
Le débutant a toujours des problèmes sur tout, même sur la touche Entrée.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 30/11/03 23:16, dans , « Eric Jacoboni » a écrit :
Éric Lévénez writes:
Hein ? N'importe quoi.
Toi même...
Ah ?
Cela fait des dizaines d'années qu'unix marchent bien avec tous les accents possibles en 8 bits.
Oui, et ? Moi je ne supporte pas la connerie et, pourtant, il y a des cons, je le sais... Pour ta gouverne, ce groupe est francophone et je n'utilise pas le verbe "supporter" comme une traduction du verbe anglais "to support". Donc, je maintiens ce que j'ai dit.
Tu as le droit de te tromper.
Il n'y a que 2 caractères interdits dans un nom de fichier; c'est NUL (0) et "/" (séparateur de répertoire). Le problème vient surtout des utilisateurs des shells qui pensent que l'on n'a pas d'espace dans les noms ou pas de caractères spéciaux.
Il n'empêche que les espaces dans les noms de fichiers font plus chier le monde qu'autre chose quand on utilise les commandes en ligne.
Le monde = qui ?
Tu peux aussi nous expliquer que le caractère '*' est tout a fait admis et qu'il ne pose jamais de problème au pauvre débutant en ligne de commande, non ?
Le débutant a toujours des problèmes sur tout, même sur la touche Entrée.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
david.andriana
Éric Lévénez wrote:
Ça viendrait de l'Unicode ?
Je ne sais pas je n'ai pas lu le début de la discussion. Je n'ai répondu que sur les caractères spéciaux.
Justement, tu dis que les caractères 8 bits passent sans problème. Je me demandais donc s'il y avait un problème avec une apostrophe Unicode.
Il ne faut pas confondre unix, les divers shells unix et les émulateurs de terminaux.
Bien sûr, bien sûr.
Seulement, le chti gars qui a eu déjà bien de la bonne volonté pour se mettre au shell par nécessité technique, alors qu'il pensait qu'il manipulerait un clickodrome fiable, ça va vachement le rassurer, tout ça.
Pour le coup, c'est "ls -l" qui part en vrille. On avait déjà eu des problèmes avec "ls", je crois bien. Dus à HFS+.
Sans rire, Éric, c'est nul, un "Unix" qui n'arrive même pas à faire marcher "ls" correctement. Je sais bien que c'est [certainement] dû à HFS+, mais tout le système en pâtit...
-- David
Éric Lévénez <news@levenez.com> wrote:
Ça viendrait de l'Unicode ?
Je ne sais pas je n'ai pas lu le début de la discussion. Je n'ai répondu que
sur les caractères spéciaux.
Justement, tu dis que les caractères 8 bits passent sans problème. Je me
demandais donc s'il y avait un problème avec une apostrophe Unicode.
Il ne faut pas confondre unix, les divers shells unix et les émulateurs de
terminaux.
Bien sûr, bien sûr.
Seulement, le chti gars qui a eu déjà bien de la bonne volonté pour se
mettre au shell par nécessité technique, alors qu'il pensait qu'il
manipulerait un clickodrome fiable, ça va vachement le rassurer, tout
ça.
Pour le coup, c'est "ls -l" qui part en vrille. On avait déjà eu des
problèmes avec "ls", je crois bien. Dus à HFS+.
Sans rire, Éric, c'est nul, un "Unix" qui n'arrive même pas à faire
marcher "ls" correctement. Je sais bien que c'est [certainement] dû à
HFS+, mais tout le système en pâtit...
Je ne sais pas je n'ai pas lu le début de la discussion. Je n'ai répondu que sur les caractères spéciaux.
Justement, tu dis que les caractères 8 bits passent sans problème. Je me demandais donc s'il y avait un problème avec une apostrophe Unicode.
Il ne faut pas confondre unix, les divers shells unix et les émulateurs de terminaux.
Bien sûr, bien sûr.
Seulement, le chti gars qui a eu déjà bien de la bonne volonté pour se mettre au shell par nécessité technique, alors qu'il pensait qu'il manipulerait un clickodrome fiable, ça va vachement le rassurer, tout ça.
Pour le coup, c'est "ls -l" qui part en vrille. On avait déjà eu des problèmes avec "ls", je crois bien. Dus à HFS+.
Sans rire, Éric, c'est nul, un "Unix" qui n'arrive même pas à faire marcher "ls" correctement. Je sais bien que c'est [certainement] dû à HFS+, mais tout le système en pâtit...
-- David
david.andriana
Salut Alain,
Alain Lortal !club-internet.fr> wrote:
....Salut David... Toujours aussi objectif, à ce que je vois...
....Salut David... Toujours aussi objectif, à ce que je vois...
Vil flatteur.
-- David
Éric Lévénez
Le 1/12/03 19:53, dans <1g59icp.1lbw63ngfo5meN@[192.168.0.120]>, « David Andriana » a écrit :
Éric Lévénez wrote:
Ça viendrait de l'Unicode ?
Je ne sais pas je n'ai pas lu le début de la discussion. Je n'ai répondu que sur les caractères spéciaux.
Justement, tu dis que les caractères 8 bits passent sans problème. Je me demandais donc s'il y avait un problème avec une apostrophe Unicode.
Attention, je parle du 8 bits sur tous les programmes unix. Le HFS+ ne gère pas des noms de 255 caractères 8 bits, mais de 255 caractères unicode 16 bits. Alors déjà il y a la limite du codage 16 bits qui est trop petite pour Panther qui utilise Unicode v4. Ensuite il y a la limite de la couche BSD sous Mac OS X qui gère mal le 8 bits. Ainsi un programme unix standard qui génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément valide. Mais si on fournit une suite d'octet valide à un programme unix il arrivera à utiliser ce nom de fichier. Le problème avec Terminal est qu'il utilise plusieurs modes d'encodage et que les shells escapent généralement tous les caractères spéciaux
Il ne faut pas confondre unix, les divers shells unix et les émulateurs de terminaux.
Bien sûr, bien sûr.
Seulement, le chti gars qui a eu déjà bien de la bonne volonté pour se mettre au shell par nécessité technique, alors qu'il pensait qu'il manipulerait un clickodrome fiable, ça va vachement le rassurer, tout ça.
Pour le coup, c'est "ls -l" qui part en vrille. On avait déjà eu des problèmes avec "ls", je crois bien. Dus à HFS+.
Sans rire, Éric, c'est nul, un "Unix" qui n'arrive même pas à faire marcher "ls" correctement. Je sais bien que c'est [certainement] dû à HFS+, mais tout le système en pâtit...
La gestion des liens unix sous HFS+ est une daube, effectivement.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 1/12/03 19:53, dans <1g59icp.1lbw63ngfo5meN@[192.168.0.120]>, « David
Andriana » <david.andriana@free.fr> a écrit :
Éric Lévénez <news@levenez.com> wrote:
Ça viendrait de l'Unicode ?
Je ne sais pas je n'ai pas lu le début de la discussion. Je n'ai répondu que
sur les caractères spéciaux.
Justement, tu dis que les caractères 8 bits passent sans problème. Je me
demandais donc s'il y avait un problème avec une apostrophe Unicode.
Attention, je parle du 8 bits sur tous les programmes unix. Le HFS+ ne gère
pas des noms de 255 caractères 8 bits, mais de 255 caractères unicode 16
bits. Alors déjà il y a la limite du codage 16 bits qui est trop petite pour
Panther qui utilise Unicode v4. Ensuite il y a la limite de la couche BSD
sous Mac OS X qui gère mal le 8 bits. Ainsi un programme unix standard qui
génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra
avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS
attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément
valide. Mais si on fournit une suite d'octet valide à un programme unix il
arrivera à utiliser ce nom de fichier. Le problème avec Terminal est qu'il
utilise plusieurs modes d'encodage et que les shells escapent généralement
tous les caractères spéciaux
Il ne faut pas confondre unix, les divers shells unix et les émulateurs de
terminaux.
Bien sûr, bien sûr.
Seulement, le chti gars qui a eu déjà bien de la bonne volonté pour se
mettre au shell par nécessité technique, alors qu'il pensait qu'il
manipulerait un clickodrome fiable, ça va vachement le rassurer, tout
ça.
Pour le coup, c'est "ls -l" qui part en vrille. On avait déjà eu des
problèmes avec "ls", je crois bien. Dus à HFS+.
Sans rire, Éric, c'est nul, un "Unix" qui n'arrive même pas à faire
marcher "ls" correctement. Je sais bien que c'est [certainement] dû à
HFS+, mais tout le système en pâtit...
La gestion des liens unix sous HFS+ est une daube, effectivement.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 1/12/03 19:53, dans <1g59icp.1lbw63ngfo5meN@[192.168.0.120]>, « David Andriana » a écrit :
Éric Lévénez wrote:
Ça viendrait de l'Unicode ?
Je ne sais pas je n'ai pas lu le début de la discussion. Je n'ai répondu que sur les caractères spéciaux.
Justement, tu dis que les caractères 8 bits passent sans problème. Je me demandais donc s'il y avait un problème avec une apostrophe Unicode.
Attention, je parle du 8 bits sur tous les programmes unix. Le HFS+ ne gère pas des noms de 255 caractères 8 bits, mais de 255 caractères unicode 16 bits. Alors déjà il y a la limite du codage 16 bits qui est trop petite pour Panther qui utilise Unicode v4. Ensuite il y a la limite de la couche BSD sous Mac OS X qui gère mal le 8 bits. Ainsi un programme unix standard qui génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément valide. Mais si on fournit une suite d'octet valide à un programme unix il arrivera à utiliser ce nom de fichier. Le problème avec Terminal est qu'il utilise plusieurs modes d'encodage et que les shells escapent généralement tous les caractères spéciaux
Il ne faut pas confondre unix, les divers shells unix et les émulateurs de terminaux.
Bien sûr, bien sûr.
Seulement, le chti gars qui a eu déjà bien de la bonne volonté pour se mettre au shell par nécessité technique, alors qu'il pensait qu'il manipulerait un clickodrome fiable, ça va vachement le rassurer, tout ça.
Pour le coup, c'est "ls -l" qui part en vrille. On avait déjà eu des problèmes avec "ls", je crois bien. Dus à HFS+.
Sans rire, Éric, c'est nul, un "Unix" qui n'arrive même pas à faire marcher "ls" correctement. Je sais bien que c'est [certainement] dû à HFS+, mais tout le système en pâtit...
La gestion des liens unix sous HFS+ est une daube, effectivement.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
david.andriana
Éric Lévénez wrote:
Attention, je parle du 8 bits sur tous les programmes unix. Le HFS+ ne gère pas des noms de 255 caractères 8 bits, mais de 255 caractères unicode 16 bits. Alors déjà il y a la limite du codage 16 bits qui est trop petite pour Panther qui utilise Unicode v4. Ensuite il y a la limite de la couche BSD sous Mac OS X qui gère mal le 8 bits. Ainsi un programme unix standard qui génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément valide. Mais si on fournit une suite d'octet valide à un programme unix il arrivera à utiliser ce nom de fichier. Le problème avec Terminal est qu'il utilise plusieurs modes d'encodage et que les shells escapent généralement tous les caractères spéciaux
Merci pour ces précisions.
Tu es sûr que le problème vient de Terminal ? Pas du shell ?
D'autre part, "une suite d'octets valide" laisse penser que ça marchera par hasard. Pas de contrôles amonts, pas de conversion rigoureuse préalable. Il n'y a pourtant pas tant de couches à traverser que ça, et en plus, les fichiers Mac peuvent utiliser des méta-données ! Pour le coup, il n'y a pas vraiment de raison technique à ce que ça marche aussi mal.
La gestion des liens unix sous HFS+ est une daube, effectivement.
Oh que oui.
Ça, plus le mélange dans les casses, qui impacte le shell. Je rappelle l'exemple :
# ls PIM pam poum # ls pim pim # ls p*m pam poum
(février 2001)
-- David
Éric Lévénez <news@levenez.com> wrote:
Attention, je parle du 8 bits sur tous les programmes unix. Le HFS+ ne gère
pas des noms de 255 caractères 8 bits, mais de 255 caractères unicode 16
bits. Alors déjà il y a la limite du codage 16 bits qui est trop petite pour
Panther qui utilise Unicode v4. Ensuite il y a la limite de la couche BSD
sous Mac OS X qui gère mal le 8 bits. Ainsi un programme unix standard qui
génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra
avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS
attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément
valide. Mais si on fournit une suite d'octet valide à un programme unix il
arrivera à utiliser ce nom de fichier. Le problème avec Terminal est qu'il
utilise plusieurs modes d'encodage et que les shells escapent généralement
tous les caractères spéciaux
Merci pour ces précisions.
Tu es sûr que le problème vient de Terminal ? Pas du shell ?
D'autre part, "une suite d'octets valide" laisse penser que ça marchera
par hasard. Pas de contrôles amonts, pas de conversion rigoureuse
préalable. Il n'y a pourtant pas tant de couches à traverser que ça, et
en plus, les fichiers Mac peuvent utiliser des méta-données ! Pour le
coup, il n'y a pas vraiment de raison technique à ce que ça marche aussi
mal.
La gestion des liens unix sous HFS+ est une daube, effectivement.
Oh que oui.
Ça, plus le mélange dans les casses, qui impacte le shell. Je rappelle
l'exemple :
Attention, je parle du 8 bits sur tous les programmes unix. Le HFS+ ne gère pas des noms de 255 caractères 8 bits, mais de 255 caractères unicode 16 bits. Alors déjà il y a la limite du codage 16 bits qui est trop petite pour Panther qui utilise Unicode v4. Ensuite il y a la limite de la couche BSD sous Mac OS X qui gère mal le 8 bits. Ainsi un programme unix standard qui génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément valide. Mais si on fournit une suite d'octet valide à un programme unix il arrivera à utiliser ce nom de fichier. Le problème avec Terminal est qu'il utilise plusieurs modes d'encodage et que les shells escapent généralement tous les caractères spéciaux
Merci pour ces précisions.
Tu es sûr que le problème vient de Terminal ? Pas du shell ?
D'autre part, "une suite d'octets valide" laisse penser que ça marchera par hasard. Pas de contrôles amonts, pas de conversion rigoureuse préalable. Il n'y a pourtant pas tant de couches à traverser que ça, et en plus, les fichiers Mac peuvent utiliser des méta-données ! Pour le coup, il n'y a pas vraiment de raison technique à ce que ça marche aussi mal.
La gestion des liens unix sous HFS+ est une daube, effectivement.
Oh que oui.
Ça, plus le mélange dans les casses, qui impacte le shell. Je rappelle l'exemple :
# ls PIM pam poum # ls pim pim # ls p*m pam poum
(février 2001)
-- David
Éric Lévénez
Le 2/12/03 8:18, dans <1g5bwdd.1x7atb7a1ned2N@[192.168.0.120]>, « David Andriana » a écrit :
Tu es sûr que le problème vient de Terminal ? Pas du shell ?
Non. J'ai dit que j'avais déjà eu ce problème avec un bug HFS+ dans le file system. En ce qui concerne les applis, les problèmes d'accents viennent de l'interaction Terminal / appli (ex shell).
D'autre part, "une suite d'octets valide" laisse penser que ça marchera par hasard.
Non, je parlais de suite d'octets UTF-8.
Pas de contrôles amonts, pas de conversion rigoureuse préalable. Il n'y a pourtant pas tant de couches à traverser que ça, et en plus, les fichiers Mac peuvent utiliser des méta-données !
Heu ? Quel rapport ?
Pour le coup, il n'y a pas vraiment de raison technique à ce que ça marche aussi mal.
HFS+ est une grosse raison.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 2/12/03 8:18, dans <1g5bwdd.1x7atb7a1ned2N@[192.168.0.120]>, « David
Andriana » <david.andriana@free.fr> a écrit :
Tu es sûr que le problème vient de Terminal ? Pas du shell ?
Non. J'ai dit que j'avais déjà eu ce problème avec un bug HFS+ dans le file
system. En ce qui concerne les applis, les problèmes d'accents viennent de
l'interaction Terminal / appli (ex shell).
D'autre part, "une suite d'octets valide" laisse penser que ça marchera
par hasard.
Non, je parlais de suite d'octets UTF-8.
Pas de contrôles amonts, pas de conversion rigoureuse
préalable. Il n'y a pourtant pas tant de couches à traverser que ça, et
en plus, les fichiers Mac peuvent utiliser des méta-données !
Heu ? Quel rapport ?
Pour le
coup, il n'y a pas vraiment de raison technique à ce que ça marche aussi
mal.
HFS+ est une grosse raison.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 2/12/03 8:18, dans <1g5bwdd.1x7atb7a1ned2N@[192.168.0.120]>, « David Andriana » a écrit :
Tu es sûr que le problème vient de Terminal ? Pas du shell ?
Non. J'ai dit que j'avais déjà eu ce problème avec un bug HFS+ dans le file system. En ce qui concerne les applis, les problèmes d'accents viennent de l'interaction Terminal / appli (ex shell).
D'autre part, "une suite d'octets valide" laisse penser que ça marchera par hasard.
Non, je parlais de suite d'octets UTF-8.
Pas de contrôles amonts, pas de conversion rigoureuse préalable. Il n'y a pourtant pas tant de couches à traverser que ça, et en plus, les fichiers Mac peuvent utiliser des méta-données !
Heu ? Quel rapport ?
Pour le coup, il n'y a pas vraiment de raison technique à ce que ça marche aussi mal.
HFS+ est une grosse raison.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
pmanet
Éric Lévénez wrote:
Ainsi un programme unix standard qui génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément valide.
ah j'ai un programme JAVA qui fonctionne parfaitement sous PC, démarre tout à fait normalement mais se vautre sur OSX au moment d'écrire son fichier de résultat ; ça pourrait correspondre ?
-- Philippe Manet
Éric Lévénez <news@levenez.com> wrote:
Ainsi un programme unix standard qui
génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra
avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS
attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément
valide.
ah
j'ai un programme JAVA qui fonctionne parfaitement sous PC, démarre tout
à fait normalement mais se vautre sur OSX au moment d'écrire son fichier
de résultat ; ça pourrait correspondre ?
Ainsi un programme unix standard qui génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément valide.
ah j'ai un programme JAVA qui fonctionne parfaitement sous PC, démarre tout à fait normalement mais se vautre sur OSX au moment d'écrire son fichier de résultat ; ça pourrait correspondre ?
-- Philippe Manet
Éric Lévénez
Le 2/12/03 20:04, dans <200312022004545769908@[10.0.0.1]>, « manet » a écrit :
Éric Lévénez wrote:
Ainsi un programme unix standard qui génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément valide.
ah j'ai un programme JAVA qui fonctionne parfaitement sous PC, démarre tout à fait normalement mais se vautre sur OSX au moment d'écrire son fichier de résultat ; ça pourrait correspondre ?
Je ne sais pas. Normalement java utilise l'unicode, alors si le JVM est bien faire, le nom du fichier devrait bien être traduit. Qui plante ? Est-ce l'interpréteur java ou le programme java, qu'elles sont les messages... Quel est le nom du fichier résultat ? As-tu essayé sur une partition UFS ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 2/12/03 20:04, dans <200312022004545769908@[10.0.0.1]>, « manet »
<pmanet@invivo.edu> a écrit :
Éric Lévénez <news@levenez.com> wrote:
Ainsi un programme unix standard qui
génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra
avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS
attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément
valide.
ah
j'ai un programme JAVA qui fonctionne parfaitement sous PC, démarre tout
à fait normalement mais se vautre sur OSX au moment d'écrire son fichier
de résultat ; ça pourrait correspondre ?
Je ne sais pas. Normalement java utilise l'unicode, alors si le JVM est bien
faire, le nom du fichier devrait bien être traduit. Qui plante ? Est-ce
l'interpréteur java ou le programme java, qu'elles sont les messages... Quel
est le nom du fichier résultat ? As-tu essayé sur une partition UFS ?
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 2/12/03 20:04, dans <200312022004545769908@[10.0.0.1]>, « manet » a écrit :
Éric Lévénez wrote:
Ainsi un programme unix standard qui génère un nom de fichiers avec du 8 bits (par exemple en ISO 8859-1) pourra avoir une erreur lors de la création (ou de l'ouverture) car la couche VFS attend de l'Unicode, et en Unicode toutes suite d'octets n'est pas forcément valide.
ah j'ai un programme JAVA qui fonctionne parfaitement sous PC, démarre tout à fait normalement mais se vautre sur OSX au moment d'écrire son fichier de résultat ; ça pourrait correspondre ?
Je ne sais pas. Normalement java utilise l'unicode, alors si le JVM est bien faire, le nom du fichier devrait bien être traduit. Qui plante ? Est-ce l'interpréteur java ou le programme java, qu'elles sont les messages... Quel est le nom du fichier résultat ? As-tu essayé sur une partition UFS ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
david.andriana
Éric Lévénez wrote:
en plus, les fichiers Mac peuvent utiliser des méta-données !
Heu ? Quel rapport ?
On peut indiquer en annexe du fichier comment il est encodé. Cela pour faciliter le travail des diverses couches de conversion.
Pour le coup, il n'y a pas vraiment de raison technique à ce que ça marche aussi mal.
HFS+ est une grosse raison.
Pas d'accord : HFS+ est une contrainte qui oblige à faire d'une certaine façon, pas une raison de mal faire.
-- David
Éric Lévénez <news@levenez.com> wrote:
en plus, les fichiers Mac peuvent utiliser des méta-données !
Heu ? Quel rapport ?
On peut indiquer en annexe du fichier comment il est encodé. Cela pour
faciliter le travail des diverses couches de conversion.
Pour le
coup, il n'y a pas vraiment de raison technique à ce que ça marche aussi
mal.
HFS+ est une grosse raison.
Pas d'accord : HFS+ est une contrainte qui oblige à faire d'une certaine
façon, pas une raison de mal faire.
en plus, les fichiers Mac peuvent utiliser des méta-données !
Heu ? Quel rapport ?
On peut indiquer en annexe du fichier comment il est encodé. Cela pour faciliter le travail des diverses couches de conversion.
Pour le coup, il n'y a pas vraiment de raison technique à ce que ça marche aussi mal.
HFS+ est une grosse raison.
Pas d'accord : HFS+ est une contrainte qui oblige à faire d'une certaine façon, pas une raison de mal faire.
-- David
david.andriana
manet wrote:
j'ai un programme JAVA qui fonctionne parfaitement sous PC, démarre tout à fait normalement mais se vautre sur OSX au moment d'écrire son fichier de résultat ; ça pourrait correspondre ?
Quel est le nom de ce fichier de résultat ?
-- David
manet <pmanet@invivo.edu> wrote:
j'ai un programme JAVA qui fonctionne parfaitement sous PC, démarre tout
à fait normalement mais se vautre sur OSX au moment d'écrire son fichier
de résultat ; ça pourrait correspondre ?
j'ai un programme JAVA qui fonctionne parfaitement sous PC, démarre tout à fait normalement mais se vautre sur OSX au moment d'écrire son fichier de résultat ; ça pourrait correspondre ?
