"Ael Rowan Terence" a écrit dans le message de news:f33si1$63v$
"Stan" a écrit dans le message de news:f33jt4$jbe$
Bonjour,
Y-a-t-il des cas de plantage qui ne générent pas de core dump ?
J'ai un programme qui plante de temps en temps et je n'ai pas de trace de fichier core.
Il se plante ? c'est à dire : il boucle indéfiniment ? il sort inopenament ?
Il faut lire le titre ;-) Il avorte, il sort prématurément; une boucle infinie, par elle même, ne provoque pas de core dump.
-- -Stan
James Kanze
On May 24, 10:56 am, "Stan" wrote:
Y-a-t-il des cas de plantage qui ne générent pas de core dump ?
J'ai un programme qui plante de temps en temps et je n'ai pas de trace de fichier core.
Ça dépend de ce que tu endends par « planter ». Un programme avec une erreur peut avoir beaucoup de comportements différents : générer un core dump, tourner sans fin, donner de mauvais résultats, etc. Il est aussi possible qu'il s'arrête comme ça, sans donner de core. (Sous Unix, ça arrive la plupart du temps à cause des problèmes avec un autre programme -- ce qui provoke un SIGPIPE dans ton programme, par exemple. Ou un SIGHUP, parce qu'on a oublié de le sortir du process group du terminal.)
-- James Kanze (GABI Software) email: 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
On May 24, 10:56 am, "Stan" <n...@none.invalid> wrote:
Y-a-t-il des cas de plantage
qui ne générent pas de core dump ?
J'ai un programme qui plante de temps en temps
et je n'ai pas de trace de fichier core.
Ça dépend de ce que tu endends par « planter ». Un programme
avec une erreur peut avoir beaucoup de comportements
différents : générer un core dump, tourner sans fin, donner de
mauvais résultats, etc. Il est aussi possible qu'il s'arrête
comme ça, sans donner de core. (Sous Unix, ça arrive la plupart
du temps à cause des problèmes avec un autre programme -- ce
qui provoke un SIGPIPE dans ton programme, par exemple. Ou un
SIGHUP, parce qu'on a oublié de le sortir du process group du
terminal.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
Y-a-t-il des cas de plantage qui ne générent pas de core dump ?
J'ai un programme qui plante de temps en temps et je n'ai pas de trace de fichier core.
Ça dépend de ce que tu endends par « planter ». Un programme avec une erreur peut avoir beaucoup de comportements différents : générer un core dump, tourner sans fin, donner de mauvais résultats, etc. Il est aussi possible qu'il s'arrête comme ça, sans donner de core. (Sous Unix, ça arrive la plupart du temps à cause des problèmes avec un autre programme -- ce qui provoke un SIGPIPE dans ton programme, par exemple. Ou un SIGHUP, parce qu'on a oublié de le sortir du process group du terminal.)
-- James Kanze (GABI Software) email: 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
James Kanze
On May 24, 1:16 pm, "Stan" wrote:
"Ael Rowan Terence" a écrit dans le message denews:f33si 1$63v$
"Stan" a écrit dans le message de news:f33jt4$jbe$
Y-a-t-il des cas de plantage qui ne générent pas de core dump ?
J'ai un programme qui plante de temps en temps et je n'ai pas de trace de fichier core.
Il se plante ? c'est à dire : il boucle indéfiniment ? il sort inopenament ?
Il faut lire le titre ;-) Il avorte, il sort prématurément; une boucle infinie, par elle même, ne provoque pas de core dump.
Avorter, en général, signifie qu'il termine suite à un SIGABRT. Dans tel cas, il aurait normalement un core, au moins que la configuration locale ne le permet pas. (Sous Unix, vérifier le ulimit -c; si c'est 0, pas de core.)
En gros, un processus sous Unix ne termine que parce qu'il a appelé _exit() (suite à un retour de main, par exemple), soit parce qu'il a reçu un signal. Dans le premier cas, le code de retour sera normalement une valeur assez petite (mais rien n'empêche qu'un programme renvoie des valeurs plus grandes) ; dans le deuxième, le shell présente une valeur qui correspond au numéro du signal plus 128. Tu dois donc pouvoir distinguer, et même savoir de quel signal il s'agit.
-- James Kanze (GABI Software) email: 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
On May 24, 1:16 pm, "Stan" <n...@none.invalid> wrote:
"Ael Rowan Terence" <N...@Null.fr> a écrit dans le message denews:f33si 1$63v$1@news1.completel.net...
"Stan" <n...@none.invalid> a écrit dans le message de
news:f33jt4$jbe$1@s1.news.oleane.net...
Y-a-t-il des cas de plantage
qui ne générent pas de core dump ?
J'ai un programme qui plante de temps en temps
et je n'ai pas de trace de fichier core.
Il se plante ? c'est à dire : il boucle indéfiniment ? il
sort inopenament ?
Il faut lire le titre ;-)
Il avorte, il sort prématurément; une boucle infinie, par elle même,
ne provoque pas de core dump.
Avorter, en général, signifie qu'il termine suite à un SIGABRT.
Dans tel cas, il aurait normalement un core, au moins que la
configuration locale ne le permet pas. (Sous Unix, vérifier le
ulimit -c; si c'est 0, pas de core.)
En gros, un processus sous Unix ne termine que parce qu'il a
appelé _exit() (suite à un retour de main, par exemple), soit
parce qu'il a reçu un signal. Dans le premier cas, le code de
retour sera normalement une valeur assez petite (mais rien
n'empêche qu'un programme renvoie des valeurs plus grandes) ;
dans le deuxième, le shell présente une valeur qui correspond au
numéro du signal plus 128. Tu dois donc pouvoir distinguer, et
même savoir de quel signal il s'agit.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
"Ael Rowan Terence" a écrit dans le message denews:f33si 1$63v$
"Stan" a écrit dans le message de news:f33jt4$jbe$
Y-a-t-il des cas de plantage qui ne générent pas de core dump ?
J'ai un programme qui plante de temps en temps et je n'ai pas de trace de fichier core.
Il se plante ? c'est à dire : il boucle indéfiniment ? il sort inopenament ?
Il faut lire le titre ;-) Il avorte, il sort prématurément; une boucle infinie, par elle même, ne provoque pas de core dump.
Avorter, en général, signifie qu'il termine suite à un SIGABRT. Dans tel cas, il aurait normalement un core, au moins que la configuration locale ne le permet pas. (Sous Unix, vérifier le ulimit -c; si c'est 0, pas de core.)
En gros, un processus sous Unix ne termine que parce qu'il a appelé _exit() (suite à un retour de main, par exemple), soit parce qu'il a reçu un signal. Dans le premier cas, le code de retour sera normalement une valeur assez petite (mais rien n'empêche qu'un programme renvoie des valeurs plus grandes) ; dans le deuxième, le shell présente une valeur qui correspond au numéro du signal plus 128. Tu dois donc pouvoir distinguer, et même savoir de quel signal il s'agit.
-- James Kanze (GABI Software) email: 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
Stan
"James Kanze" a écrit dans le message de
En gros, un processus sous Unix ne termine que parce qu'il a appelé _exit() (suite à un retour de main, par exemple), soit parce qu'il a reçu un signal. Dans le premier cas, le code de retour sera normalement une valeur assez petite (mais rien n'empêche qu'un programme renvoie des valeurs plus grandes) ; dans le deuxième, le shell présente une valeur qui correspond au numéro du signal plus 128. Tu dois donc pouvoir distinguer, et même savoir de quel signal il s'agit.
Le programme est lancé depuis inetd ( xinetd pour être précis ), de ce fait, je ne suis pas sûr de pouvoir retouver le signal.
-- -Stan
"James Kanze" <james.kanze@gmail.com> a écrit dans le message de
En gros, un processus sous Unix ne termine que parce qu'il a
appelé _exit() (suite à un retour de main, par exemple), soit
parce qu'il a reçu un signal. Dans le premier cas, le code de
retour sera normalement une valeur assez petite (mais rien
n'empêche qu'un programme renvoie des valeurs plus grandes) ;
dans le deuxième, le shell présente une valeur qui correspond au
numéro du signal plus 128. Tu dois donc pouvoir distinguer, et
même savoir de quel signal il s'agit.
Le programme est lancé depuis inetd ( xinetd pour être précis ),
de ce fait, je ne suis pas sûr de pouvoir retouver le signal.
En gros, un processus sous Unix ne termine que parce qu'il a appelé _exit() (suite à un retour de main, par exemple), soit parce qu'il a reçu un signal. Dans le premier cas, le code de retour sera normalement une valeur assez petite (mais rien n'empêche qu'un programme renvoie des valeurs plus grandes) ; dans le deuxième, le shell présente une valeur qui correspond au numéro du signal plus 128. Tu dois donc pouvoir distinguer, et même savoir de quel signal il s'agit.
Le programme est lancé depuis inetd ( xinetd pour être précis ), de ce fait, je ne suis pas sûr de pouvoir retouver le signal.
-- -Stan
James Kanze
On May 24, 3:48 pm, "Stan" wrote:
"James Kanze" a écrit dans le message de
En gros, un processus sous Unix ne termine que parce qu'il a appelé _exit() (suite à un retour de main, par exemple), soit parce qu'il a reçu un signal. Dans le premier cas, le code de retour sera normalement une valeur assez petite (mais rien n'empêche qu'un programme renvoie des valeurs plus grandes) ; dans le deuxième, le shell présente une valeur qui correspond au numéro du signal plus 128. Tu dois donc pouvoir distinguer, et même savoir de quel signal il s'agit.
Le programme est lancé depuis inetd ( xinetd pour être précis ), de ce fait, je ne suis pas sûr de pouvoir retouver le signal.
En effet. Et tu ne peux pas réproduire l'erreur en le lançant depuis un shell ?
Sinon, il faut écrire un tout petit programme qui le lance, qui récupère l'état de sortie (signal, etc.), et qui l'écrit dans un fichier de log, et configurer xinetd pour lancer ce petit programme.
Aussi, si c'est un programme qui se lance à partir d'inetd (ou d'un cron, ou d'un rc du système), il faut bien que tu lui instrumentes, avec des logs, configuré par un fichier de configuration. Ensuite, tu as les logs, pour voir ce qui était la dernière chose que tu faisais.
-- James Kanze (Gabi Software) email: 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
On May 24, 3:48 pm, "Stan" <n...@none.invalid> wrote:
"James Kanze" <james.ka...@gmail.com> a écrit dans le message de
En gros, un processus sous Unix ne termine que parce qu'il a
appelé _exit() (suite à un retour de main, par exemple), soit
parce qu'il a reçu un signal. Dans le premier cas, le code de
retour sera normalement une valeur assez petite (mais rien
n'empêche qu'un programme renvoie des valeurs plus grandes) ;
dans le deuxième, le shell présente une valeur qui correspond au
numéro du signal plus 128. Tu dois donc pouvoir distinguer, et
même savoir de quel signal il s'agit.
Le programme est lancé depuis inetd ( xinetd pour être précis ),
de ce fait, je ne suis pas sûr de pouvoir retouver le signal.
En effet. Et tu ne peux pas réproduire l'erreur en le lançant
depuis un shell ?
Sinon, il faut écrire un tout petit programme qui le lance, qui
récupère l'état de sortie (signal, etc.), et qui l'écrit dans un
fichier de log, et configurer xinetd pour lancer ce petit
programme.
Aussi, si c'est un programme qui se lance à partir d'inetd (ou
d'un cron, ou d'un rc du système), il faut bien que tu lui
instrumentes, avec des logs, configuré par un fichier de
configuration. Ensuite, tu as les logs, pour voir ce qui était
la dernière chose que tu faisais.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
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
En gros, un processus sous Unix ne termine que parce qu'il a appelé _exit() (suite à un retour de main, par exemple), soit parce qu'il a reçu un signal. Dans le premier cas, le code de retour sera normalement une valeur assez petite (mais rien n'empêche qu'un programme renvoie des valeurs plus grandes) ; dans le deuxième, le shell présente une valeur qui correspond au numéro du signal plus 128. Tu dois donc pouvoir distinguer, et même savoir de quel signal il s'agit.
Le programme est lancé depuis inetd ( xinetd pour être précis ), de ce fait, je ne suis pas sûr de pouvoir retouver le signal.
En effet. Et tu ne peux pas réproduire l'erreur en le lançant depuis un shell ?
Sinon, il faut écrire un tout petit programme qui le lance, qui récupère l'état de sortie (signal, etc.), et qui l'écrit dans un fichier de log, et configurer xinetd pour lancer ce petit programme.
Aussi, si c'est un programme qui se lance à partir d'inetd (ou d'un cron, ou d'un rc du système), il faut bien que tu lui instrumentes, avec des logs, configuré par un fichier de configuration. Ensuite, tu as les logs, pour voir ce qui était la dernière chose que tu faisais.
-- James Kanze (Gabi Software) email: 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
espie
In article , James Kanze wrote:
On May 24, 3:48 pm, "Stan" wrote:
"James Kanze" a écrit dans le message de
En gros, un processus sous Unix ne termine que parce qu'il a appelé _exit() (suite à un retour de main, par exemple), soit parce qu'il a reçu un signal. Dans le premier cas, le code de retour sera normalement une valeur assez petite (mais rien n'empêche qu'un programme renvoie des valeurs plus grandes) ; dans le deuxième, le shell présente une valeur qui correspond au numéro du signal plus 128. Tu dois donc pouvoir distinguer, et même savoir de quel signal il s'agit.
Le programme est lancé depuis inetd ( xinetd pour être précis ), de ce fait, je ne suis pas sûr de pouvoir retouver le signal.
En effet. Et tu ne peux pas réproduire l'erreur en le lançant depuis un shell ?
Sinon, il faut écrire un tout petit programme qui le lance, qui récupère l'état de sortie (signal, etc.), et qui l'écrit dans un fichier de log, et configurer xinetd pour lancer ce petit programme.
Normalement, un inetd bien foutu regarde le statut de retour des programmes qu'il a lance... je sais que celui d'OpenBSD loggue toute terminaison anormale (et normalement, ne relance PAS automatiquement le demon en question, ce qui est logique).
Apres, les raisons de ne pas avoir de core-dump: - le programme est lance dans un repertoire ou il ne peut pas ecrire: ca peut etre tres possible s'il est lance avec sa propre uid dans un repertoire appartenant a root (suffit dans ce cas-la de mettre TEMPORAIREMENT le repertoire en question en ecriture pour le groupe ou tout le monde). - le programme est setuid. Les programmes setuid ne font normalement pas de core. Normalement, ca se configure a coup de sysctl, ca.
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait mieux aller faire un tour dans un groupe unix, a ce compte...
In article <1180039498.741903.250500@p77g2000hsh.googlegroups.com>,
James Kanze <james.kanze@gmail.com> wrote:
On May 24, 3:48 pm, "Stan" <n...@none.invalid> wrote:
"James Kanze" <james.ka...@gmail.com> a écrit dans le message de
En gros, un processus sous Unix ne termine que parce qu'il a
appelé _exit() (suite à un retour de main, par exemple), soit
parce qu'il a reçu un signal. Dans le premier cas, le code de
retour sera normalement une valeur assez petite (mais rien
n'empêche qu'un programme renvoie des valeurs plus grandes) ;
dans le deuxième, le shell présente une valeur qui correspond au
numéro du signal plus 128. Tu dois donc pouvoir distinguer, et
même savoir de quel signal il s'agit.
Le programme est lancé depuis inetd ( xinetd pour être précis ),
de ce fait, je ne suis pas sûr de pouvoir retouver le signal.
En effet. Et tu ne peux pas réproduire l'erreur en le lançant
depuis un shell ?
Sinon, il faut écrire un tout petit programme qui le lance, qui
récupère l'état de sortie (signal, etc.), et qui l'écrit dans un
fichier de log, et configurer xinetd pour lancer ce petit
programme.
Normalement, un inetd bien foutu regarde le statut de retour des programmes
qu'il a lance... je sais que celui d'OpenBSD loggue toute terminaison
anormale (et normalement, ne relance PAS automatiquement le demon en
question, ce qui est logique).
Apres, les raisons de ne pas avoir de core-dump:
- le programme est lance dans un repertoire ou il ne peut pas ecrire: ca
peut etre tres possible s'il est lance avec sa propre uid dans un repertoire
appartenant a root (suffit dans ce cas-la de mettre TEMPORAIREMENT le
repertoire en question en ecriture pour le groupe ou tout le monde).
- le programme est setuid. Les programmes setuid ne font normalement
pas de core. Normalement, ca se configure a coup de sysctl, ca.
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait
mieux aller faire un tour dans un groupe unix, a ce compte...
En gros, un processus sous Unix ne termine que parce qu'il a appelé _exit() (suite à un retour de main, par exemple), soit parce qu'il a reçu un signal. Dans le premier cas, le code de retour sera normalement une valeur assez petite (mais rien n'empêche qu'un programme renvoie des valeurs plus grandes) ; dans le deuxième, le shell présente une valeur qui correspond au numéro du signal plus 128. Tu dois donc pouvoir distinguer, et même savoir de quel signal il s'agit.
Le programme est lancé depuis inetd ( xinetd pour être précis ), de ce fait, je ne suis pas sûr de pouvoir retouver le signal.
En effet. Et tu ne peux pas réproduire l'erreur en le lançant depuis un shell ?
Sinon, il faut écrire un tout petit programme qui le lance, qui récupère l'état de sortie (signal, etc.), et qui l'écrit dans un fichier de log, et configurer xinetd pour lancer ce petit programme.
Normalement, un inetd bien foutu regarde le statut de retour des programmes qu'il a lance... je sais que celui d'OpenBSD loggue toute terminaison anormale (et normalement, ne relance PAS automatiquement le demon en question, ce qui est logique).
Apres, les raisons de ne pas avoir de core-dump: - le programme est lance dans un repertoire ou il ne peut pas ecrire: ca peut etre tres possible s'il est lance avec sa propre uid dans un repertoire appartenant a root (suffit dans ce cas-la de mettre TEMPORAIREMENT le repertoire en question en ecriture pour le groupe ou tout le monde). - le programme est setuid. Les programmes setuid ne font normalement pas de core. Normalement, ca se configure a coup de sysctl, ca.
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait mieux aller faire un tour dans un groupe unix, a ce compte...
Stan
"Marc Espie" a écrit dans le message de news:f34u3u$1e6c$
Normalement, un inetd bien foutu regarde le statut de retour des programmes
qu'il a lance... je sais que celui d'OpenBSD loggue toute terminaison anormale (et normalement, ne relance PAS automatiquement le demon en question, ce qui est logique).
Je ne sais pas ce qu'est un inetd "mal foutu", mais je ne pense pas que le xinetd de la FreeBSD que j'utilise soit mal codé. Or, mon application est bien relancé la fois suivante...
Apres, les raisons de ne pas avoir de core-dump: - le programme est lance dans un repertoire ou il ne peut pas ecrire: ca peut etre tres possible s'il est lance avec sa propre uid dans un repertoire
appartenant a root (suffit dans ce cas-la de mettre TEMPORAIREMENT le repertoire en question en ecriture pour le groupe ou tout le monde).
ce n'est pas le cas.
- le programme est setuid. Les programmes setuid ne font normalement pas de core. Normalement, ca se configure a coup de sysctl, ca.
non plus.
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait mieux aller faire un tour dans un groupe unix, a ce compte...
Oui. Mais nous sommes des gens responsables, n'est-ce pas. On peut admettre un léger bruit qui résulte forcément de la réponse aux questions subsidiaires ;-)
-- -Stan
"Marc Espie" <espie@lain.home> a écrit dans le message de
news:f34u3u$1e6c$1@biggoron.nerim.net...
Normalement, un inetd bien foutu regarde le statut de retour des
programmes
qu'il a lance... je sais que celui d'OpenBSD loggue toute terminaison
anormale (et normalement, ne relance PAS automatiquement le demon en
question, ce qui est logique).
Je ne sais pas ce qu'est un inetd "mal foutu", mais je ne pense pas
que le xinetd de la FreeBSD que j'utilise soit mal codé.
Or, mon application est bien relancé la fois suivante...
Apres, les raisons de ne pas avoir de core-dump:
- le programme est lance dans un repertoire ou il ne peut pas ecrire: ca
peut etre tres possible s'il est lance avec sa propre uid dans un
repertoire
appartenant a root (suffit dans ce cas-la de mettre TEMPORAIREMENT le
repertoire en question en ecriture pour le groupe ou tout le monde).
ce n'est pas le cas.
- le programme est setuid. Les programmes setuid ne font normalement
pas de core. Normalement, ca se configure a coup de sysctl, ca.
non plus.
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait
mieux aller faire un tour dans un groupe unix, a ce compte...
Oui. Mais nous sommes des gens responsables, n'est-ce pas.
On peut admettre un léger bruit qui résulte forcément
de la réponse aux questions subsidiaires ;-)
"Marc Espie" a écrit dans le message de news:f34u3u$1e6c$
Normalement, un inetd bien foutu regarde le statut de retour des programmes
qu'il a lance... je sais que celui d'OpenBSD loggue toute terminaison anormale (et normalement, ne relance PAS automatiquement le demon en question, ce qui est logique).
Je ne sais pas ce qu'est un inetd "mal foutu", mais je ne pense pas que le xinetd de la FreeBSD que j'utilise soit mal codé. Or, mon application est bien relancé la fois suivante...
Apres, les raisons de ne pas avoir de core-dump: - le programme est lance dans un repertoire ou il ne peut pas ecrire: ca peut etre tres possible s'il est lance avec sa propre uid dans un repertoire
appartenant a root (suffit dans ce cas-la de mettre TEMPORAIREMENT le repertoire en question en ecriture pour le groupe ou tout le monde).
ce n'est pas le cas.
- le programme est setuid. Les programmes setuid ne font normalement pas de core. Normalement, ca se configure a coup de sysctl, ca.
non plus.
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait mieux aller faire un tour dans un groupe unix, a ce compte...
Oui. Mais nous sommes des gens responsables, n'est-ce pas. On peut admettre un léger bruit qui résulte forcément de la réponse aux questions subsidiaires ;-)
-- -Stan
alex
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait mieux aller faire un tour dans un groupe unix, a ce compte...
Oui. Mais nous sommes des gens responsables, n'est-ce pas. On peut admettre un léger bruit qui résulte forcément de la réponse aux questions subsidiaires ;-)
certes, mais admettez que quand qqn pose une question genre "comment faire du réseau sous windows en C++" il est nettement plus vide redirigé vers la sortie...
Les programmeurs C++, plutôt des unixiens que des windoweux ?
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait
mieux aller faire un tour dans un groupe unix, a ce compte...
Oui. Mais nous sommes des gens responsables, n'est-ce pas.
On peut admettre un léger bruit qui résulte forcément
de la réponse aux questions subsidiaires ;-)
certes, mais admettez que quand qqn pose une question genre "comment faire
du réseau sous windows en C++" il est nettement plus vide redirigé vers la
sortie...
Les programmeurs C++, plutôt des unixiens que des windoweux ?
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait mieux aller faire un tour dans un groupe unix, a ce compte...
Oui. Mais nous sommes des gens responsables, n'est-ce pas. On peut admettre un léger bruit qui résulte forcément de la réponse aux questions subsidiaires ;-)
certes, mais admettez que quand qqn pose une question genre "comment faire du réseau sous windows en C++" il est nettement plus vide redirigé vers la sortie...
Les programmeurs C++, plutôt des unixiens que des windoweux ?
espie
In article <465f1aee$0$7501$, alex wrote:
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait mieux aller faire un tour dans un groupe unix, a ce compte...
Oui. Mais nous sommes des gens responsables, n'est-ce pas. On peut admettre un léger bruit qui résulte forcément de la réponse aux questions subsidiaires ;-)
certes, mais admettez que quand qqn pose une question genre "comment faire du réseau sous windows en C++" il est nettement plus vide redirigé vers la sortie...
Pas tout a fait vrai. En ce qui me concerne, je considere que je l'ai redirige vers la sortie, dans ce cas-aussi. La seule petite difference, c'est que j'avais deux/trois pistes de reponse, ce qui est moins souvent le cas sous windows.
Mais bon, il me semble que les windowsiens du coin sont generalement exactement aussi civils: une indication de quoi faire, et zou direction le groupe windows approprie.
In article <465f1aee$0$7501$426a74cc@news.free.fr>,
alex <alexandre_21000@hotmail.fr> wrote:
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait
mieux aller faire un tour dans un groupe unix, a ce compte...
Oui. Mais nous sommes des gens responsables, n'est-ce pas.
On peut admettre un léger bruit qui résulte forcément
de la réponse aux questions subsidiaires ;-)
certes, mais admettez que quand qqn pose une question genre "comment faire
du réseau sous windows en C++" il est nettement plus vide redirigé vers la
sortie...
Pas tout a fait vrai. En ce qui me concerne, je considere que je l'ai
redirige vers la sortie, dans ce cas-aussi. La seule petite difference,
c'est que j'avais deux/trois pistes de reponse, ce qui est moins
souvent le cas sous windows.
Mais bon, il me semble que les windowsiens du coin sont generalement
exactement aussi civils: une indication de quoi faire, et zou direction
le groupe windows approprie.
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait mieux aller faire un tour dans un groupe unix, a ce compte...
Oui. Mais nous sommes des gens responsables, n'est-ce pas. On peut admettre un léger bruit qui résulte forcément de la réponse aux questions subsidiaires ;-)
certes, mais admettez que quand qqn pose une question genre "comment faire du réseau sous windows en C++" il est nettement plus vide redirigé vers la sortie...
Pas tout a fait vrai. En ce qui me concerne, je considere que je l'ai redirige vers la sortie, dans ce cas-aussi. La seule petite difference, c'est que j'avais deux/trois pistes de reponse, ce qui est moins souvent le cas sous windows.
Mais bon, il me semble que les windowsiens du coin sont generalement exactement aussi civils: une indication de quoi faire, et zou direction le groupe windows approprie.
