Ubuntu 12.10 iconv ne supporte tjs pas UTF-8-MAC ?
45 réponses
Une Bévue
si je fais :
$ iconv -l | grep MAC
CSISO111ECMACYRILLIC//
CSMACINTOSH//
ECMACYRILLIC//
MAC-CENTRALEUROPE//
MAC-CYRILLIC//
MAC-IS//
MAC-SAMI//
MAC-UK//
MAC//
MACCYRILLIC//
MACINTOSH//
MACIS//
MACUK//
MACUKRAINIAN//
MS-MAC-CYRILLIC//
MSMACCYRILLIC//
il n'est pas listé UTF-8-MAC, pourtant déjà en 2004 quelqu'un le
réclamait pour Debian :
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272727>
c'est génant pour faire du rsync car un fichier :
cachée.html (sur mac)
devient :
cacheé.html (sur linux)
(l'accent aigu a été déplacé au caractère suivant)
aussi rsync "pense" ne pas avoir up/downloadé le fichier...
Une Bévue , dans le message <50a92c5d$0$6136$, a écrit :
il n'est pas listé UTF-8-MAC
Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a aucune raison d'être supporté par iconv.
Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode sous forme canonique décomposée, parce que apple ne pouvait pas décemment utiliser la forme canonique composée comme tout le monde, ça aurait rendu l'interopérabilité trop facile.
c'est génant pour faire du rsync car un fichier : cachée.html (sur mac) devient : cacheé.html (sur linux) (l'accent aigu a été déplacé au caractère suivant)
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.
Accessoirement :
# 3.276 Portable Filename Character Set # # The set of characters from which portable filenames are constructed. # # A B C D E F G H I J K L M N O P Q R S T U V W X Y Z # a b c d e f g h i j k l m n o p q r s t u v w x y z # 0 1 2 3 4 5 6 7 8 9 . _ - # # The last three characters are the <period>, <underscore>, and <hyphen> # characters, respectively.
Sinon, c'est que tu cherches les ennuis.
Une Bévue , dans le message <50a92c5d$0$6136$426a34cc@news.free.fr>, a
écrit :
il n'est pas listé UTF-8-MAC
Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a
aucune raison d'être supporté par iconv.
Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode
sous forme canonique décomposée, parce que apple ne pouvait pas décemment
utiliser la forme canonique composée comme tout le monde, ça aurait rendu
l'interopérabilité trop facile.
c'est génant pour faire du rsync car un fichier :
cachée.html (sur mac)
devient :
cacheé.html (sur linux)
(l'accent aigu a été déplacé au caractère suivant)
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas
FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.
Accessoirement :
# 3.276 Portable Filename Character Set
#
# The set of characters from which portable filenames are constructed.
#
# A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
# a b c d e f g h i j k l m n o p q r s t u v w x y z
# 0 1 2 3 4 5 6 7 8 9 . _ -
#
# The last three characters are the <period>, <underscore>, and <hyphen>
# characters, respectively.
Une Bévue , dans le message <50a92c5d$0$6136$, a écrit :
il n'est pas listé UTF-8-MAC
Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a aucune raison d'être supporté par iconv.
Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode sous forme canonique décomposée, parce que apple ne pouvait pas décemment utiliser la forme canonique composée comme tout le monde, ça aurait rendu l'interopérabilité trop facile.
c'est génant pour faire du rsync car un fichier : cachée.html (sur mac) devient : cacheé.html (sur linux) (l'accent aigu a été déplacé au caractère suivant)
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.
Accessoirement :
# 3.276 Portable Filename Character Set # # The set of characters from which portable filenames are constructed. # # A B C D E F G H I J K L M N O P Q R S T U V W X Y Z # a b c d e f g h i j k l m n o p q r s t u v w x y z # 0 1 2 3 4 5 6 7 8 9 . _ - # # The last three characters are the <period>, <underscore>, and <hyphen> # characters, respectively.
Sinon, c'est que tu cherches les ennuis.
Erwan David
Nicolas George <nicolas$ écrivait :
Une Bévue , dans le message <50a92c5d$0$6136$, a écrit :
il n'est pas listé UTF-8-MAC
Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a aucune raison d'être supporté par iconv.
Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode sous forme canonique décomposée, parce que apple ne pouvait pas décemment utiliser la forme canonique composée comme tout le monde, ça aurait rendu l'interopérabilité trop facile.
c'est génant pour faire du rsync car un fichier : cachée.html (sur mac) devient : cacheé.html (sur linux) (l'accent aigu a été déplacé au caractère suivant)
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.
Certes, mais l'option de rsync sers à ce que le nom de fichier soit correctement converti selon les FS de départ et d'arrivée.
-- Les simplifications c'est trop compliqué
Nicolas George <nicolas$george@salle-s.org> écrivait :
Une Bévue , dans le message <50a92c5d$0$6136$426a34cc@news.free.fr>, a
écrit :
il n'est pas listé UTF-8-MAC
Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a
aucune raison d'être supporté par iconv.
Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode
sous forme canonique décomposée, parce que apple ne pouvait pas décemment
utiliser la forme canonique composée comme tout le monde, ça aurait rendu
l'interopérabilité trop facile.
c'est génant pour faire du rsync car un fichier :
cachée.html (sur mac)
devient :
cacheé.html (sur linux)
(l'accent aigu a été déplacé au caractère suivant)
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas
FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.
Certes, mais l'option de rsync sers à ce que le nom de fichier soit
correctement converti selon les FS de départ et d'arrivée.
Une Bévue , dans le message <50a92c5d$0$6136$, a écrit :
il n'est pas listé UTF-8-MAC
Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a aucune raison d'être supporté par iconv.
Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode sous forme canonique décomposée, parce que apple ne pouvait pas décemment utiliser la forme canonique composée comme tout le monde, ça aurait rendu l'interopérabilité trop facile.
c'est génant pour faire du rsync car un fichier : cachée.html (sur mac) devient : cacheé.html (sur linux) (l'accent aigu a été déplacé au caractère suivant)
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.
Certes, mais l'option de rsync sers à ce que le nom de fichier soit correctement converti selon les FS de départ et d'arrivée.
-- Les simplifications c'est trop compliqué
Une Bévue
Le 18/11/12 20:59, Nicolas George a écrit :
il n'est pas listé UTF-8-MAC
Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a aucune raison d'être supporté par iconv.
ben si je lis la FAQ <http://rsync.samba.org/FAQ.html> : You can avoid a charset problem by passing an appropriate --iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using --iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).
et sur Mac OS X Mountain Lion : iconv -l | grep MAC UTF-8-MAC UTF8-MAC MAC MACINTOSH MACROMAN CSMACINTOSH ...
Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode sous forme canonique décomposée, parce que apple ne pouvait pas décemment utiliser la forme canonique composée comme tout le monde, ça aurait rendu l'interopérabilité trop facile.
c'est pas du tout ça, le décomposé est un truc sioux, mais emmerdant il est vrai, qui permet de faire un sort alphabétique + rapidement.
>c'est génant pour faire du rsync car un fichier : >cachée.html (sur mac) >devient : >cacheé.html (sur linux) >(l'accent aigu a été déplacé au caractère suivant)
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.
Accessoirement :
# 3.276 Portable Filename Character Set
ouais, d'accord, mais, ce n'est pas moi qui ai choisi ces filenames et quand même cette politique, même si je la pratique en enlevant tous les signes diacritiques, dans les filenames, cette politique est pou le moins viellotte, les chinois ont maintenant des FDQN en chinois, c'est quand même plus respectueux de la diversité...
Le 18/11/12 20:59, Nicolas George a écrit :
il n'est pas listé UTF-8-MAC
Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a
aucune raison d'être supporté par iconv.
ben si je lis la FAQ <http://rsync.samba.org/FAQ.html> :
You can avoid a charset problem by passing an appropriate --iconv option
to rsync that tells it what character-set the source files are, and what
character-set the destination files get stored in. For instance, the
above Mac OS X problem would be dealt with by using
--iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac
OS X iconv in which all characters are decomposed).
et sur Mac OS X Mountain Lion :
iconv -l | grep MAC
UTF-8-MAC UTF8-MAC
MAC MACINTOSH MACROMAN CSMACINTOSH
...
Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode
sous forme canonique décomposée, parce que apple ne pouvait pas décemment
utiliser la forme canonique composée comme tout le monde, ça aurait rendu
l'interopérabilité trop facile.
c'est pas du tout ça, le décomposé est un truc sioux, mais emmerdant il
est vrai, qui permet de faire un sort alphabétique + rapidement.
>c'est génant pour faire du rsync car un fichier :
>cachée.html (sur mac)
>devient :
>cacheé.html (sur linux)
>(l'accent aigu a été déplacé au caractère suivant)
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas
FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.
Accessoirement :
# 3.276 Portable Filename Character Set
ouais, d'accord, mais, ce n'est pas moi qui ai choisi ces filenames et
quand même cette politique, même si je la pratique en enlevant tous les
signes diacritiques, dans les filenames, cette politique est pou le
moins viellotte, les chinois ont maintenant des FDQN en chinois, c'est
quand même plus respectueux de la diversité...
Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a aucune raison d'être supporté par iconv.
ben si je lis la FAQ <http://rsync.samba.org/FAQ.html> : You can avoid a charset problem by passing an appropriate --iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using --iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).
et sur Mac OS X Mountain Lion : iconv -l | grep MAC UTF-8-MAC UTF8-MAC MAC MACINTOSH MACROMAN CSMACINTOSH ...
Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode sous forme canonique décomposée, parce que apple ne pouvait pas décemment utiliser la forme canonique composée comme tout le monde, ça aurait rendu l'interopérabilité trop facile.
c'est pas du tout ça, le décomposé est un truc sioux, mais emmerdant il est vrai, qui permet de faire un sort alphabétique + rapidement.
>c'est génant pour faire du rsync car un fichier : >cachée.html (sur mac) >devient : >cacheé.html (sur linux) >(l'accent aigu a été déplacé au caractère suivant)
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.
Accessoirement :
# 3.276 Portable Filename Character Set
ouais, d'accord, mais, ce n'est pas moi qui ai choisi ces filenames et quand même cette politique, même si je la pratique en enlevant tous les signes diacritiques, dans les filenames, cette politique est pou le moins viellotte, les chinois ont maintenant des FDQN en chinois, c'est quand même plus respectueux de la diversité...
Une Bévue
Le 18/11/12 21:46, Erwan David a écrit :
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas >FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage. >
Certes, mais l'option de rsync sers à ce que le nom de fichier soit correctement converti selon les FS de départ et d'arrivée.
Non, c'est faux d'ailleurs rsync ne se fiche pas de l'encodage, (voir la FAQ) car il est incapable de faire une sync entre deux fs à encodage différent sans iconv.
Le 18/11/12 21:46, Erwan David a écrit :
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas
>FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.
>
Certes, mais l'option de rsync sers à ce que le nom de fichier soit
correctement converti selon les FS de départ et d'arrivée.
Non, c'est faux d'ailleurs rsync ne se fiche pas de l'encodage, (voir la
FAQ) car il est incapable de faire une sync entre deux fs à encodage
différent sans iconv.
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas >FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage. >
Certes, mais l'option de rsync sers à ce que le nom de fichier soit correctement converti selon les FS de départ et d'arrivée.
Non, c'est faux d'ailleurs rsync ne se fiche pas de l'encodage, (voir la FAQ) car il est incapable de faire une sync entre deux fs à encodage différent sans iconv.
Nicolas George
Une Bévue , dans le message <50a9d52f$0$2289$, a écrit :
You can avoid a charset problem by passing an appropriate --iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using --iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).
Il n'y a pas de notion d'encodage des noms de fichiers sous Unix, les noms de fichiers sont des suites d'octets, point.
et sur Mac OS X Mountain Lion :
macos est une caricature d'Unix, il ne faut pas le prendre comme référence.
c'est pas du tout ça, le décomposé est un truc sioux, mais emmerdant il est vrai, qui permet de faire un sort alphabétique + rapidement.
Ça, c'est ce qu'on dit aux macounets un peu moins endoctrinés que les autres qui sont capables de se rendre compte du problème, mais pas de comprendre que c'est du pipo.
ouais, d'accord, mais, ce n'est pas moi qui ai choisi ces filenames et
Ils sont sur ton ordinateur, non ?
quand même cette politique, même si je la pratique en enlevant tous les signes diacritiques, dans les filenames, cette politique est pou le moins viellotte, les chinois ont maintenant des FDQN en chinois, c'est quand même plus respectueux de la diversité...
Les Chinois font ce qu'ils veulent, s'ils veulent des ennuis d'encodage c'est leur problème.
Une Bévue , dans le message <50a9d52f$0$2289$426a34cc@news.free.fr>, a
écrit :
You can avoid a charset problem by passing an appropriate --iconv option
to rsync that tells it what character-set the source files are, and what
character-set the destination files get stored in. For instance, the
above Mac OS X problem would be dealt with by using
--iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac
OS X iconv in which all characters are decomposed).
Il n'y a pas de notion d'encodage des noms de fichiers sous Unix, les noms
de fichiers sont des suites d'octets, point.
et sur Mac OS X Mountain Lion :
macos est une caricature d'Unix, il ne faut pas le prendre comme référence.
c'est pas du tout ça, le décomposé est un truc sioux, mais emmerdant il
est vrai, qui permet de faire un sort alphabétique + rapidement.
Ça, c'est ce qu'on dit aux macounets un peu moins endoctrinés que les autres
qui sont capables de se rendre compte du problème, mais pas de comprendre
que c'est du pipo.
ouais, d'accord, mais, ce n'est pas moi qui ai choisi ces filenames et
Ils sont sur ton ordinateur, non ?
quand même cette politique, même si je la pratique en enlevant tous les
signes diacritiques, dans les filenames, cette politique est pou le
moins viellotte, les chinois ont maintenant des FDQN en chinois, c'est
quand même plus respectueux de la diversité...
Les Chinois font ce qu'ils veulent, s'ils veulent des ennuis d'encodage
c'est leur problème.
Une Bévue , dans le message <50a9d52f$0$2289$, a écrit :
You can avoid a charset problem by passing an appropriate --iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using --iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).
Il n'y a pas de notion d'encodage des noms de fichiers sous Unix, les noms de fichiers sont des suites d'octets, point.
et sur Mac OS X Mountain Lion :
macos est une caricature d'Unix, il ne faut pas le prendre comme référence.
c'est pas du tout ça, le décomposé est un truc sioux, mais emmerdant il est vrai, qui permet de faire un sort alphabétique + rapidement.
Ça, c'est ce qu'on dit aux macounets un peu moins endoctrinés que les autres qui sont capables de se rendre compte du problème, mais pas de comprendre que c'est du pipo.
ouais, d'accord, mais, ce n'est pas moi qui ai choisi ces filenames et
Ils sont sur ton ordinateur, non ?
quand même cette politique, même si je la pratique en enlevant tous les signes diacritiques, dans les filenames, cette politique est pou le moins viellotte, les chinois ont maintenant des FDQN en chinois, c'est quand même plus respectueux de la diversité...
Les Chinois font ce qu'ils veulent, s'ils veulent des ennuis d'encodage c'est leur problème.
Une Bévue
Le 19/11/2012 18:01, Nicolas George a écrit :
Ils sont sur ton ordinateur, non ?
ben qu'en j'enregistre un cd par exemple du "Pražák Quartet" je ne vais pas aller changer le nom du dossier, c'est automatique point barre.
bon là, je ne sais pas ce qui va se passer avec les signes diacritiques compte tenu du fait que mon FAI est free et que j'utilise Thunderbird sous Xubuntu, mais cet exemple précis j'ai : "Prazak Quartet" disons US ascii sur Xubuntu le signe diacritique qui ressemble à un v est sur le z alors que sur mon mac il est sur le a qui précède de même l'accent aigu sur le a qui suit est sur le z sur mac.
et ça ça me fait singulièrement chier, ya pas d'autre mot parce que je ne peux pas faire du rsync comme je veux.
rsync, avec l'option iconv, s'en dépatouille bien côté mac mais côté linux, ça mouline dans la choucroute, enfin j'ai des doublons et des trucs qui sont téléchargés plusieurs fois.
Le 19/11/2012 18:01, Nicolas George a écrit :
Ils sont sur ton ordinateur, non ?
ben qu'en j'enregistre un cd par exemple du "Pražák Quartet" je ne vais
pas aller changer le nom du dossier, c'est automatique point barre.
bon là, je ne sais pas ce qui va se passer avec les signes diacritiques
compte tenu du fait que mon FAI est free et que j'utilise Thunderbird
sous Xubuntu, mais cet exemple précis j'ai :
"Prazak Quartet" disons US ascii
sur Xubuntu le signe diacritique qui ressemble à un v est sur le z alors
que sur mon mac il est sur le a qui précède de même l'accent aigu sur le
a qui suit est sur le z sur mac.
et ça ça me fait singulièrement chier, ya pas d'autre mot parce que je
ne peux pas faire du rsync comme je veux.
rsync, avec l'option iconv, s'en dépatouille bien côté mac mais côté
linux, ça mouline dans la choucroute, enfin j'ai des doublons et des
trucs qui sont téléchargés plusieurs fois.
ben qu'en j'enregistre un cd par exemple du "Pražák Quartet" je ne vais pas aller changer le nom du dossier, c'est automatique point barre.
bon là, je ne sais pas ce qui va se passer avec les signes diacritiques compte tenu du fait que mon FAI est free et que j'utilise Thunderbird sous Xubuntu, mais cet exemple précis j'ai : "Prazak Quartet" disons US ascii sur Xubuntu le signe diacritique qui ressemble à un v est sur le z alors que sur mon mac il est sur le a qui précède de même l'accent aigu sur le a qui suit est sur le z sur mac.
et ça ça me fait singulièrement chier, ya pas d'autre mot parce que je ne peux pas faire du rsync comme je veux.
rsync, avec l'option iconv, s'en dépatouille bien côté mac mais côté linux, ça mouline dans la choucroute, enfin j'ai des doublons et des trucs qui sont téléchargés plusieurs fois.
Erwan David
Nicolas George <nicolas$ écrivait :
Une Bévue , dans le message <50a9d52f$0$2289$, a écrit :
You can avoid a charset problem by passing an appropriate --iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using --iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).
Il n'y a pas de notion d'encodage des noms de fichiers sous Unix, les noms de fichiers sont des suites d'octets, point.
Et quand tu f ais un ls, ce qu'il affiche c'est quoi ?
Non ce n'est pas une suite d'octest, c'est une suite de caractères, idem pour un open.
-- Les simplifications c'est trop compliqué
Nicolas George <nicolas$george@salle-s.org> écrivait :
Une Bévue , dans le message <50a9d52f$0$2289$426a34cc@news.free.fr>, a
écrit :
You can avoid a charset problem by passing an appropriate --iconv option
to rsync that tells it what character-set the source files are, and what
character-set the destination files get stored in. For instance, the
above Mac OS X problem would be dealt with by using
--iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac
OS X iconv in which all characters are decomposed).
Il n'y a pas de notion d'encodage des noms de fichiers sous Unix, les noms
de fichiers sont des suites d'octets, point.
Et quand tu f ais un ls, ce qu'il affiche c'est quoi ?
Non ce n'est pas une suite d'octest, c'est une suite de caractères, idem
pour un open.
Une Bévue , dans le message <50a9d52f$0$2289$, a écrit :
You can avoid a charset problem by passing an appropriate --iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using --iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).
Il n'y a pas de notion d'encodage des noms de fichiers sous Unix, les noms de fichiers sont des suites d'octets, point.
Et quand tu f ais un ls, ce qu'il affiche c'est quoi ?
Non ce n'est pas une suite d'octest, c'est une suite de caractères, idem pour un open.
-- Les simplifications c'est trop compliqué
Une Bévue
Le 19/11/2012 18:27, Erwan David a écrit :
Et quand tu f ais un ls, ce qu'il affiche c'est quoi ?
Côté xubuntu : $ ls Pra* Pražák Quartet - Arnold Schönberg
Non ce n'est pas une suite d'octest, c'est une suite de caractères, idem pour un open.
ben oui il y a des découpages...
Le 19/11/2012 18:27, Erwan David a écrit :
Et quand tu f ais un ls, ce qu'il affiche c'est quoi ?
Côté xubuntu :
$ ls Pra*
Pražák Quartet - Arnold Schönberg
Non ce n'est pas une suite d'octest, c'est une suite de caractères, idem
pour un open.
Et quand tu f ais un ls, ce qu'il affiche c'est quoi ?
Côté xubuntu : $ ls Pra* Pražák Quartet - Arnold Schönberg
Non ce n'est pas une suite d'octest, c'est une suite de caractères, idem pour un open.
ben oui il y a des découpages...
jp willm
Hello,
Le 19/11/2012 18:22, Une Bévue a écrit :
ben qu'en j'enregistre un cd par exemple du "Pražák Quartet" je ne vais pas aller changer le nom du dossier, c'est automatique point barre.
Un fichier "mal" nommé peut tôt ou tard poser problème.
Je mouline le tout avec pyrenamer ou gprename pour supprimer les accents, les espaces et pour tout mettre en minuscule (extensions comprises, car sous gtk les photos sont toujours importées avec des extensions en majuscule).
ben qu'en j'enregistre un cd par exemple du "Pražák Quartet" je ne vais
pas aller changer le nom du dossier, c'est automatique point barre.
Un fichier "mal" nommé peut tôt ou tard poser problème.
Je mouline le tout avec pyrenamer ou gprename pour supprimer les
accents, les espaces et pour tout mettre en minuscule (extensions
comprises, car sous gtk les photos sont toujours importées avec des
extensions en majuscule).
ben qu'en j'enregistre un cd par exemple du "Pražák Quartet" je ne vais pas aller changer le nom du dossier, c'est automatique point barre.
Un fichier "mal" nommé peut tôt ou tard poser problème.
Je mouline le tout avec pyrenamer ou gprename pour supprimer les accents, les espaces et pour tout mettre en minuscule (extensions comprises, car sous gtk les photos sont toujours importées avec des extensions en majuscule).
