si je cr=E9e un dossier avec des caract=E8res Unicode :
$> mkdir =E9t=E9
ou :
$> touch =E9t=E9.txt
si je fais un mdls l=E0-dessus, pas de pb, j'imagine que c'est Apple qui
a con=E7u le mdls (?)
le mdls confirme que touch et mkdir "passent" avec des caract=E8res
unicode
mdls affiche d'ailleurs de deux maniers ce path :
=E9t=E9 ou "e' te' "
par contre si je fais un stat dessus, stat trouve que le r=E9pertoire
comme le fichier n'existent pas, j'imagine que c'est du =E0 une
comparaison interne (???) bien s=FBr pour passer l'argument du path je
suis obliger, avec stat de faire un cast (char *) (au lieu d'avoir
wchar_t)
donc ma question, est-ce qu'il existe des fonctions telles que stat
and Co en wchar_t ??? comme il existe des fonctions pour les strings
en multi-bytes.
Dans l'article <C2EB7F08.B0504%, Eric Levenez écrit:
Le 17/08/07 15:07, dans <20070817125547$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EB2414.B045B%, Eric Levenez écrit:
Je préfère l'impémentation Apple du système où tout est en UTF-8
HFS+ est en UTF-8.
Il est en UTF-16.
Peut-être en interne, mais l'utilisateur s'en f... L'interface est en UTF-8, i.e. si l'utilisateur tape 'touch é' pour créer un fichier 'é', le 'é' doit obligatoirement être codé en UTF-8.
plutôt que celle des autres BSD ou de Linux où des conversions dans tous les sens sont ou devraient être fait. Chacun son truc je le répète, je préfère voir les caractères des fichiers tels qu'ils sont.
Justement, tu ne les vois pas tels qu'ils sont avec le /bin/ls.
Avec ton ls du GNU qui lui aussi masque certains caractères.
Le ls de GNU affiche *tous* les caractères imprimables, quelles que soient les options.
La norme Posix n'impose pas d'avoir plusieurs locales et donc les defines type LC_CTYPE peuvent ne pas avoir d'effet. Alors pour la compatibilité Posix, merci de repasser :-)
Les locales sont définies par le système. Dans la mesure où Apple supporte UTF-8, et que c'est même la locale du système de fichiers HFS+, ls /bin/ls doit la supporter.
Il n'y a aucun problème à part ceux que tu te poses toi-même.
Si, il y a un bug dans le /bin/ls, comme je l'ai clairement expliqué. T'es bouché, mais je n'y peux rien.
Dans l'article <C2EB7F08.B0504%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Le 17/08/07 15:07, dans <20070817125547$26ae@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2EB2414.B045B%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Je préfère l'impémentation Apple du système où tout est en UTF-8
HFS+ est en UTF-8.
Il est en UTF-16.
Peut-être en interne, mais l'utilisateur s'en f... L'interface est en
UTF-8, i.e. si l'utilisateur tape 'touch é' pour créer un fichier 'é',
le 'é' doit obligatoirement être codé en UTF-8.
plutôt que celle des autres BSD ou de Linux où des conversions dans
tous les sens sont ou devraient être fait. Chacun son truc je le
répète, je préfère voir les caractères des fichiers tels qu'ils
sont.
Justement, tu ne les vois pas tels qu'ils sont avec le /bin/ls.
Avec ton ls du GNU qui lui aussi masque certains caractères.
Le ls de GNU affiche *tous* les caractères imprimables, quelles que
soient les options.
La norme Posix n'impose pas d'avoir plusieurs locales et donc les
defines type LC_CTYPE peuvent ne pas avoir d'effet. Alors pour la
compatibilité Posix, merci de repasser :-)
Les locales sont définies par le système. Dans la mesure où Apple
supporte UTF-8, et que c'est même la locale du système de fichiers
HFS+, ls /bin/ls doit la supporter.
Il n'y a aucun problème à part ceux que tu te poses toi-même.
Si, il y a un bug dans le /bin/ls, comme je l'ai clairement expliqué.
T'es bouché, mais je n'y peux rien.
Dans l'article <C2EB7F08.B0504%, Eric Levenez écrit:
Le 17/08/07 15:07, dans <20070817125547$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EB2414.B045B%, Eric Levenez écrit:
Je préfère l'impémentation Apple du système où tout est en UTF-8
HFS+ est en UTF-8.
Il est en UTF-16.
Peut-être en interne, mais l'utilisateur s'en f... L'interface est en UTF-8, i.e. si l'utilisateur tape 'touch é' pour créer un fichier 'é', le 'é' doit obligatoirement être codé en UTF-8.
plutôt que celle des autres BSD ou de Linux où des conversions dans tous les sens sont ou devraient être fait. Chacun son truc je le répète, je préfère voir les caractères des fichiers tels qu'ils sont.
Justement, tu ne les vois pas tels qu'ils sont avec le /bin/ls.
Avec ton ls du GNU qui lui aussi masque certains caractères.
Le ls de GNU affiche *tous* les caractères imprimables, quelles que soient les options.
La norme Posix n'impose pas d'avoir plusieurs locales et donc les defines type LC_CTYPE peuvent ne pas avoir d'effet. Alors pour la compatibilité Posix, merci de repasser :-)
Les locales sont définies par le système. Dans la mesure où Apple supporte UTF-8, et que c'est même la locale du système de fichiers HFS+, ls /bin/ls doit la supporter.
Il n'y a aucun problème à part ceux que tu te poses toi-même.
Si, il y a un bug dans le /bin/ls, comme je l'ai clairement expliqué. T'es bouché, mais je n'y peux rien.
Le 18/08/07 0:51, dans <20070817224610$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EB7F08.B0504%, Eric Levenez écrit:
Le 17/08/07 15:07, dans <20070817125547$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EB2414.B045B%, Eric Levenez écrit:
Je préfère l'impémentation Apple du système où tout est en UTF-8
HFS+ est en UTF-8.
Il est en UTF-16.
Peut-être en interne, mais l'utilisateur s'en f... L'interface est en UTF-8, i.e. si l'utilisateur tape 'touch é' pour créer un fichier 'é', le 'é' doit obligatoirement être codé en UTF-8.
Idem si on accède à un système du type FAT32...
plutôt que celle des autres BSD ou de Linux où des conversions dans tous les sens sont ou devraient être fait. Chacun son truc je le répète, je préfère voir les caractères des fichiers tels qu'ils sont.
Justement, tu ne les vois pas tels qu'ils sont avec le /bin/ls.
Avec ton ls du GNU qui lui aussi masque certains caractères.
Le ls de GNU affiche *tous* les caractères imprimables, quelles que soient les options.
Il masque certains caractères, oui.
La norme Posix n'impose pas d'avoir plusieurs locales et donc les defines type LC_CTYPE peuvent ne pas avoir d'effet. Alors pour la compatibilité Posix, merci de repasser :-)
Les locales sont définies par le système. Dans la mesure où Apple supporte UTF-8, et que c'est même la locale du système de fichiers HFS+, ls /bin/ls doit la supporter.
Il n'y a aucun problème à part ceux que tu te poses toi-même.
Si, il y a un bug dans le /bin/ls, comme je l'ai clairement expliqué.
Disons ce que tu considères comme un bug, n'en est pas un pour moi. Tout comme le problème de sécurité que tu évoquais au départ. Il faudrait aussi interdire toutes les commandes qui affichent des noms de fichiers : find, echo...
T'es bouché, mais je n'y peux rien.
Je n'ai pas la même option que toi, c'est tout.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 18/08/07 0:51, dans <20070817224610$4efe@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2EB7F08.B0504%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Le 17/08/07 15:07, dans <20070817125547$26ae@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2EB2414.B045B%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Je préfère l'impémentation Apple du système où tout est en UTF-8
HFS+ est en UTF-8.
Il est en UTF-16.
Peut-être en interne, mais l'utilisateur s'en f... L'interface est en
UTF-8, i.e. si l'utilisateur tape 'touch é' pour créer un fichier 'é',
le 'é' doit obligatoirement être codé en UTF-8.
Idem si on accède à un système du type FAT32...
plutôt que celle des autres BSD ou de Linux où des conversions dans
tous les sens sont ou devraient être fait. Chacun son truc je le
répète, je préfère voir les caractères des fichiers tels qu'ils
sont.
Justement, tu ne les vois pas tels qu'ils sont avec le /bin/ls.
Avec ton ls du GNU qui lui aussi masque certains caractères.
Le ls de GNU affiche *tous* les caractères imprimables, quelles que
soient les options.
Il masque certains caractères, oui.
La norme Posix n'impose pas d'avoir plusieurs locales et donc les
defines type LC_CTYPE peuvent ne pas avoir d'effet. Alors pour la
compatibilité Posix, merci de repasser :-)
Les locales sont définies par le système. Dans la mesure où Apple
supporte UTF-8, et que c'est même la locale du système de fichiers
HFS+, ls /bin/ls doit la supporter.
Il n'y a aucun problème à part ceux que tu te poses toi-même.
Si, il y a un bug dans le /bin/ls, comme je l'ai clairement expliqué.
Disons ce que tu considères comme un bug, n'en est pas un pour moi. Tout
comme le problème de sécurité que tu évoquais au départ. Il faudrait aussi
interdire toutes les commandes qui affichent des noms de fichiers : find,
echo...
T'es bouché, mais je n'y peux rien.
Je n'ai pas la même option que toi, c'est tout.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 18/08/07 0:51, dans <20070817224610$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EB7F08.B0504%, Eric Levenez écrit:
Le 17/08/07 15:07, dans <20070817125547$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EB2414.B045B%, Eric Levenez écrit:
Je préfère l'impémentation Apple du système où tout est en UTF-8
HFS+ est en UTF-8.
Il est en UTF-16.
Peut-être en interne, mais l'utilisateur s'en f... L'interface est en UTF-8, i.e. si l'utilisateur tape 'touch é' pour créer un fichier 'é', le 'é' doit obligatoirement être codé en UTF-8.
Idem si on accède à un système du type FAT32...
plutôt que celle des autres BSD ou de Linux où des conversions dans tous les sens sont ou devraient être fait. Chacun son truc je le répète, je préfère voir les caractères des fichiers tels qu'ils sont.
Justement, tu ne les vois pas tels qu'ils sont avec le /bin/ls.
Avec ton ls du GNU qui lui aussi masque certains caractères.
Le ls de GNU affiche *tous* les caractères imprimables, quelles que soient les options.
Il masque certains caractères, oui.
La norme Posix n'impose pas d'avoir plusieurs locales et donc les defines type LC_CTYPE peuvent ne pas avoir d'effet. Alors pour la compatibilité Posix, merci de repasser :-)
Les locales sont définies par le système. Dans la mesure où Apple supporte UTF-8, et que c'est même la locale du système de fichiers HFS+, ls /bin/ls doit la supporter.
Il n'y a aucun problème à part ceux que tu te poses toi-même.
Si, il y a un bug dans le /bin/ls, comme je l'ai clairement expliqué.
Disons ce que tu considères comme un bug, n'en est pas un pour moi. Tout comme le problème de sécurité que tu évoquais au départ. Il faudrait aussi interdire toutes les commandes qui affichent des noms de fichiers : find, echo...
T'es bouché, mais je n'y peux rien.
Je n'ai pas la même option que toi, c'est tout.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <C2EC7A9B.B05C0%, Eric Levenez écrit:
Le 18/08/07 0:51, dans <20070817224610$, « Vincent Lefevre » <vincent+ a écrit :
Le ls de GNU affiche *tous* les caractères imprimables, quelles que soient les options.
Il masque certains caractères, oui.
Seulement les caractères non imprimables. Mais un 'é' par exemple n'est pas masqué, quelles que soient les options utilisées.
Si, il y a un bug dans le /bin/ls, comme je l'ai clairement expliqué.
Disons ce que tu considères comme un bug, n'en est pas un pour moi.
En tout cas, /bin/ls ne se comporte pas comme sa page man le décrit. Générer des séquences UTF-8 invalides (alors que les noms de fichier sont en UTF-8 valide) est un bug. J'ai soumis un rapport de bug il y a quelques jours sur le site d'Apple (aucune réponse pour le moment).
Tout comme le problème de sécurité que tu évoquais au départ. Il faudrait aussi interdire toutes les commandes qui affichent des noms de fichiers : find,
Justement, le find de GNU masque maintenant les caractères non imprimables lorsque la sortie se fait sur un terminal. Tu peux voir mon rapport de bug ici:
echo n'affiche pas des noms de fichier, mais seulement ce que lui donne l'utilisateur. C'est à l'utilisateur de faire le filtrage s'il en a envie. Mais echo est justement très souvent utilisé pour envoyer des séquences d'échappement au terminal.
Dans l'article <C2EC7A9B.B05C0%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Le 18/08/07 0:51, dans <20070817224610$4efe@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Le ls de GNU affiche *tous* les caractères imprimables, quelles que
soient les options.
Il masque certains caractères, oui.
Seulement les caractères non imprimables. Mais un 'é' par exemple
n'est pas masqué, quelles que soient les options utilisées.
Si, il y a un bug dans le /bin/ls, comme je l'ai clairement expliqué.
Disons ce que tu considères comme un bug, n'en est pas un pour moi.
En tout cas, /bin/ls ne se comporte pas comme sa page man le décrit.
Générer des séquences UTF-8 invalides (alors que les noms de fichier
sont en UTF-8 valide) est un bug. J'ai soumis un rapport de bug il y
a quelques jours sur le site d'Apple (aucune réponse pour le moment).
Tout comme le problème de sécurité que tu évoquais au départ. Il
faudrait aussi interdire toutes les commandes qui affichent des noms
de fichiers : find,
Justement, le find de GNU masque maintenant les caractères non
imprimables lorsque la sortie se fait sur un terminal. Tu peux
voir mon rapport de bug ici:
echo n'affiche pas des noms de fichier, mais seulement ce que lui
donne l'utilisateur. C'est à l'utilisateur de faire le filtrage
s'il en a envie. Mais echo est justement très souvent utilisé pour
envoyer des séquences d'échappement au terminal.
Dans l'article <C2EC7A9B.B05C0%, Eric Levenez écrit:
Le 18/08/07 0:51, dans <20070817224610$, « Vincent Lefevre » <vincent+ a écrit :
Le ls de GNU affiche *tous* les caractères imprimables, quelles que soient les options.
Il masque certains caractères, oui.
Seulement les caractères non imprimables. Mais un 'é' par exemple n'est pas masqué, quelles que soient les options utilisées.
Si, il y a un bug dans le /bin/ls, comme je l'ai clairement expliqué.
Disons ce que tu considères comme un bug, n'en est pas un pour moi.
En tout cas, /bin/ls ne se comporte pas comme sa page man le décrit. Générer des séquences UTF-8 invalides (alors que les noms de fichier sont en UTF-8 valide) est un bug. J'ai soumis un rapport de bug il y a quelques jours sur le site d'Apple (aucune réponse pour le moment).
Tout comme le problème de sécurité que tu évoquais au départ. Il faudrait aussi interdire toutes les commandes qui affichent des noms de fichiers : find,
Justement, le find de GNU masque maintenant les caractères non imprimables lorsque la sortie se fait sur un terminal. Tu peux voir mon rapport de bug ici:
echo n'affiche pas des noms de fichier, mais seulement ce que lui donne l'utilisateur. C'est à l'utilisateur de faire le filtrage s'il en a envie. Mais echo est justement très souvent utilisé pour envoyer des séquences d'échappement au terminal.
Le 19/08/07 18:35, dans <20070819162046$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EC7A9B.B05C0%, Eric Levenez écrit:
echo...
echo n'affiche pas des noms de fichier,
echo *
Et des commandes qui affichent des noms de fichiers ou d'exécutables, il y en a des dizaines, peut-être des centaines...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <C2EE54A9.B07AF%, Eric Levenez écrit:
Le 19/08/07 18:35, dans <20070819162046$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EC7A9B.B05C0%, Eric Levenez écrit:
echo...
echo n'affiche pas des noms de fichier,
echo *
C'est le shell qui transforme * en noms de fichier! La commande echo ne reçoit que des chaînes de caractères et est donc incapable de faire la différence entre une chaîne arbitraire et un nom de fichier. Et d'ailleurs, comme un nom de fichier peut être '-n', la commande "echo *" risque de ne pas toujours avoir l'effet escompté. Bref, avant d'utiliser une commande shell, l'utilisateur doit utiliser son cerveau.
Dans l'article <C2EE54A9.B07AF%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Le 19/08/07 18:35, dans <20070819162046$7d0f@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2EC7A9B.B05C0%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
echo...
echo n'affiche pas des noms de fichier,
echo *
C'est le shell qui transforme * en noms de fichier! La commande echo
ne reçoit que des chaînes de caractères et est donc incapable de faire
la différence entre une chaîne arbitraire et un nom de fichier. Et
d'ailleurs, comme un nom de fichier peut être '-n', la commande "echo *"
risque de ne pas toujours avoir l'effet escompté. Bref, avant d'utiliser
une commande shell, l'utilisateur doit utiliser son cerveau.
Dans l'article <C2EE54A9.B07AF%, Eric Levenez écrit:
Le 19/08/07 18:35, dans <20070819162046$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EC7A9B.B05C0%, Eric Levenez écrit:
echo...
echo n'affiche pas des noms de fichier,
echo *
C'est le shell qui transforme * en noms de fichier! La commande echo ne reçoit que des chaînes de caractères et est donc incapable de faire la différence entre une chaîne arbitraire et un nom de fichier. Et d'ailleurs, comme un nom de fichier peut être '-n', la commande "echo *" risque de ne pas toujours avoir l'effet escompté. Bref, avant d'utiliser une commande shell, l'utilisateur doit utiliser son cerveau.
Le 20/08/07 3:51, dans <20070820014555$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EE54A9.B07AF%, Eric Levenez écrit:
Le 19/08/07 18:35, dans <20070819162046$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EC7A9B.B05C0%, Eric Levenez écrit:
echo...
echo n'affiche pas des noms de fichier,
echo *
C'est le shell qui transforme * en noms de fichier!
Et alors ? Cette commande (buildin ou non) affiche des noms de fichiers et n'interprète pas les caractères (comme ls -w). Tu vas faire aussi un bug report pour problème de sécurité à tous les fabricants de shells ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/08/07 3:51, dans <20070820014555$34c5@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2EE54A9.B07AF%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Le 19/08/07 18:35, dans <20070819162046$7d0f@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2EC7A9B.B05C0%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
echo...
echo n'affiche pas des noms de fichier,
echo *
C'est le shell qui transforme * en noms de fichier!
Et alors ? Cette commande (buildin ou non) affiche des noms de fichiers et
n'interprète pas les caractères (comme ls -w). Tu vas faire aussi un bug
report pour problème de sécurité à tous les fabricants de shells ?
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/08/07 3:51, dans <20070820014555$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EE54A9.B07AF%, Eric Levenez écrit:
Le 19/08/07 18:35, dans <20070819162046$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2EC7A9B.B05C0%, Eric Levenez écrit:
echo...
echo n'affiche pas des noms de fichier,
echo *
C'est le shell qui transforme * en noms de fichier!
Et alors ? Cette commande (buildin ou non) affiche des noms de fichiers et n'interprète pas les caractères (comme ls -w). Tu vas faire aussi un bug report pour problème de sécurité à tous les fabricants de shells ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <C2EF0F30.B084E%, Eric Levenez écrit:
C'est le shell qui transforme * en noms de fichier!
Et alors ? Cette commande (buildin ou non) affiche des noms de fichiers et n'interprète pas les caractères (comme ls -w). Tu vas faire aussi un bug report pour problème de sécurité à tous les fabricants de shells ?
Si c'est pour ne pas lire mes messages en entier et snipper n'importe comment, évite de répondre. L'explication est dans la partie que tu as snippée. Tu n'as qu'à la lire au lieu d'écrire n'importe quoi.
De toute façon, echo se comporte comme il est documenté, ce qui n'est pas le cas de /bin/ls.
Dans l'article <C2EF0F30.B084E%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
C'est le shell qui transforme * en noms de fichier!
Et alors ? Cette commande (buildin ou non) affiche des noms de fichiers et
n'interprète pas les caractères (comme ls -w). Tu vas faire aussi un bug
report pour problème de sécurité à tous les fabricants de shells ?
Si c'est pour ne pas lire mes messages en entier et snipper n'importe
comment, évite de répondre. L'explication est dans la partie que tu as
snippée. Tu n'as qu'à la lire au lieu d'écrire n'importe quoi.
De toute façon, echo se comporte comme il est documenté, ce qui n'est
pas le cas de /bin/ls.
Dans l'article <C2EF0F30.B084E%, Eric Levenez écrit:
C'est le shell qui transforme * en noms de fichier!
Et alors ? Cette commande (buildin ou non) affiche des noms de fichiers et n'interprète pas les caractères (comme ls -w). Tu vas faire aussi un bug report pour problème de sécurité à tous les fabricants de shells ?
Si c'est pour ne pas lire mes messages en entier et snipper n'importe comment, évite de répondre. L'explication est dans la partie que tu as snippée. Tu n'as qu'à la lire au lieu d'écrire n'importe quoi.
De toute façon, echo se comporte comme il est documenté, ce qui n'est pas le cas de /bin/ls.
Le 20/08/07 18:03, dans <20070820155829$, « Vincent Lefevre » <vincent+ a écrit :
De toute façon, echo se comporte comme il est documenté, ce qui n'est pas le cas de /bin/ls.
Et le problème de sécurité que tu vois dans ls, tu ne vois pas dans echo ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <C2EF931F.B091A%, Eric Levenez écrit:
Le 20/08/07 18:03, dans <20070820155829$, « Vincent Lefevre » <vincent+ a écrit :
De toute façon, echo se comporte comme il est documenté, ce qui n'est pas le cas de /bin/ls.
Et le problème de sécurité que tu vois dans ls, tu ne vois pas dans echo ?
Il n'y a pas de problème de sécurité dans echo. C'est dans "echo *" qu'il y en a (potentiellement) un. Pas seulement un problème de sécurité d'ailleurs, mais d'autres effets non voulus même si tous les caractères sont imprimables. De même qu'il n'y a pas de problème de sécurité avec "ls -q" (l'option -q est généralement l'option par défaut lorsque la sortie est un terminal), mais il y en a un avec "ls -w" (sauf en cas de préfiltrage par l'utilisateur ou un script).
Dans l'article <C2EF931F.B091A%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Le 20/08/07 18:03, dans <20070820155829$5e07@prunille.vinc17.org>,
« Vincent Lefevre » <vincent+news@vinc17.org> a écrit :
De toute façon, echo se comporte comme il est documenté, ce qui n'est
pas le cas de /bin/ls.
Et le problème de sécurité que tu vois dans ls, tu ne vois pas dans echo ?
Il n'y a pas de problème de sécurité dans echo. C'est dans "echo *"
qu'il y en a (potentiellement) un. Pas seulement un problème de
sécurité d'ailleurs, mais d'autres effets non voulus même si tous
les caractères sont imprimables. De même qu'il n'y a pas de problème
de sécurité avec "ls -q" (l'option -q est généralement l'option par
défaut lorsque la sortie est un terminal), mais il y en a un avec
"ls -w" (sauf en cas de préfiltrage par l'utilisateur ou un script).
Dans l'article <C2EF931F.B091A%, Eric Levenez écrit:
Le 20/08/07 18:03, dans <20070820155829$, « Vincent Lefevre » <vincent+ a écrit :
De toute façon, echo se comporte comme il est documenté, ce qui n'est pas le cas de /bin/ls.
Et le problème de sécurité que tu vois dans ls, tu ne vois pas dans echo ?
Il n'y a pas de problème de sécurité dans echo. C'est dans "echo *" qu'il y en a (potentiellement) un. Pas seulement un problème de sécurité d'ailleurs, mais d'autres effets non voulus même si tous les caractères sont imprimables. De même qu'il n'y a pas de problème de sécurité avec "ls -q" (l'option -q est généralement l'option par défaut lorsque la sortie est un terminal), mais il y en a un avec "ls -w" (sauf en cas de préfiltrage par l'utilisateur ou un script).
