Bonjour,
Je vous explique mon probleme et si vous avez une solution merci de
m'aider.
Je ne suis pas un super pro du langage C ni d'unix, mais je connais un
peu le principe de la comamned Fork(), j'ai appris cela =E0 l'ecole il
ya maintenant 20 ans.
Je suis dba Oracle, j'optimise mes bases et je m'occupe aussi des
serveurs Unix (AIX), j'installe, je sauvegarde, etc etc j'alloue des
disques je surveille un peu tout, pour vue que ca marche.
Et la j'ai un petit probleme. Nous avons fait developp=E9 un logiciel
qui est cens=E9 simuler le traitement des batchs, sauf qu'il n'est pas
parall=E9lis=E9 et que les traitement s'executent les uns apres les
autres.
Un processus unix, lit une table de demande de travaux et soumet les
travaux les uns apres les autres.
Je me dis que si ce processus j'arrivais a le Fork=E9 dans un autre je
pourrais ainsi paralleliser les soumissions de job j'ai raison ou tord
?
Bonjour, Je vous explique mon probleme et si vous avez une solution merci de m'aider.
Je ne suis pas un super pro du langage C ni d'unix, mais je connais un peu le principe de la comamned Fork(), j'ai appris cela à l'ecole il ya maintenant 20 ans. Je suis dba Oracle, j'optimise mes bases et je m'occupe aussi des serveurs Unix (AIX), j'installe, je sauvegarde, etc etc j'alloue des disques je surveille un peu tout, pour vue que ca marche.
Et la j'ai un petit probleme. Nous avons fait developpé un logiciel qui est censé simuler le traitement des batchs, sauf qu'il n'est pas parallélisé et que les traitement s'executent les uns apres les autres.
S'il s'agit de _simuler_ il n'y a pas vraiment besoin d'utiliser plusieurs processus.
Une simulation avec "parallelisme", tenant compte du nombre de processeur et du nombre maximum de travaux simultané (ou éventuellement d'autres paramètres, comme le profil CPU ou I/O du travail, etc), pourrait donner comme résultat:
Ce n'est qu'une question d'additions, et il n'est pas nécessaire d'utiliser plusieurs processus pour les faire.
Un processus unix, lit une table de demande de jobs et soumet les jobs les uns apres les autres.
Je me dis que si ce processus j'arrivais a le Forké dans un autre je pourrais ainsi paralleliser les soumissions de job j'ai raison ou tord ?
Merci de me répondre et me dire comment faire.
S'il ne s'agit pas de simuler mais d'exécuter réellement ces travaux, le programme ordonanceur qui les lance automatiquement peut effectivement en lancer plusieurs à la fois, en "parallèle".
On ne veut pas forcément faire tourner deux copies de ce programme ordonanceur, car elles seraient indépendantes, et les travaux on certainement des contraintes d'ordonancement: certains travaux ne peuvent être exécutés que lorsque des phases précédentes ont été terminées (peut être avec condition de succès, ou avec des contraintes de date, etc).
Dans tous les cas, le programme ordonanceur lance les travaux de manière classique sur unix, en fork-ant et execut-ant le travail, puis en attendant que le travail se termine avec wait(2) ou waitpid(2). Donc, fork(2) est déjà utilisé. La question est si le programme ordonanceur utilse wait(2) pour attendre la fin du travail avant de lancer le suivant on non.
Parmis les outils "standard" unix existants, on peut aussi considérer;
cron at batch nqs
http://www.google.com/search?qºtch+unix+scheduler
-- __Pascal Bourguignon__ http://www.informatimago.com/ Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects. The first system to really do this in an important way is Lisp. -- Alan Kay
"freedba" <p.hirth@gmail.com> writes:
Bonjour,
Je vous explique mon probleme et si vous avez une solution merci de
m'aider.
Je ne suis pas un super pro du langage C ni d'unix, mais je connais un
peu le principe de la comamned Fork(), j'ai appris cela à l'ecole il
ya maintenant 20 ans.
Je suis dba Oracle, j'optimise mes bases et je m'occupe aussi des
serveurs Unix (AIX), j'installe, je sauvegarde, etc etc j'alloue des
disques je surveille un peu tout, pour vue que ca marche.
Et la j'ai un petit probleme. Nous avons fait developpé un logiciel
qui est censé simuler le traitement des batchs, sauf qu'il n'est pas
parallélisé et que les traitement s'executent les uns apres les
autres.
S'il s'agit de _simuler_ il n'y a pas vraiment besoin d'utiliser
plusieurs processus.
Une simulation avec "parallelisme", tenant compte du nombre de
processeur et du nombre maximum de travaux simultané (ou
éventuellement d'autres paramètres, comme le profil CPU ou I/O du
travail, etc), pourrait donner comme résultat:
Ce n'est qu'une question d'additions, et il n'est pas nécessaire
d'utiliser plusieurs processus pour les faire.
Un processus unix, lit une table de demande de jobs et soumet les
jobs les uns apres les autres.
Je me dis que si ce processus j'arrivais a le Forké dans un autre je
pourrais ainsi paralleliser les soumissions de job j'ai raison ou tord ?
Merci de me répondre et me dire comment faire.
S'il ne s'agit pas de simuler mais d'exécuter réellement ces travaux,
le programme ordonanceur qui les lance automatiquement peut
effectivement en lancer plusieurs à la fois, en "parallèle".
On ne veut pas forcément faire tourner deux copies de ce programme
ordonanceur, car elles seraient indépendantes, et les travaux on
certainement des contraintes d'ordonancement: certains travaux ne
peuvent être exécutés que lorsque des phases précédentes ont été
terminées (peut être avec condition de succès, ou avec des contraintes
de date, etc).
Dans tous les cas, le programme ordonanceur lance les travaux de
manière classique sur unix, en fork-ant et execut-ant le travail, puis
en attendant que le travail se termine avec wait(2) ou waitpid(2).
Donc, fork(2) est déjà utilisé. La question est si le programme
ordonanceur utilse wait(2) pour attendre la fin du travail avant de
lancer le suivant on non.
Parmis les outils "standard" unix existants, on peut aussi considérer;
cron
at
batch
nqs
http://www.google.com/search?qºtch+unix+scheduler
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
Bonjour, Je vous explique mon probleme et si vous avez une solution merci de m'aider.
Je ne suis pas un super pro du langage C ni d'unix, mais je connais un peu le principe de la comamned Fork(), j'ai appris cela à l'ecole il ya maintenant 20 ans. Je suis dba Oracle, j'optimise mes bases et je m'occupe aussi des serveurs Unix (AIX), j'installe, je sauvegarde, etc etc j'alloue des disques je surveille un peu tout, pour vue que ca marche.
Et la j'ai un petit probleme. Nous avons fait developpé un logiciel qui est censé simuler le traitement des batchs, sauf qu'il n'est pas parallélisé et que les traitement s'executent les uns apres les autres.
S'il s'agit de _simuler_ il n'y a pas vraiment besoin d'utiliser plusieurs processus.
Une simulation avec "parallelisme", tenant compte du nombre de processeur et du nombre maximum de travaux simultané (ou éventuellement d'autres paramètres, comme le profil CPU ou I/O du travail, etc), pourrait donner comme résultat:
Ce n'est qu'une question d'additions, et il n'est pas nécessaire d'utiliser plusieurs processus pour les faire.
Un processus unix, lit une table de demande de jobs et soumet les jobs les uns apres les autres.
Je me dis que si ce processus j'arrivais a le Forké dans un autre je pourrais ainsi paralleliser les soumissions de job j'ai raison ou tord ?
Merci de me répondre et me dire comment faire.
S'il ne s'agit pas de simuler mais d'exécuter réellement ces travaux, le programme ordonanceur qui les lance automatiquement peut effectivement en lancer plusieurs à la fois, en "parallèle".
On ne veut pas forcément faire tourner deux copies de ce programme ordonanceur, car elles seraient indépendantes, et les travaux on certainement des contraintes d'ordonancement: certains travaux ne peuvent être exécutés que lorsque des phases précédentes ont été terminées (peut être avec condition de succès, ou avec des contraintes de date, etc).
Dans tous les cas, le programme ordonanceur lance les travaux de manière classique sur unix, en fork-ant et execut-ant le travail, puis en attendant que le travail se termine avec wait(2) ou waitpid(2). Donc, fork(2) est déjà utilisé. La question est si le programme ordonanceur utilse wait(2) pour attendre la fin du travail avant de lancer le suivant on non.
Parmis les outils "standard" unix existants, on peut aussi considérer;
cron at batch nqs
http://www.google.com/search?qºtch+unix+scheduler
-- __Pascal Bourguignon__ http://www.informatimago.com/ Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects. The first system to really do this in an important way is Lisp. -- Alan Kay
freedba
merci monsieur.
En fait quand vous dites la commande Batch (et c'est vrai je n'y avais pas pensé, c'est tout bete!!!) c'est peut etre le & en korn shell ?
merci
"freedba" writes:
Bonjour, Je vous explique mon probleme et si vous avez une solution merci de m'aider.
Je ne suis pas un super pro du langage C ni d'unix, mais je connais un peu le principe de la comamned Fork(), j'ai appris cela à l'ecole il ya maintenant 20 ans. Je suis dba Oracle, j'optimise mes bases et je m'occupe aussi des serveurs Unix (AIX), j'installe, je sauvegarde, etc etc j'alloue des disques je surveille un peu tout, pour vue que ca marche.
Et la j'ai un petit probleme. Nous avons fait developpé un logiciel qui est censé simuler le traitement des batchs, sauf qu'il n'est pas parallélisé et que les traitement s'executent les uns apres les autres.
S'il s'agit de _simuler_ il n'y a pas vraiment besoin d'utiliser plusieurs processus.
Une simulation avec "parallelisme", tenant compte du nombre de processeur et du nombre maximum de travaux simultané (ou éventuellement d'autres paramètres, comme le profil CPU ou I/O du travail, etc), pourrait donner comme résultat:
Ce n'est qu'une question d'additions, et il n'est pas nécessaire d'utiliser plusieurs processus pour les faire.
Un processus unix, lit une table de demande de jobs et soumet les jobs les uns apres les autres.
Je me dis que si ce processus j'arrivais a le Forké dans un autre je pourrais ainsi paralleliser les soumissions de job j'ai raison ou tord ?
Merci de me répondre et me dire comment faire.
S'il ne s'agit pas de simuler mais d'exécuter réellement ces travaux, le programme ordonanceur qui les lance automatiquement peut effectivement en lancer plusieurs à la fois, en "parallèle".
On ne veut pas forcément faire tourner deux copies de ce programme ordonanceur, car elles seraient indépendantes, et les travaux on certainement des contraintes d'ordonancement: certains travaux ne peuvent être exécutés que lorsque des phases précédentes ont été terminées (peut être avec condition de succès, ou avec des contrain tes de date, etc).
Dans tous les cas, le programme ordonanceur lance les travaux de manière classique sur unix, en fork-ant et execut-ant le travail, puis en attendant que le travail se termine avec wait(2) ou waitpid(2). Donc, fork(2) est déjà utilisé. La question est si le programme ordonanceur utilse wait(2) pour attendre la fin du travail avant de lancer le suivant on non.
Parmis les outils "standard" unix existants, on peut aussi considérer;
cron at batch nqs
http://www.google.com/search?qºtch+unix+scheduler
-- __Pascal Bourguignon__ http://www.informatimago.com/ Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects. The first system to really do this in an important way is Lisp. -- Alan Kay
merci monsieur.
En fait quand vous dites la commande Batch (et c'est vrai je n'y avais
pas pensé, c'est tout bete!!!) c'est peut etre le & en korn shell ?
merci
"freedba" <p.hirth@gmail.com> writes:
Bonjour,
Je vous explique mon probleme et si vous avez une solution merci de
m'aider.
Je ne suis pas un super pro du langage C ni d'unix, mais je connais un
peu le principe de la comamned Fork(), j'ai appris cela à l'ecole il
ya maintenant 20 ans.
Je suis dba Oracle, j'optimise mes bases et je m'occupe aussi des
serveurs Unix (AIX), j'installe, je sauvegarde, etc etc j'alloue des
disques je surveille un peu tout, pour vue que ca marche.
Et la j'ai un petit probleme. Nous avons fait developpé un logiciel
qui est censé simuler le traitement des batchs, sauf qu'il n'est pas
parallélisé et que les traitement s'executent les uns apres les
autres.
S'il s'agit de _simuler_ il n'y a pas vraiment besoin d'utiliser
plusieurs processus.
Une simulation avec "parallelisme", tenant compte du nombre de
processeur et du nombre maximum de travaux simultané (ou
éventuellement d'autres paramètres, comme le profil CPU ou I/O du
travail, etc), pourrait donner comme résultat:
Ce n'est qu'une question d'additions, et il n'est pas nécessaire
d'utiliser plusieurs processus pour les faire.
Un processus unix, lit une table de demande de jobs et soumet les
jobs les uns apres les autres.
Je me dis que si ce processus j'arrivais a le Forké dans un autre je
pourrais ainsi paralleliser les soumissions de job j'ai raison ou tord ?
Merci de me répondre et me dire comment faire.
S'il ne s'agit pas de simuler mais d'exécuter réellement ces travaux,
le programme ordonanceur qui les lance automatiquement peut
effectivement en lancer plusieurs à la fois, en "parallèle".
On ne veut pas forcément faire tourner deux copies de ce programme
ordonanceur, car elles seraient indépendantes, et les travaux on
certainement des contraintes d'ordonancement: certains travaux ne
peuvent être exécutés que lorsque des phases précédentes ont été
terminées (peut être avec condition de succès, ou avec des contrain tes
de date, etc).
Dans tous les cas, le programme ordonanceur lance les travaux de
manière classique sur unix, en fork-ant et execut-ant le travail, puis
en attendant que le travail se termine avec wait(2) ou waitpid(2).
Donc, fork(2) est déjà utilisé. La question est si le programme
ordonanceur utilse wait(2) pour attendre la fin du travail avant de
lancer le suivant on non.
Parmis les outils "standard" unix existants, on peut aussi considérer;
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
En fait quand vous dites la commande Batch (et c'est vrai je n'y avais pas pensé, c'est tout bete!!!) c'est peut etre le & en korn shell ?
merci
"freedba" writes:
Bonjour, Je vous explique mon probleme et si vous avez une solution merci de m'aider.
Je ne suis pas un super pro du langage C ni d'unix, mais je connais un peu le principe de la comamned Fork(), j'ai appris cela à l'ecole il ya maintenant 20 ans. Je suis dba Oracle, j'optimise mes bases et je m'occupe aussi des serveurs Unix (AIX), j'installe, je sauvegarde, etc etc j'alloue des disques je surveille un peu tout, pour vue que ca marche.
Et la j'ai un petit probleme. Nous avons fait developpé un logiciel qui est censé simuler le traitement des batchs, sauf qu'il n'est pas parallélisé et que les traitement s'executent les uns apres les autres.
S'il s'agit de _simuler_ il n'y a pas vraiment besoin d'utiliser plusieurs processus.
Une simulation avec "parallelisme", tenant compte du nombre de processeur et du nombre maximum de travaux simultané (ou éventuellement d'autres paramètres, comme le profil CPU ou I/O du travail, etc), pourrait donner comme résultat:
Ce n'est qu'une question d'additions, et il n'est pas nécessaire d'utiliser plusieurs processus pour les faire.
Un processus unix, lit une table de demande de jobs et soumet les jobs les uns apres les autres.
Je me dis que si ce processus j'arrivais a le Forké dans un autre je pourrais ainsi paralleliser les soumissions de job j'ai raison ou tord ?
Merci de me répondre et me dire comment faire.
S'il ne s'agit pas de simuler mais d'exécuter réellement ces travaux, le programme ordonanceur qui les lance automatiquement peut effectivement en lancer plusieurs à la fois, en "parallèle".
On ne veut pas forcément faire tourner deux copies de ce programme ordonanceur, car elles seraient indépendantes, et les travaux on certainement des contraintes d'ordonancement: certains travaux ne peuvent être exécutés que lorsque des phases précédentes ont été terminées (peut être avec condition de succès, ou avec des contrain tes de date, etc).
Dans tous les cas, le programme ordonanceur lance les travaux de manière classique sur unix, en fork-ant et execut-ant le travail, puis en attendant que le travail se termine avec wait(2) ou waitpid(2). Donc, fork(2) est déjà utilisé. La question est si le programme ordonanceur utilse wait(2) pour attendre la fin du travail avant de lancer le suivant on non.
Parmis les outils "standard" unix existants, on peut aussi considérer;
cron at batch nqs
http://www.google.com/search?qºtch+unix+scheduler
-- __Pascal Bourguignon__ http://www.informatimago.com/ Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects. The first system to really do this in an important way is Lisp. -- Alan Kay
Pascal Bourguignon
"freedba" writes:
En fait quand vous dites la commande Batch (et c'est vrai je n'y avais pas pensé, c'est tout bete!!!) c'est peut etre le & en korn shell ?
Non, il y a une commande nommée batch(1), qui permet de mettre en queue des travaux de traitement par lot qui seront lancés automatiquement quand la charge du système (donnée par uptime(1)) passe en dessous d'un seuil.
Si un travail lancé ne charge pas trop le système (s'il travaille principalement en E/S par exemple) alors batch pourra lancer un deuxième travail en parallèle, et ainsi de suite tant que la charge reste inférieure au seuil.
man man man batch man cron man at
La syntaxe & des shell permet de lancer un processus en tâche de fond. Ça correspond à un exec/fork. Bien entendu, on peut programmer en shell une gestion de travaux par lot en utilisant cette fonctionnalité (et la primitive shell wait(1)), comme on le programmerait en C ou n'importe quel autre langage. (Mais à mon avis, les shells ne sont pas adapté dès qu'il s'agit de faire des programmes de plus de deux lignes, je préfère programmer avec un vrai langage de programmation, comme Common Lisp).
D'ailleurs, batch est un script shell!
$ file $(which batch) /usr/bin/batch: Bourne shell script text
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any manner whatsoever, will increase the amount of disorder in the universe. Although no liability is implied herein, the consumer is warned that this process will ultimately lead to the heat death of the universe.
"freedba" <p.hirth@gmail.com> writes:
En fait quand vous dites la commande Batch (et c'est vrai je n'y avais
pas pensé, c'est tout bete!!!) c'est peut etre le & en korn shell ?
Non, il y a une commande nommée batch(1), qui permet de mettre en
queue des travaux de traitement par lot qui seront lancés
automatiquement quand la charge du système (donnée par uptime(1))
passe en dessous d'un seuil.
Si un travail lancé ne charge pas trop le système (s'il travaille
principalement en E/S par exemple) alors batch pourra lancer un
deuxième travail en parallèle, et ainsi de suite tant que la charge
reste inférieure au seuil.
man man
man batch
man cron
man at
La syntaxe & des shell permet de lancer un processus en tâche de fond.
Ça correspond à un exec/fork. Bien entendu, on peut programmer en
shell une gestion de travaux par lot en utilisant cette fonctionnalité
(et la primitive shell wait(1)), comme on le programmerait en C ou
n'importe quel autre langage. (Mais à mon avis, les shells ne sont
pas adapté dès qu'il s'agit de faire des programmes de plus de deux
lignes, je préfère programmer avec un vrai langage de programmation,
comme Common Lisp).
D'ailleurs, batch est un script shell!
$ file $(which batch)
/usr/bin/batch: Bourne shell script text
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
En fait quand vous dites la commande Batch (et c'est vrai je n'y avais pas pensé, c'est tout bete!!!) c'est peut etre le & en korn shell ?
Non, il y a une commande nommée batch(1), qui permet de mettre en queue des travaux de traitement par lot qui seront lancés automatiquement quand la charge du système (donnée par uptime(1)) passe en dessous d'un seuil.
Si un travail lancé ne charge pas trop le système (s'il travaille principalement en E/S par exemple) alors batch pourra lancer un deuxième travail en parallèle, et ainsi de suite tant que la charge reste inférieure au seuil.
man man man batch man cron man at
La syntaxe & des shell permet de lancer un processus en tâche de fond. Ça correspond à un exec/fork. Bien entendu, on peut programmer en shell une gestion de travaux par lot en utilisant cette fonctionnalité (et la primitive shell wait(1)), comme on le programmerait en C ou n'importe quel autre langage. (Mais à mon avis, les shells ne sont pas adapté dès qu'il s'agit de faire des programmes de plus de deux lignes, je préfère programmer avec un vrai langage de programmation, comme Common Lisp).
D'ailleurs, batch est un script shell!
$ file $(which batch) /usr/bin/batch: Bourne shell script text
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any manner whatsoever, will increase the amount of disorder in the universe. Although no liability is implied herein, the consumer is warned that this process will ultimately lead to the heat death of the universe.
Stephane Dupille
D'ailleurs, batch est un script shell! $ file $(which batch) /usr/bin/batch: Bourne shell script text
Pas partout : $ file ºtch /usr/bin/batch: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 6.1, dynamically linked (uses shared libs), stripped
D'ailleurs, batch est un script shell!
$ file $(which batch)
/usr/bin/batch: Bourne shell script text
Pas partout :
$ file ºtch
/usr/bin/batch: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 6.1, dynamically linked (uses shared libs), stripped
D'ailleurs, batch est un script shell! $ file $(which batch) /usr/bin/batch: Bourne shell script text
Pas partout : $ file ºtch /usr/bin/batch: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 6.1, dynamically linked (uses shared libs), stripped
Pascal Bourguignon
Stephane Dupille writes:
D'ailleurs, batch est un script shell! $ file $(which batch) /usr/bin/batch: Bourne shell script text
Pas partout : $ file ºtch /usr/bin/batch: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 6.1, dynamically linked (uses shared libs), stripped
Oui, bien sur, je voulais dire, "sur mon système".
-- __Pascal Bourguignon__ http://www.informatimago.com/ Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects. The first system to really do this in an important way is Lisp. -- Alan Kay
D'ailleurs, batch est un script shell!
$ file $(which batch)
/usr/bin/batch: Bourne shell script text
Pas partout :
$ file ºtch
/usr/bin/batch: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 6.1, dynamically linked (uses shared libs), stripped
Oui, bien sur, je voulais dire, "sur mon système".
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
D'ailleurs, batch est un script shell! $ file $(which batch) /usr/bin/batch: Bourne shell script text
Pas partout : $ file ºtch /usr/bin/batch: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 6.1, dynamically linked (uses shared libs), stripped
Oui, bien sur, je voulais dire, "sur mon système".
-- __Pascal Bourguignon__ http://www.informatimago.com/ Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects. The first system to really do this in an important way is Lisp. -- Alan Kay
Loïc Restoux
Le 18 jui, à 08:05, Pascal Bourguignon papotait :
D'ailleurs, batch est un script shell!
$ file $(which batch) /usr/bin/batch: Bourne shell script text
Sur mon système, il ne fait que 8 lignes, et appelle at. :)
-- No fortunes found
Le 18 jui, à 08:05, Pascal Bourguignon papotait :
D'ailleurs, batch est un script shell!
$ file $(which batch)
/usr/bin/batch: Bourne shell script text
Sur mon système, il ne fait que 8 lignes, et appelle at. :)
