je cherche a xor des chaines de caracteres.
Existe t'il un bout de script shell qui realise ce genre de chose, ou
il faut obligatoirement passer par un langage de programmation?
On Mon, 12 Jun 2006 12:59:24 +0000 (UTC), Vincent Lefevre wrote: [...]
A ce compte la, tu n'auras peut-etre pas de sh POSIX ni Bourne
Si, le shell par défaut est bash.
Quand je disais "a ce compte la", je voulais dire "si tu veux prendre en compte les systemes embarqués comme ceux utilisant busybox".
(pourra etre le sh de minix ou un ash simplifié...), tu n'auras pas forcement sed, ou alors un sed qui ne connait que "s", tu n'auras probablement pas awk, surtout pas perl...
Il doit y avoir awk et sed en standard. Pas perl, mais il y a un paquet (c'est une des premières choses que j'ai installées, mais il y a malheureusement peu de modules, et cpan ne fonctionne pas). En revanche, je n'ai pas vu de paquet od (il faut peut-être l'installer via les coreutils).
Quand tu configures busybox, tu dis quelles commandes tu veux installer avec quelles limitations (par exemple, tu peux demander un sed minimal qui ne support que la commande "s").
od fait partie des choix.
Si on a besoin de od, on peut l'inclure. Mais si pour faire cette operation (des xors de chaines), on a besoin d'inclure a la fois awk et od, et si ces commandes ne serviront que pour ca, alors autant compiler une commande qui fait ca:
Sauf qu'il n'y a pas de compilateur en standard, donc ce n'est pas forcément mieux. J'ai également installé gcc, ceci dit.
Sur un systeme embarqué, tu ne fais rien, surtout pas du developpement, tu compiles les commandes dont tu as besoin sur une machine de developpement, et les mets dans un root filesystem en ROM ou flash (initrd you flash filesystem). (en general). Donc, si ton systeme embarqué a besoin d'un script qui fait des XORs de chaines, tu peux ajouter cette commande (dans busybox, ou dans une commande separee), apres l'avoir compilee sur une autre machine.
-- Stephane
On Mon, 12 Jun 2006 12:59:24 +0000 (UTC), Vincent Lefevre wrote:
[...]
A ce compte la, tu n'auras peut-etre pas de sh POSIX ni Bourne
Si, le shell par défaut est bash.
Quand je disais "a ce compte la", je voulais dire "si tu veux
prendre en compte les systemes embarqués comme ceux utilisant
busybox".
(pourra etre le sh de minix ou un ash simplifié...), tu n'auras
pas forcement sed, ou alors un sed qui ne connait que "s", tu
n'auras probablement pas awk, surtout pas perl...
Il doit y avoir awk et sed en standard. Pas perl, mais il y a un
paquet (c'est une des premières choses que j'ai installées, mais
il y a malheureusement peu de modules, et cpan ne fonctionne
pas). En revanche, je n'ai pas vu de paquet od (il faut peut-être
l'installer via les coreutils).
Quand tu configures busybox, tu dis quelles commandes tu veux
installer avec quelles limitations (par exemple, tu peux
demander un sed minimal qui ne support que la commande "s").
od fait partie des choix.
Si on a besoin de od, on peut l'inclure. Mais si pour faire
cette operation (des xors de chaines), on a besoin d'inclure a
la fois awk et od, et si ces commandes ne serviront que pour ca,
alors autant compiler une commande qui fait ca:
Sauf qu'il n'y a pas de compilateur en standard, donc ce n'est pas
forcément mieux. J'ai également installé gcc, ceci dit.
Sur un systeme embarqué, tu ne fais rien, surtout pas du
developpement, tu compiles les commandes dont tu as besoin sur
une machine de developpement, et les mets dans un root
filesystem en ROM ou flash (initrd you flash filesystem).
(en general). Donc, si ton systeme embarqué a besoin d'un script
qui fait des XORs de chaines, tu peux ajouter cette commande
(dans busybox, ou dans une commande separee), apres l'avoir
compilee sur une autre machine.
On Mon, 12 Jun 2006 12:59:24 +0000 (UTC), Vincent Lefevre wrote: [...]
A ce compte la, tu n'auras peut-etre pas de sh POSIX ni Bourne
Si, le shell par défaut est bash.
Quand je disais "a ce compte la", je voulais dire "si tu veux prendre en compte les systemes embarqués comme ceux utilisant busybox".
(pourra etre le sh de minix ou un ash simplifié...), tu n'auras pas forcement sed, ou alors un sed qui ne connait que "s", tu n'auras probablement pas awk, surtout pas perl...
Il doit y avoir awk et sed en standard. Pas perl, mais il y a un paquet (c'est une des premières choses que j'ai installées, mais il y a malheureusement peu de modules, et cpan ne fonctionne pas). En revanche, je n'ai pas vu de paquet od (il faut peut-être l'installer via les coreutils).
Quand tu configures busybox, tu dis quelles commandes tu veux installer avec quelles limitations (par exemple, tu peux demander un sed minimal qui ne support que la commande "s").
od fait partie des choix.
Si on a besoin de od, on peut l'inclure. Mais si pour faire cette operation (des xors de chaines), on a besoin d'inclure a la fois awk et od, et si ces commandes ne serviront que pour ca, alors autant compiler une commande qui fait ca:
Sauf qu'il n'y a pas de compilateur en standard, donc ce n'est pas forcément mieux. J'ai également installé gcc, ceci dit.
Sur un systeme embarqué, tu ne fais rien, surtout pas du developpement, tu compiles les commandes dont tu as besoin sur une machine de developpement, et les mets dans un root filesystem en ROM ou flash (initrd you flash filesystem). (en general). Donc, si ton systeme embarqué a besoin d'un script qui fait des XORs de chaines, tu peux ajouter cette commande (dans busybox, ou dans une commande separee), apres l'avoir compilee sur une autre machine.
-- Stephane
lhabert
Nicolas George :
En revanche, l'utilisation d'un comportement implementation-defined (les opérations binaires sur des valeurs signées) est inexcusable :-Þ
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Nicolas George :
En revanche, l'utilisation d'un comportement implementation-defined (les
opérations binaires sur des valeurs signées) est inexcusable :-Þ
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
En revanche, l'utilisation d'un comportement implementation-defined (les opérations binaires sur des valeurs signées) est inexcusable :-Þ
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Stephane Chazelas
On Mon, 12 Jun 2006 15:04:30 +0000 (UTC), Luc Habert wrote:
Nicolas George :
En revanche, l'utilisation d'un comportement implementation-defined (les opérations binaires sur des valeurs signées) est inexcusable :-Þ
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Vous avez raison.
char *c; putchar(*c++);
avec *c=0xe9 (é) va appeler putchar avec un entier egal a -23 (0xFFFFFFE9 par exemple si les signed int sont codés sur 32bits)
Maintenant, POSIX dit que cet int doit etre converti en unsigned char. Je ne vois pas trop comment ce -23 peut etre converti en autre chose que 0xE9, mais bon, on peut peut-etre imaginer des systemes ou -23 devient 23 apres conversion en unsigned char.
-- Stephane
On Mon, 12 Jun 2006 15:04:30 +0000 (UTC), Luc Habert wrote:
Nicolas George :
En revanche, l'utilisation d'un comportement implementation-defined (les
opérations binaires sur des valeurs signées) est inexcusable :-Þ
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Vous avez raison.
char *c;
putchar(*c++);
avec *c=0xe9 (é) va appeler putchar avec un entier
egal a -23 (0xFFFFFFE9 par exemple si les signed int sont codés
sur 32bits)
Maintenant, POSIX dit que cet int doit etre converti en unsigned
char. Je ne vois pas trop comment ce -23 peut etre converti en
autre chose que 0xE9, mais bon, on peut peut-etre imaginer des
systemes ou -23 devient 23 apres conversion en unsigned char.
On Mon, 12 Jun 2006 15:04:30 +0000 (UTC), Luc Habert wrote:
Nicolas George :
En revanche, l'utilisation d'un comportement implementation-defined (les opérations binaires sur des valeurs signées) est inexcusable :-Þ
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Vous avez raison.
char *c; putchar(*c++);
avec *c=0xe9 (é) va appeler putchar avec un entier egal a -23 (0xFFFFFFE9 par exemple si les signed int sont codés sur 32bits)
Maintenant, POSIX dit que cet int doit etre converti en unsigned char. Je ne vois pas trop comment ce -23 peut etre converti en autre chose que 0xE9, mais bon, on peut peut-etre imaginer des systemes ou -23 devient 23 apres conversion en unsigned char.
-- Stephane
Vincent Lefevre
Dans l'article <e6jvpu$74q$, Luc Habert écrit:
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Je pense que si. La norme renvoie sur fputc et dit à cet endroit:
[#2] The fputc function writes the character specified by c (converted to an unsigned char) to the output stream pointed to by stream, [...]
Je pense que "the character specified by c" signifie que c est converti en unsigned char (c'est toujours défini), qui spécifie un caractère.
Maintenant, POSIX dit que cet int doit etre converti en unsigned char. Je ne vois pas trop comment ce -23 peut etre converti en autre chose que 0xE9, mais bon, on peut peut-etre imaginer des systemes ou -23 devient 23 apres conversion en unsigned char.
Non. -23 est converti forcément en UCHAR_MAX - 22. Les règles de conversion vers les non signés sont bien définies.
Dans l'article <slrne8r57r.d4q.stephane_chazelas@duey.spider.com>,
Stephane Chazelas <stephane_chazelas@yahoo.fr> écrit:
Maintenant, POSIX dit que cet int doit etre converti en unsigned
char. Je ne vois pas trop comment ce -23 peut etre converti en
autre chose que 0xE9, mais bon, on peut peut-etre imaginer des
systemes ou -23 devient 23 apres conversion en unsigned char.
Non. -23 est converti forcément en UCHAR_MAX - 22. Les règles de
conversion vers les non signés sont bien définies.
Maintenant, POSIX dit que cet int doit etre converti en unsigned char. Je ne vois pas trop comment ce -23 peut etre converti en autre chose que 0xE9, mais bon, on peut peut-etre imaginer des systemes ou -23 devient 23 apres conversion en unsigned char.
Non. -23 est converti forcément en UCHAR_MAX - 22. Les règles de conversion vers les non signés sont bien définies.
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Je pense que si. La norme renvoie sur fputc et dit à cet endroit:
[#2] The fputc function writes the character specified by c (converted to an unsigned char) to the output stream pointed to by stream, [...]
Je pense que "the character specified by c" signifie que c est converti en unsigned char (c'est toujours défini), qui spécifie un caractère.
Oui, tu as raison. Je sais pas pourquoi, j'avais toujours compris cette phrase comme « l'argument doit être un unsigned char convertit en int », mais c'est idiot.
Vincent Lefevre :
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Je pense que si. La norme renvoie sur fputc et dit à cet endroit:
[#2] The fputc function writes the character specified by c
(converted to an unsigned char) to the output stream pointed
to by stream, [...]
Je pense que "the character specified by c" signifie que c est converti
en unsigned char (c'est toujours défini), qui spécifie un caractère.
Oui, tu as raison. Je sais pas pourquoi, j'avais toujours compris cette
phrase comme « l'argument doit être un unsigned char convertit en int »,
mais c'est idiot.
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Je pense que si. La norme renvoie sur fputc et dit à cet endroit:
[#2] The fputc function writes the character specified by c (converted to an unsigned char) to the output stream pointed to by stream, [...]
Je pense que "the character specified by c" signifie que c est converti en unsigned char (c'est toujours défini), qui spécifie un caractère.
Oui, tu as raison. Je sais pas pourquoi, j'avais toujours compris cette phrase comme « l'argument doit être un unsigned char convertit en int », mais c'est idiot.
Vincent Lefevre
Dans l'article <e6mgo7$d8u$, Luc Habert écrit:
Vincent Lefevre :
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Je pense que si. La norme renvoie sur fputc et dit à cet endroit:
[#2] The fputc function writes the character specified by c (converted to an unsigned char) to the output stream pointed to by stream, [...]
Je pense que "the character specified by c" signifie que c est converti en unsigned char (c'est toujours défini), qui spécifie un caractère.
Oui, tu as raison. Je sais pas pourquoi, j'avais toujours compris cette phrase comme « l'argument doit être un unsigned char convertit en int », mais c'est idiot.
Tu confondais peut-être avec les fonctions isalnum, etc. où l'argument (un int) doit avoir la valeur d'un unsigned char *ou* EOF.
Dans l'article <e6mgo7$d8u$1@nef.ens.fr>,
Luc Habert <lhabert@clipper.ens.fr> écrit:
Vincent Lefevre :
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Je pense que si. La norme renvoie sur fputc et dit à cet endroit:
[#2] The fputc function writes the character specified by c
(converted to an unsigned char) to the output stream pointed
to by stream, [...]
Je pense que "the character specified by c" signifie que c est converti
en unsigned char (c'est toujours défini), qui spécifie un caractère.
Oui, tu as raison. Je sais pas pourquoi, j'avais toujours compris cette
phrase comme « l'argument doit être un unsigned char convertit en int »,
mais c'est idiot.
Tu confondais peut-être avec les fonctions isalnum, etc. où l'argument
(un int) doit avoir la valeur d'un unsigned char *ou* EOF.
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Je pense que si. La norme renvoie sur fputc et dit à cet endroit:
[#2] The fputc function writes the character specified by c (converted to an unsigned char) to the output stream pointed to by stream, [...]
Je pense que "the character specified by c" signifie que c est converti en unsigned char (c'est toujours défini), qui spécifie un caractère.
Oui, tu as raison. Je sais pas pourquoi, j'avais toujours compris cette phrase comme « l'argument doit être un unsigned char convertit en int », mais c'est idiot.
Tu confondais peut-être avec les fonctions isalnum, etc. où l'argument (un int) doit avoir la valeur d'un unsigned char *ou* EOF.
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Je pense que si. La norme renvoie sur fputc et dit à cet endroit:
[#2] The fputc function writes the character specified by c (converted to an unsigned char) to the output stream pointed to by stream, [...]
Je pense que "the character specified by c" signifie que c est converti en unsigned char (c'est toujours défini), qui spécifie un caractère.
Le problème, en effet, se présente dans l'autre direction. Tu lis un caractère 'é' avec fgetc ; en ISO 8859-1, c'est 0xE9. Alors, comment fais-tu pour l'affecter à un char ?
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Vincent Lefevre wrote:
Dans l'article <e6jvpu$74q$1@nef.ens.fr>,
Luc Habert <lhabert@clipper.ens.fr> écrit:
Et un putchar sur un entier négatif, ça n'est pas garanti de
marcher, si?
Je pense que si. La norme renvoie sur fputc et dit à cet
endroit:
[#2] The fputc function writes the character specified by c
(converted to an unsigned char) to the output stream pointed
to by stream, [...]
Je pense que "the character specified by c" signifie que c est
converti en unsigned char (c'est toujours défini), qui
spécifie un caractère.
Le problème, en effet, se présente dans l'autre direction. Tu
lis un caractère 'é' avec fgetc ; en ISO 8859-1, c'est 0xE9.
Alors, comment fais-tu pour l'affecter à un char ?
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Et un putchar sur un entier négatif, ça n'est pas garanti de marcher, si?
Je pense que si. La norme renvoie sur fputc et dit à cet endroit:
[#2] The fputc function writes the character specified by c (converted to an unsigned char) to the output stream pointed to by stream, [...]
Je pense que "the character specified by c" signifie que c est converti en unsigned char (c'est toujours défini), qui spécifie un caractère.
Le problème, en effet, se présente dans l'autre direction. Tu lis un caractère 'é' avec fgetc ; en ISO 8859-1, c'est 0xE9. Alors, comment fais-tu pour l'affecter à un char ?
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Vincent Lefevre
Dans l'article <e73bb8$bn1$, James Kanze écrit:
Le problème, en effet, se présente dans l'autre direction. Tu lis un caractère 'é' avec fgetc ; en ISO 8859-1, c'est 0xE9. Alors, comment fais-tu pour l'affecter à un char ?
On n'a jamais besoin de l'affecter à un char, il me semble.
Dans l'article <e73bb8$bn1$1@nntp.aioe.org>,
James Kanze <kanze.james@neuf.fr> écrit:
Le problème, en effet, se présente dans l'autre direction. Tu
lis un caractère 'é' avec fgetc ; en ISO 8859-1, c'est 0xE9.
Alors, comment fais-tu pour l'affecter à un char ?
On n'a jamais besoin de l'affecter à un char, il me semble.
Le problème, en effet, se présente dans l'autre direction. Tu lis un caractère 'é' avec fgetc ; en ISO 8859-1, c'est 0xE9. Alors, comment fais-tu pour l'affecter à un char ?
On n'a jamais besoin de l'affecter à un char, il me semble.
Le problème, en effet, se présente dans l'autre direction. Tu lis un caractère 'é' avec fgetc ; en ISO 8859-1, c'est 0xE9. Alors, comment fais-tu pour l'affecter à un char ?
On n'a jamais besoin de l'affecter à un char, il me semble.
Ça dépend de l'application. Il arrive, par exemple, de vouloir lire plus d'un caractère, et de les mettre dans un buffer qu'on peut traiter par la suite avec des fonctions telles que strstr().
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Vincent Lefevre wrote:
Dans l'article <e73bb8$bn1$1@nntp.aioe.org>,
James Kanze <kanze.james@neuf.fr> écrit:
Le problème, en effet, se présente dans l'autre direction. Tu
lis un caractère 'é' avec fgetc ; en ISO 8859-1, c'est 0xE9.
Alors, comment fais-tu pour l'affecter à un char ?
On n'a jamais besoin de l'affecter à un char, il me semble.
Ça dépend de l'application. Il arrive, par exemple, de vouloir
lire plus d'un caractère, et de les mettre dans un buffer qu'on
peut traiter par la suite avec des fonctions telles que
strstr().
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Le problème, en effet, se présente dans l'autre direction. Tu lis un caractère 'é' avec fgetc ; en ISO 8859-1, c'est 0xE9. Alors, comment fais-tu pour l'affecter à un char ?
On n'a jamais besoin de l'affecter à un char, il me semble.
Ça dépend de l'application. Il arrive, par exemple, de vouloir lire plus d'un caractère, et de les mettre dans un buffer qu'on peut traiter par la suite avec des fonctions telles que strstr().
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
