un truc dont j'ai toujours rêvé et que je finirai par implémenter
à moins que cela n'existe déjà. Si cela existe, j'ignore quel terme
générique désigne déjà cet outil.
Comme j'ai l'habitude de lancer des gros (et longs) calculs sous
la forme de programme compilés ou de scripts divers, que ces derniers
écrivent à intervalles variables des résultats sur la sortie standard,
j'aimerais disposer d'une interface qui permette aisément:
- de démarrer un programme, éventuellement de lui donner un
nom plus parlant que a.out avec un petit commentaire ;
- à tout moment d'avoir à l'écran la liste de ces processus
(pas les autres ; je ne veux que les processus en question),
le temps écoulé;
- de sélectionner facilement un processus pour le tuer, modifier
sa priorité, etc.
- de sélectionner un processus pour avoir (éventuellement dans un
"panneau" à l'écran) ses dernières lignes affichées sur stdout
de sauver si besoin est lesdites lignes
- certains processus écrivant peut-être beaucoup d'informations
pas toujours destinées à être sauvées, de limiter la taille
en nombre de lignes de ces dernières, pouvoir éventuellement
les parcourir par "scroll"
- quelques gadgets : associer à chaque processus des règles
(regexp) pour jouer sur l'affichage (virer des lignes), mettre
en surbrillance certaines parties (exemple : les nombres)
(voire même: des regexp pour tuer le processus, pour beeper, etc.)
- de faire absolument tout ;-)
Ma préférence irait à un programme console (ncurses) ; je serais
toujours content de connaître l'existence d'un programme graphique
malgré tout. Un programme en ligne de commande irait aussi, mais
compte-tenu du descriptif ci-dessus, je doute que cela existe
vraiment. Si je devais le programmer, je le ferais avec ncurses,
auquel cas je serais content de savoir si ce genre de choses aurait
un intérêt à vos yeux.
Cordialement,
--
Thomas Baruchel --- Home Page: http://baruchel.free.fr/~thomas/
write to baruchel at the host called bluebottle dot com
écrire à baruchel chez l'hôte nommé bluebottle point com
(you will be asked for a confirmation the first time you write)
Ma préférence irait à un programme console (ncurses) ; je serais toujours content de connaître l'existence d'un programme graphique malgré tout.
top ? ça fait pas tout, mais ça fait déjà bcp.
Thomas Baruchel
top ? ça fait pas tout, mais ça fait déjà bcp. Compte-tenu de certaines réponses, je pense m'être mal expliqué.
J'ai sans doute eu tort de mettre en avant l'idée de processus. En fait, le but est exclusivement scientifique ; il s'agit de pouvoir gérer une dizaine de programmes compilés ou interprétés en ayant le plus de possibilités en termes de monitoring, de gestion bas niveau (ou autre), d'accessibilité à la sortie standard, etc. Pour régler certaines questions, j'utilise Unix depuis dix ans, et je ne cherchais à vrai dire pas telle ou telle commande. Je pensais vraiment à un "logiciel" que j'imagine être une sorte de "poste de contrôle" pour gérer ces calculs (et évidemment seulement cela ; je me fiche des autres processus). Ces calculs étant censés durer plusieurs jours, un certain confort offert par une interface ncurses me plairait, mais je sais bien que top, screen, nice, kill, etc. permettent de faire tout cela.
En fait, j'ai vaguement le souvenir d'avoir vu un jour un truc de ce genre, mais je ne me souviens plus où ni du nom. On voyait la liste des programmes lancés, et avec les flèches haut et bas, on pouvait se positionner pour lire la fin de leur stdout. Je crois que cela faisait aussi du monitoring : quand un processus affichait quelque chose, une asterisque (ou je ne sais plus) signalait que le processus avait affiché quelque chose, aussi pouvait-on se positionner sur lui pour voir quoi.
Travaillant exclusivement sous screen, je sais bien que l'on peut faire une partie de cela, mais pas tout à fait : on n'a pas la possibilité d'embrasser d'un coup d'oeil l'"efficacité" des processus, leur statut ; où ils en sont du calcul, etc.
En espérant avoir donné plus de précisions,
cordialement,
-- Thomas Baruchel --- Home Page: http://baruchel.free.fr/~thomas/ write to baruchel at the host called bluebottle dot com écrire à baruchel chez l'hôte nommé bluebottle point com (you will be asked for a confirmation the first time you write)
top ? ça fait pas tout, mais ça fait déjà bcp.
Compte-tenu de certaines réponses, je pense m'être mal expliqué.
J'ai sans doute eu tort de mettre en avant l'idée de processus.
En fait, le but est exclusivement scientifique ; il s'agit de
pouvoir gérer une dizaine de programmes compilés ou interprétés
en ayant le plus de possibilités en termes de monitoring, de
gestion bas niveau (ou autre), d'accessibilité à la sortie standard, etc.
Pour régler certaines questions, j'utilise Unix depuis dix ans, et
je ne cherchais à vrai dire pas telle ou telle commande. Je pensais
vraiment à un "logiciel" que j'imagine être une sorte de "poste de
contrôle" pour gérer ces calculs (et évidemment seulement cela ;
je me fiche des autres processus). Ces calculs étant censés durer
plusieurs jours, un certain confort offert par une interface
ncurses me plairait, mais je sais bien que top, screen, nice, kill,
etc. permettent de faire tout cela.
En fait, j'ai vaguement le souvenir d'avoir vu un jour un truc de
ce genre, mais je ne me souviens plus où ni du nom. On voyait la
liste des programmes lancés, et avec les flèches haut et bas, on
pouvait se positionner pour lire la fin de leur stdout. Je crois que
cela faisait aussi du monitoring : quand un processus affichait quelque
chose, une asterisque (ou je ne sais plus) signalait que le processus
avait affiché quelque chose, aussi pouvait-on se positionner sur lui
pour voir quoi.
Travaillant exclusivement sous screen, je sais bien que l'on peut
faire une partie de cela, mais pas tout à fait : on n'a pas la possibilité
d'embrasser d'un coup d'oeil l'"efficacité" des processus, leur
statut ; où ils en sont du calcul, etc.
En espérant avoir donné plus de précisions,
cordialement,
--
Thomas Baruchel --- Home Page: http://baruchel.free.fr/~thomas/
write to baruchel at the host called bluebottle dot com
écrire à baruchel chez l'hôte nommé bluebottle point com
(you will be asked for a confirmation the first time you write)
top ? ça fait pas tout, mais ça fait déjà bcp. Compte-tenu de certaines réponses, je pense m'être mal expliqué.
J'ai sans doute eu tort de mettre en avant l'idée de processus. En fait, le but est exclusivement scientifique ; il s'agit de pouvoir gérer une dizaine de programmes compilés ou interprétés en ayant le plus de possibilités en termes de monitoring, de gestion bas niveau (ou autre), d'accessibilité à la sortie standard, etc. Pour régler certaines questions, j'utilise Unix depuis dix ans, et je ne cherchais à vrai dire pas telle ou telle commande. Je pensais vraiment à un "logiciel" que j'imagine être une sorte de "poste de contrôle" pour gérer ces calculs (et évidemment seulement cela ; je me fiche des autres processus). Ces calculs étant censés durer plusieurs jours, un certain confort offert par une interface ncurses me plairait, mais je sais bien que top, screen, nice, kill, etc. permettent de faire tout cela.
En fait, j'ai vaguement le souvenir d'avoir vu un jour un truc de ce genre, mais je ne me souviens plus où ni du nom. On voyait la liste des programmes lancés, et avec les flèches haut et bas, on pouvait se positionner pour lire la fin de leur stdout. Je crois que cela faisait aussi du monitoring : quand un processus affichait quelque chose, une asterisque (ou je ne sais plus) signalait que le processus avait affiché quelque chose, aussi pouvait-on se positionner sur lui pour voir quoi.
Travaillant exclusivement sous screen, je sais bien que l'on peut faire une partie de cela, mais pas tout à fait : on n'a pas la possibilité d'embrasser d'un coup d'oeil l'"efficacité" des processus, leur statut ; où ils en sont du calcul, etc.
En espérant avoir donné plus de précisions,
cordialement,
-- Thomas Baruchel --- Home Page: http://baruchel.free.fr/~thomas/ write to baruchel at the host called bluebottle dot com écrire à baruchel chez l'hôte nommé bluebottle point com (you will be asked for a confirmation the first time you write)
talon
Thomas Baruchel wrote:
En espérant avoir donné plus de précisions,
Regardes si http://www.cs.wisc.edu/condor/ ne correspond pas à ce que tu cherches (je ne l'ai pas utilisé).
cordialement,
--
Michel TALON
Thomas Baruchel <baruchel@127.0.0.1> wrote:
En espérant avoir donné plus de précisions,
Regardes si
http://www.cs.wisc.edu/condor/
ne correspond pas à ce que tu cherches (je ne l'ai pas utilisé).
Regardes si http://www.cs.wisc.edu/condor/ ne correspond pas à ce que tu cherches (je ne l'ai pas utilisé).
cordialement,
--
Michel TALON
Thomas Baruchel
Regardes si http://www.cs.wisc.edu/condor/ ne correspond pas à ce que tu cherches (je ne l'ai pas utilisé). En tous les cas, la description correspond de très près, et en outre
il a l'air largement plus puissant que ce à quoi je pensais. Je vais explorer cette posibilité, mais il est clair que de toute façon à partir de là je pourrai mieux orienter des recherches sur Google.
Merci beaucoup,
-- Thomas Baruchel --- Home Page: http://baruchel.free.fr/~thomas/ write to baruchel at the host called bluebottle dot com écrire à baruchel chez l'hôte nommé bluebottle point com (you will be asked for a confirmation the first time you write)
Regardes si
http://www.cs.wisc.edu/condor/
ne correspond pas à ce que tu cherches (je ne l'ai pas utilisé).
En tous les cas, la description correspond de très près, et en outre
il a l'air largement plus puissant que ce à quoi je pensais. Je vais
explorer cette posibilité, mais il est clair que de toute façon à
partir de là je pourrai mieux orienter des recherches sur Google.
Merci beaucoup,
--
Thomas Baruchel --- Home Page: http://baruchel.free.fr/~thomas/
write to baruchel at the host called bluebottle dot com
écrire à baruchel chez l'hôte nommé bluebottle point com
(you will be asked for a confirmation the first time you write)
Regardes si http://www.cs.wisc.edu/condor/ ne correspond pas à ce que tu cherches (je ne l'ai pas utilisé). En tous les cas, la description correspond de très près, et en outre
il a l'air largement plus puissant que ce à quoi je pensais. Je vais explorer cette posibilité, mais il est clair que de toute façon à partir de là je pourrai mieux orienter des recherches sur Google.
Merci beaucoup,
-- Thomas Baruchel --- Home Page: http://baruchel.free.fr/~thomas/ write to baruchel at the host called bluebottle dot com écrire à baruchel chez l'hôte nommé bluebottle point com (you will be asked for a confirmation the first time you write)
Jérémy JUST
On 23 Oct 2005 09:57:19 GMT Thomas Baruchel wrote:
Il me semble que quelque chose appelé PBS correspond "un peu". Quelqu'un connaît-il et peut-il me dire si cela correspond réellement à ce que je décrivais ?
Il me semble que c'est plutôt un gestionnaire de files d'attente.
À ma connaissance, il ne permet pas de gérer les sorties des programmes comme tu le demandes, mais je me trompe peut-être.
-- Jérémy JUST
On 23 Oct 2005 09:57:19 GMT
Thomas Baruchel <baruchel@127.0.0.1> wrote:
Il me semble que quelque chose appelé PBS correspond "un peu".
Quelqu'un connaît-il et peut-il me dire si cela correspond
réellement à ce que je décrivais ?
Il me semble que c'est plutôt un gestionnaire de files d'attente.
À ma connaissance, il ne permet pas de gérer les sorties des
programmes comme tu le demandes, mais je me trompe peut-être.
On 23 Oct 2005 09:57:19 GMT Thomas Baruchel wrote:
Il me semble que quelque chose appelé PBS correspond "un peu". Quelqu'un connaît-il et peut-il me dire si cela correspond réellement à ce que je décrivais ?
Il me semble que c'est plutôt un gestionnaire de files d'attente.
À ma connaissance, il ne permet pas de gérer les sorties des programmes comme tu le demandes, mais je me trompe peut-être.
-- Jérémy JUST
Pascal Bourguignon
Thomas Baruchel writes:
Ces calculs étant censés durer plusieurs jours, un certain confort offert par une interface ncurses me plairait, mais je sais bien que top, screen, nice, kill, etc. permettent de faire tout cela.
Normalement, quand on lance un processus long, on le fait en tâche de fond, et en redirigeant sa sortie dans un fichier:
(oui, ça demande un peu de prévision quand on lance le programme, on ne peut pas se contenter de taper long-calcul-1 RET, et de se rendre compte de son erreur cinq minutes plus tard et de vouloir rediriger les sorties après coup).
Le principe d'unix est d'avoir plein de petits programmes qui font bien leur taf et rien que leur taf, et de laisser l'utilisateur les combiner pour obtenir le résultat qu'il veut.
Ce n'est donc pas surprenant de rencontrer trés peu d'utilitaire intégré en un seul gros programme, faisant tout ce que font les utilitaires unix en groupe modulaire.
Mais, si c'est une spécification utilisateur, c'est totalement valide, et il est effectivement possible de développer un logiciel qui te convient. Je pense que le mieux serait d'intégrer ces fonctionnalités au shell, section gestion des jobs.
Quand on lance une commande dans le shell, les E/S standard sont normalement attachées au terminal. Le shell pourrait les intercepter dans tous les cas, ce qui lui permetrait de les rediriger vers des fichiers, des pipes ou des terminaux en cours de route.
En fait, on pourrait trés bien ne pas afficher les résultats des commandes systématiquement comme le fait le shell actuellement. Il pourrait lancer toutes les commandes en tâche de fond, et afficher (dans un interface curses) une liste des commandes lancées avec leur status et un indicateur de sorties ou d'attente en entrée. L'opérateur pourrait alors choisir à quelle commande envoyer une entrée, ou de quelle commande lire les sorties, etc. Comme ça se faisait avec les systèmes orientés batch comme VM sur 360, etc, ou toutes les sorties allaient dans un spool imprimante (on n'imprimait pas tout, on visualisait les spools sur des terminaux, mais toutes les sorties passaient par des fichiers spool).
(En fait 99% de ce que tu demande pourrait être programmé dans un script bash, en utilisant les outils unix existant).
-- __Pascal Bourguignon__ http://www.informatimago.com/ The rule for today: Touch my tail, I shred your hand. New rule tomorrow.
Thomas Baruchel <baruchel@127.0.0.1> writes:
Ces calculs étant censés durer
plusieurs jours, un certain confort offert par une interface
ncurses me plairait, mais je sais bien que top, screen, nice, kill,
etc. permettent de faire tout cela.
Normalement, quand on lance un processus long, on le fait en tâche de
fond, et en redirigeant sa sortie dans un fichier:
(oui, ça demande un peu de prévision quand on lance le programme, on
ne peut pas se contenter de taper long-calcul-1 RET, et de se rendre
compte de son erreur cinq minutes plus tard et de vouloir rediriger
les sorties après coup).
Le principe d'unix est d'avoir plein de petits programmes qui font
bien leur taf et rien que leur taf, et de laisser l'utilisateur les
combiner pour obtenir le résultat qu'il veut.
Ce n'est donc pas surprenant de rencontrer trés peu d'utilitaire
intégré en un seul gros programme, faisant tout ce que font les
utilitaires unix en groupe modulaire.
Mais, si c'est une spécification utilisateur, c'est totalement valide,
et il est effectivement possible de développer un logiciel qui te
convient. Je pense que le mieux serait d'intégrer ces fonctionnalités
au shell, section gestion des jobs.
Quand on lance une commande dans le shell, les E/S standard sont
normalement attachées au terminal. Le shell pourrait les intercepter
dans tous les cas, ce qui lui permetrait de les rediriger vers des
fichiers, des pipes ou des terminaux en cours de route.
En fait, on pourrait trés bien ne pas afficher les résultats des
commandes systématiquement comme le fait le shell actuellement. Il
pourrait lancer toutes les commandes en tâche de fond, et afficher
(dans un interface curses) une liste des commandes lancées avec leur
status et un indicateur de sorties ou d'attente en entrée. L'opérateur
pourrait alors choisir à quelle commande envoyer une entrée, ou de
quelle commande lire les sorties, etc. Comme ça se faisait avec les
systèmes orientés batch comme VM sur 360, etc, ou toutes les sorties
allaient dans un spool imprimante (on n'imprimait pas tout, on
visualisait les spools sur des terminaux, mais toutes les sorties
passaient par des fichiers spool).
(En fait 99% de ce que tu demande pourrait être programmé dans un
script bash, en utilisant les outils unix existant).
--
__Pascal Bourguignon__ http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.
Ces calculs étant censés durer plusieurs jours, un certain confort offert par une interface ncurses me plairait, mais je sais bien que top, screen, nice, kill, etc. permettent de faire tout cela.
Normalement, quand on lance un processus long, on le fait en tâche de fond, et en redirigeant sa sortie dans un fichier:
(oui, ça demande un peu de prévision quand on lance le programme, on ne peut pas se contenter de taper long-calcul-1 RET, et de se rendre compte de son erreur cinq minutes plus tard et de vouloir rediriger les sorties après coup).
Le principe d'unix est d'avoir plein de petits programmes qui font bien leur taf et rien que leur taf, et de laisser l'utilisateur les combiner pour obtenir le résultat qu'il veut.
Ce n'est donc pas surprenant de rencontrer trés peu d'utilitaire intégré en un seul gros programme, faisant tout ce que font les utilitaires unix en groupe modulaire.
Mais, si c'est une spécification utilisateur, c'est totalement valide, et il est effectivement possible de développer un logiciel qui te convient. Je pense que le mieux serait d'intégrer ces fonctionnalités au shell, section gestion des jobs.
Quand on lance une commande dans le shell, les E/S standard sont normalement attachées au terminal. Le shell pourrait les intercepter dans tous les cas, ce qui lui permetrait de les rediriger vers des fichiers, des pipes ou des terminaux en cours de route.
En fait, on pourrait trés bien ne pas afficher les résultats des commandes systématiquement comme le fait le shell actuellement. Il pourrait lancer toutes les commandes en tâche de fond, et afficher (dans un interface curses) une liste des commandes lancées avec leur status et un indicateur de sorties ou d'attente en entrée. L'opérateur pourrait alors choisir à quelle commande envoyer une entrée, ou de quelle commande lire les sorties, etc. Comme ça se faisait avec les systèmes orientés batch comme VM sur 360, etc, ou toutes les sorties allaient dans un spool imprimante (on n'imprimait pas tout, on visualisait les spools sur des terminaux, mais toutes les sorties passaient par des fichiers spool).
(En fait 99% de ce que tu demande pourrait être programmé dans un script bash, en utilisant les outils unix existant).
-- __Pascal Bourguignon__ http://www.informatimago.com/ The rule for today: Touch my tail, I shred your hand. New rule tomorrow.
Thomas Baruchel
Le principe d'unix est d'avoir plein de petits programmes qui font bien leur taf et rien que leur taf, et de laisser l'utilisateur les combiner pour obtenir le résultat qu'il veut.
:-) Certes, je le sais bien ; c'est précisément comme cela que je procède, faute de mieux, depuis des années. Maintenant, c'est précisément parce que j'ai souvent regretté de ne pas avoir plus de confort pour telle ou telle tâche que je pose la question. Dans ces cas : soit on accumule progressivement au fil des ans, des macros, qui à la longue deviennent quasiment tout un environnement ; soit on pose la question de savoir si le besoin s'est déjà rencontré. En effet,
(En fait 99% de ce que tu demande pourrait être programmé dans un script bash, en utilisant les outils unix existant).
99% de ce que mutt fait se fait aussi avec mh, et bien plus encore de ce que fait ncftp se fait avec ftp. Maintenant, si on utilise le FTP sur une machine tous les six mois, autant passer par ftp et ne pas installer ncftp. Si le principal usage de la machine va dans ce sens, autant utiliser ncftp qui n'ajoute pas grand chose si ce n'est que quand on essaie on trouve quand même que cela ajoute quelque chose ;-)
Dans mon cas, les ordis de la maison sont constamment en train de faire tourner des calculs. Alors bien sûr, le matin en me levant, je peux faire quinze 'tail' ou basculer de fenêtre screen en fenêtre screen, pareillement quand je rentre du travail ou quand j'ai fini de prendre mon thé. Mon besoin est limité et je peux vivre sans, mais je ne crois pas que ma question était à ce point aberrante (la preuve, le logiciel Condor qui semble proche de ce que je veux existe) : ne se pourrait-il qu'un environnement sympa ne me présente un 'digest' interactif des calculs en cours. Dans la pratique, les processus écrivent si rarement, que cela peut être sympa qu'au moment où j'arrive devant l'écran, ce soit précisement le dernier processus à avoir écrit dont j'ai l'affichage à l'écran avec par ailleurs toutes sortes d'informations sur l'heure à laquelle la ligne est "tombée", etc.
Encore une fois, nous sommes d'accord sur le fond ; je peux faire sans. Mais je pense que le besoin ne s'évalue pas qu'en termes de possibilités de faire. Si l'utilisation est régulière, voire constante, il est normal de chercher un certain confort ; libre à toi d'y voir une facilité qui va à l'encontre de l'esprit Unix.
Bien cordialement,
P.-S. - Ah, au fait : 99% de ce que fait Linux se fait aussi sous un vrai Unix, non ?
-- Thomas Baruchel --- Home Page: http://baruchel.free.fr/~thomas/ write to baruchel at the host called bluebottle dot com écrire à baruchel chez l'hôte nommé bluebottle point com (you will be asked for a confirmation the first time you write)
Le principe d'unix est d'avoir plein de petits programmes qui font
bien leur taf et rien que leur taf, et de laisser l'utilisateur les
combiner pour obtenir le résultat qu'il veut.
:-) Certes, je le sais bien ; c'est précisément comme cela que je
procède, faute de mieux, depuis des années. Maintenant, c'est
précisément parce que j'ai souvent regretté de ne pas avoir plus
de confort pour telle ou telle tâche que je pose la question.
Dans ces cas : soit on accumule progressivement au fil des ans,
des macros, qui à la longue deviennent quasiment tout un
environnement ; soit on pose la question de savoir si le besoin
s'est déjà rencontré. En effet,
(En fait 99% de ce que tu demande pourrait être programmé dans un
script bash, en utilisant les outils unix existant).
99% de ce que mutt fait se fait aussi avec mh, et bien plus encore
de ce que fait ncftp se fait avec ftp. Maintenant, si on utilise le
FTP sur une machine tous les six mois, autant passer par ftp et ne
pas installer ncftp. Si le principal usage de la machine va dans ce
sens, autant utiliser ncftp qui n'ajoute pas grand chose si ce n'est
que quand on essaie on trouve quand même que cela ajoute quelque chose ;-)
Dans mon cas, les ordis de la maison sont constamment en train de faire
tourner des calculs. Alors bien sûr, le matin en me levant, je peux
faire quinze 'tail' ou basculer de fenêtre screen en fenêtre screen,
pareillement quand je rentre du travail ou quand j'ai fini de prendre
mon thé. Mon besoin est limité et je peux vivre sans, mais je ne crois
pas que ma question était à ce point aberrante (la preuve, le logiciel
Condor qui semble proche de ce que je veux existe) : ne se pourrait-il
qu'un environnement sympa ne me présente un 'digest' interactif des calculs
en cours. Dans la pratique, les processus écrivent si rarement, que cela
peut être sympa qu'au moment où j'arrive devant l'écran, ce soit précisement
le dernier processus à avoir écrit dont j'ai l'affichage à l'écran
avec par ailleurs toutes sortes d'informations sur l'heure à laquelle
la ligne est "tombée", etc.
Encore une fois, nous sommes d'accord sur le fond ; je peux faire sans.
Mais je pense que le besoin ne s'évalue pas qu'en termes de possibilités
de faire. Si l'utilisation est régulière, voire constante, il est
normal de chercher un certain confort ; libre à toi d'y voir une
facilité qui va à l'encontre de l'esprit Unix.
Bien cordialement,
P.-S. - Ah, au fait : 99% de ce que fait Linux se fait aussi sous
un vrai Unix, non ?
--
Thomas Baruchel --- Home Page: http://baruchel.free.fr/~thomas/
write to baruchel at the host called bluebottle dot com
écrire à baruchel chez l'hôte nommé bluebottle point com
(you will be asked for a confirmation the first time you write)
Le principe d'unix est d'avoir plein de petits programmes qui font bien leur taf et rien que leur taf, et de laisser l'utilisateur les combiner pour obtenir le résultat qu'il veut.
:-) Certes, je le sais bien ; c'est précisément comme cela que je procède, faute de mieux, depuis des années. Maintenant, c'est précisément parce que j'ai souvent regretté de ne pas avoir plus de confort pour telle ou telle tâche que je pose la question. Dans ces cas : soit on accumule progressivement au fil des ans, des macros, qui à la longue deviennent quasiment tout un environnement ; soit on pose la question de savoir si le besoin s'est déjà rencontré. En effet,
(En fait 99% de ce que tu demande pourrait être programmé dans un script bash, en utilisant les outils unix existant).
99% de ce que mutt fait se fait aussi avec mh, et bien plus encore de ce que fait ncftp se fait avec ftp. Maintenant, si on utilise le FTP sur une machine tous les six mois, autant passer par ftp et ne pas installer ncftp. Si le principal usage de la machine va dans ce sens, autant utiliser ncftp qui n'ajoute pas grand chose si ce n'est que quand on essaie on trouve quand même que cela ajoute quelque chose ;-)
Dans mon cas, les ordis de la maison sont constamment en train de faire tourner des calculs. Alors bien sûr, le matin en me levant, je peux faire quinze 'tail' ou basculer de fenêtre screen en fenêtre screen, pareillement quand je rentre du travail ou quand j'ai fini de prendre mon thé. Mon besoin est limité et je peux vivre sans, mais je ne crois pas que ma question était à ce point aberrante (la preuve, le logiciel Condor qui semble proche de ce que je veux existe) : ne se pourrait-il qu'un environnement sympa ne me présente un 'digest' interactif des calculs en cours. Dans la pratique, les processus écrivent si rarement, que cela peut être sympa qu'au moment où j'arrive devant l'écran, ce soit précisement le dernier processus à avoir écrit dont j'ai l'affichage à l'écran avec par ailleurs toutes sortes d'informations sur l'heure à laquelle la ligne est "tombée", etc.
Encore une fois, nous sommes d'accord sur le fond ; je peux faire sans. Mais je pense que le besoin ne s'évalue pas qu'en termes de possibilités de faire. Si l'utilisation est régulière, voire constante, il est normal de chercher un certain confort ; libre à toi d'y voir une facilité qui va à l'encontre de l'esprit Unix.
Bien cordialement,
P.-S. - Ah, au fait : 99% de ce que fait Linux se fait aussi sous un vrai Unix, non ?
-- Thomas Baruchel --- Home Page: http://baruchel.free.fr/~thomas/ write to baruchel at the host called bluebottle dot com écrire à baruchel chez l'hôte nommé bluebottle point com (you will be asked for a confirmation the first time you write)
Gilles Civario
Ce que tu cherche s'appelle un batch scheduler. C'est livré en standard sur toutes le machines de calcul centralisées. Sous Unix, le plus commun s'appelle Torque (ex OpenPBS, issue de PBS). Il existe aussi Sun Grid Engine, Condor, LSF ... En générale, tout se pilote avec: - soumission : qsub - interrogation : qstat - récupération de sorties : qcat - destruction : qdel
Gilles
Thomas Baruchel wrote:
Bonjour,
un truc dont j'ai toujours rêvé et que je finirai par implémenter à moins que cela n'existe déjà. Si cela existe, j'ignore quel terme générique désigne déjà cet outil.
Comme j'ai l'habitude de lancer des gros (et longs) calculs sous la forme de programme compilés ou de scripts divers, que ces derniers écrivent à intervalles variables des résultats sur la sortie standard, j'aimerais disposer d'une interface qui permette aisément: - de démarrer un programme, éventuellement de lui donner un nom plus parlant que a.out avec un petit commentaire ; - à tout moment d'avoir à l'écran la liste de ces processus (pas les autres ; je ne veux que les processus en question), le temps écoulé; - de sélectionner facilement un processus pour le tuer, modifier sa priorité, etc. - de sélectionner un processus pour avoir (éventuellement dans un "panneau" à l'écran) ses dernières lignes affichées sur stdout de sauver si besoin est lesdites lignes - certains processus écrivant peut-être beaucoup d'informations pas toujours destinées à être sauvées, de limiter la taille en nombre de lignes de ces dernières, pouvoir éventuellement les parcourir par "scroll" - quelques gadgets : associer à chaque processus des règles (regexp) pour jouer sur l'affichage (virer des lignes), mettre en surbrillance certaines parties (exemple : les nombres) (voire même: des regexp pour tuer le processus, pour beeper, etc.) - de faire absolument tout ;-)
Ma préférence irait à un programme console (ncurses) ; je serais toujours content de connaître l'existence d'un programme graphique malgré tout. Un programme en ligne de commande irait aussi, mais compte-tenu du descriptif ci-dessus, je doute que cela existe vraiment. Si je devais le programmer, je le ferais avec ncurses, auquel cas je serais content de savoir si ce genre de choses aurait un intérêt à vos yeux.
Cordialement,
Ce que tu cherche s'appelle un batch scheduler.
C'est livré en standard sur toutes le machines de calcul
centralisées.
Sous Unix, le plus commun s'appelle Torque (ex OpenPBS, issue
de PBS). Il existe aussi Sun Grid Engine, Condor, LSF ...
En générale, tout se pilote avec:
- soumission : qsub
- interrogation : qstat
- récupération de sorties : qcat
- destruction : qdel
Gilles
Thomas Baruchel wrote:
Bonjour,
un truc dont j'ai toujours rêvé et que je finirai par implémenter
à moins que cela n'existe déjà. Si cela existe, j'ignore quel terme
générique désigne déjà cet outil.
Comme j'ai l'habitude de lancer des gros (et longs) calculs sous
la forme de programme compilés ou de scripts divers, que ces derniers
écrivent à intervalles variables des résultats sur la sortie standard,
j'aimerais disposer d'une interface qui permette aisément:
- de démarrer un programme, éventuellement de lui donner un
nom plus parlant que a.out avec un petit commentaire ;
- à tout moment d'avoir à l'écran la liste de ces processus
(pas les autres ; je ne veux que les processus en question),
le temps écoulé;
- de sélectionner facilement un processus pour le tuer, modifier
sa priorité, etc.
- de sélectionner un processus pour avoir (éventuellement dans un
"panneau" à l'écran) ses dernières lignes affichées sur stdout
de sauver si besoin est lesdites lignes
- certains processus écrivant peut-être beaucoup d'informations
pas toujours destinées à être sauvées, de limiter la taille
en nombre de lignes de ces dernières, pouvoir éventuellement
les parcourir par "scroll"
- quelques gadgets : associer à chaque processus des règles
(regexp) pour jouer sur l'affichage (virer des lignes), mettre
en surbrillance certaines parties (exemple : les nombres)
(voire même: des regexp pour tuer le processus, pour beeper, etc.)
- de faire absolument tout ;-)
Ma préférence irait à un programme console (ncurses) ; je serais
toujours content de connaître l'existence d'un programme graphique
malgré tout. Un programme en ligne de commande irait aussi, mais
compte-tenu du descriptif ci-dessus, je doute que cela existe
vraiment. Si je devais le programmer, je le ferais avec ncurses,
auquel cas je serais content de savoir si ce genre de choses aurait
un intérêt à vos yeux.
Ce que tu cherche s'appelle un batch scheduler. C'est livré en standard sur toutes le machines de calcul centralisées. Sous Unix, le plus commun s'appelle Torque (ex OpenPBS, issue de PBS). Il existe aussi Sun Grid Engine, Condor, LSF ... En générale, tout se pilote avec: - soumission : qsub - interrogation : qstat - récupération de sorties : qcat - destruction : qdel
Gilles
Thomas Baruchel wrote:
Bonjour,
un truc dont j'ai toujours rêvé et que je finirai par implémenter à moins que cela n'existe déjà. Si cela existe, j'ignore quel terme générique désigne déjà cet outil.
Comme j'ai l'habitude de lancer des gros (et longs) calculs sous la forme de programme compilés ou de scripts divers, que ces derniers écrivent à intervalles variables des résultats sur la sortie standard, j'aimerais disposer d'une interface qui permette aisément: - de démarrer un programme, éventuellement de lui donner un nom plus parlant que a.out avec un petit commentaire ; - à tout moment d'avoir à l'écran la liste de ces processus (pas les autres ; je ne veux que les processus en question), le temps écoulé; - de sélectionner facilement un processus pour le tuer, modifier sa priorité, etc. - de sélectionner un processus pour avoir (éventuellement dans un "panneau" à l'écran) ses dernières lignes affichées sur stdout de sauver si besoin est lesdites lignes - certains processus écrivant peut-être beaucoup d'informations pas toujours destinées à être sauvées, de limiter la taille en nombre de lignes de ces dernières, pouvoir éventuellement les parcourir par "scroll" - quelques gadgets : associer à chaque processus des règles (regexp) pour jouer sur l'affichage (virer des lignes), mettre en surbrillance certaines parties (exemple : les nombres) (voire même: des regexp pour tuer le processus, pour beeper, etc.) - de faire absolument tout ;-)
Ma préférence irait à un programme console (ncurses) ; je serais toujours content de connaître l'existence d'un programme graphique malgré tout. Un programme en ligne de commande irait aussi, mais compte-tenu du descriptif ci-dessus, je doute que cela existe vraiment. Si je devais le programmer, je le ferais avec ncurses, auquel cas je serais content de savoir si ce genre de choses aurait un intérêt à vos yeux.
