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)
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
[...]
Avec "batch" dans le moteur de recherche de http://freshmeat.net/ il y a des réponses qui semblent plus ou moins correspondre à ce que tu décrit.
La viande fraiche, c'est bon, mangez-en.
-- | Dans les OS Microsoft, "AUX" est un mot réservé, tout comme "CON", | "COM", "LPT", "NUL", "PRN", qui désignent des flux d'entrée-sortie | particuliers. Je suis fort aise de savoir que "CON" et "NUL" sont réservés à Microsoft!
On 2005-10-22, Thomas Baruchel <baruchel@127.0.0.1> wrote:
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
[...]
Avec "batch" dans le moteur de recherche de http://freshmeat.net/
il y a des réponses qui semblent plus ou moins correspondre à
ce que tu décrit.
La viande fraiche, c'est bon, mangez-en.
--
| Dans les OS Microsoft, "AUX" est un mot réservé, tout comme "CON",
| "COM", "LPT", "NUL", "PRN", qui désignent des flux d'entrée-sortie
| particuliers.
Je suis fort aise de savoir que "CON" et "NUL" sont réservés à Microsoft!
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
[...]
Avec "batch" dans le moteur de recherche de http://freshmeat.net/ il y a des réponses qui semblent plus ou moins correspondre à ce que tu décrit.
La viande fraiche, c'est bon, mangez-en.
-- | Dans les OS Microsoft, "AUX" est un mot réservé, tout comme "CON", | "COM", "LPT", "NUL", "PRN", qui désignent des flux d'entrée-sortie | particuliers. Je suis fort aise de savoir que "CON" et "NUL" sont réservés à Microsoft!
Thomas Baruchel
- de démarrer un programme, éventuellement de lui donner un nom plus parlant que a.out avec un petit commentaire ; Je me rends compte que la formule ci-dessus est un peu ambiguë :
je ne demande pas à une âme généreuse de me faire découvrir l'option -o de gcc ou la commande 'mv'. Il m'arrive fréquemment d'écrire un bout de code non destiné à passer à la postérité, que je compile rapidement, que je lance, puis, PENDANT QUE LE PROCESSUS, destiné à durer plusieurs jours, travaille, de tout de suite retravailler le code (en changeant une variable par exemple), de recompiler, d'écraser le fichier binaire, puis de lancer un second processus légèrement différent.
Ce que j'appelais "donner un nom", c'est non pas modifier le nom du fichier dont je me contrefiche (en général donc /tmp/a.out) mais plutôt *à l'écran* de faire appraître le processus comme "algorithme n°2 avec xB" plutôt que par son PID, un peu moins parlant... Lui donner un commentaire, c'est faire en sorte que si je me positionne sur ce processus nommé comme je l'indique en exemple, voir apparaître (par exemple dans un panneau dédié à des informations) : "Je fais le test avec telle ou telle variable parce que les résultats de l'algo machin chouette m'ont laissé penser que etc. Penser à tuer le processus jeudi 32 octobre s'il n'a toujours rien donné". Trois ou quatre lignes donc que j'aurais écrites au lancement, avec éventuellement la possibilité de les modifier par la suite.
En espérant avoir été plus clair,
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)
- de démarrer un programme, éventuellement de lui donner un
nom plus parlant que a.out avec un petit commentaire ;
Je me rends compte que la formule ci-dessus est un peu ambiguë :
je ne demande pas à une âme généreuse de me faire découvrir
l'option -o de gcc ou la commande 'mv'.
Il m'arrive fréquemment d'écrire un bout de code non destiné à
passer à la postérité, que je compile rapidement, que je lance,
puis, PENDANT QUE LE PROCESSUS, destiné à durer plusieurs jours,
travaille, de tout de suite retravailler le code (en changeant
une variable par exemple), de recompiler, d'écraser le fichier
binaire, puis de lancer un second processus légèrement différent.
Ce que j'appelais "donner un nom", c'est non pas modifier le
nom du fichier dont je me contrefiche (en général donc /tmp/a.out)
mais plutôt *à l'écran* de faire appraître le processus
comme "algorithme n°2 avec xB" plutôt que par son PID, un peu
moins parlant... Lui donner un commentaire, c'est faire en sorte
que si je me positionne sur ce processus nommé comme je l'indique
en exemple, voir apparaître (par exemple dans un panneau dédié
à des informations) : "Je fais le test avec telle ou telle variable
parce que les résultats de l'algo machin chouette m'ont laissé
penser que etc. Penser à tuer le processus jeudi 32 octobre s'il
n'a toujours rien donné". Trois ou quatre lignes donc que j'aurais
écrites au lancement, avec éventuellement la possibilité de les
modifier par la suite.
En espérant avoir été plus clair,
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)
- de démarrer un programme, éventuellement de lui donner un nom plus parlant que a.out avec un petit commentaire ; Je me rends compte que la formule ci-dessus est un peu ambiguë :
je ne demande pas à une âme généreuse de me faire découvrir l'option -o de gcc ou la commande 'mv'. Il m'arrive fréquemment d'écrire un bout de code non destiné à passer à la postérité, que je compile rapidement, que je lance, puis, PENDANT QUE LE PROCESSUS, destiné à durer plusieurs jours, travaille, de tout de suite retravailler le code (en changeant une variable par exemple), de recompiler, d'écraser le fichier binaire, puis de lancer un second processus légèrement différent.
Ce que j'appelais "donner un nom", c'est non pas modifier le nom du fichier dont je me contrefiche (en général donc /tmp/a.out) mais plutôt *à l'écran* de faire appraître le processus comme "algorithme n°2 avec xB" plutôt que par son PID, un peu moins parlant... Lui donner un commentaire, c'est faire en sorte que si je me positionne sur ce processus nommé comme je l'indique en exemple, voir apparaître (par exemple dans un panneau dédié à des informations) : "Je fais le test avec telle ou telle variable parce que les résultats de l'algo machin chouette m'ont laissé penser que etc. Penser à tuer le processus jeudi 32 octobre s'il n'a toujours rien donné". Trois ou quatre lignes donc que j'aurais écrites au lancement, avec éventuellement la possibilité de les modifier par la suite.
En espérant avoir été plus clair,
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)
David
Le Sat, 22 Oct 2005 16:38:01 +0000, Thomas Baruchel a écrit :
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.
En fonction de ton OS, parcourir /proc peux t'aider à faire un truc rapide et qui corresponde à ton besoin.
Le Sat, 22 Oct 2005 16:38:01 +0000, Thomas Baruchel a écrit :
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.
En fonction de ton OS, parcourir /proc peux t'aider à faire un truc
rapide et qui corresponde à ton besoin.
Le Sat, 22 Oct 2005 16:38:01 +0000, Thomas Baruchel a écrit :
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.
En fonction de ton OS, parcourir /proc peux t'aider à faire un truc rapide et qui corresponde à ton besoin.
Pascal Bourguignon
Thomas Baruchel writes:
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 ;
mv a.out nom-parlant ou simplement, utiliser l'option -o de gcc gcc mon-programme.c -o nom-parlant
- à 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é;
top Bon, si tu ne veux qu'une liste de processus donnés, tu peux faire: sudo useradd processus-donnes su - processus-donnes sh -c 'nom-parlant-1 &' su - processus-donnes sh -c 'nom-parlant-2 &' puis: top RET u processus-donnse RET
- de sélectionner facilement un processus pour le tuer, modifier sa priorité, etc.
Pareil, il y a des commandes dans top pour faire ça.
- 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
S'il faut gérer des sorties, passer par screen au lieu d'utiliser su directement:
screen -dmS su - processus-donnes nom-parlant-1 screen -dmS su - processus-donnes nom-parlant-2
Puis, quand on veux se connecter aux E/S standard du processus: su - processus-donnes screen -list # pour voir les processus disponibles su - processus-donnes screen -r ID # pour se connecter C-a C-d # pour se déconnecter.
- 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"
screen a une option pour écrire un journal des sortie. On peut utiliser more ou less sur ces journaux.
- 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.)
grep fait ça trés bien:
screen -L -dmS su - processus-donnes sh -c 'nom-parlant-1 | grep -v ligne-a-virer'
- de faire absolument tout ;-)
Unix fait absolument tout. Que veux tu de plus? Apprends à te servir d'unix!!
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.
Personnellement j'utilise rarement screen, car emacs fait presque tout ce que fait screen, de manière intégrée: on peut lancer plusieurs processus dans plusieurs tampons shell, on peut ouvrir des frame sur d'autres serveurs X, et maintenant avec le patch multitty, aussi sur des terminaux, etc.
Ceci dit, on peut effectivement considérer un tel outil, qui permet de centraliser les dialogues avec des programmes plutôt orientés traitement par lot. Sur unix, on a tendance à ne voir que les processus interactifs, et avec le progrès des processeurs, tout traitement par lot devient traitement interactif. Un traitement qui prend une heure (3600 secondes) aujourd'hui sur un processeur à 1GHz, ne prendra que 3.6 secondes sur un cell-processeur à 10 processeurs à 100GHz dans 10 ans, et sera alors un traitement interactif.
Je conseillerais d'utiliser un peu VM (avec l'émulateur Hercules) pour prendre quelques idées pour ce qui est du dialogue opérateur avec plusieurs traitements par lot ou tâches de fond dans un terminal.
Le mieux serait peut être d'intégrer ces fonctionnalités à la gestion des jobs du shell (bash).
In a World without Walls and Fences, who needs Windows and Gates?
Thomas Baruchel <baruchel@127.0.0.1> writes:
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 ;
mv a.out nom-parlant
ou simplement, utiliser l'option -o de gcc
gcc mon-programme.c -o nom-parlant
- à 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é;
top
Bon, si tu ne veux qu'une liste de processus donnés, tu peux faire:
sudo useradd processus-donnes
su - processus-donnes sh -c 'nom-parlant-1 &'
su - processus-donnes sh -c 'nom-parlant-2 &'
puis:
top RET u processus-donnse RET
- de sélectionner facilement un processus pour le tuer, modifier
sa priorité, etc.
Pareil, il y a des commandes dans top pour faire ça.
- 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
S'il faut gérer des sorties, passer par screen au lieu d'utiliser su
directement:
screen -dmS su - processus-donnes nom-parlant-1
screen -dmS su - processus-donnes nom-parlant-2
Puis, quand on veux se connecter aux E/S standard du processus:
su - processus-donnes screen -list # pour voir les processus disponibles
su - processus-donnes screen -r ID # pour se connecter
C-a C-d # pour se déconnecter.
- 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"
screen a une option pour écrire un journal des sortie. On peut
utiliser more ou less sur ces journaux.
- 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.)
grep fait ça trés bien:
screen -L -dmS su - processus-donnes
sh -c 'nom-parlant-1 | grep -v ligne-a-virer'
- de faire absolument tout ;-)
Unix fait absolument tout. Que veux tu de plus? Apprends à te servir d'unix!!
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.
Personnellement j'utilise rarement screen, car emacs fait presque tout
ce que fait screen, de manière intégrée: on peut lancer plusieurs
processus dans plusieurs tampons shell, on peut ouvrir des frame sur
d'autres serveurs X, et maintenant avec le patch multitty, aussi sur
des terminaux, etc.
Ceci dit, on peut effectivement considérer un tel outil, qui permet de
centraliser les dialogues avec des programmes plutôt orientés
traitement par lot. Sur unix, on a tendance à ne voir que les
processus interactifs, et avec le progrès des processeurs, tout
traitement par lot devient traitement interactif. Un traitement qui
prend une heure (3600 secondes) aujourd'hui sur un processeur à 1GHz,
ne prendra que 3.6 secondes sur un cell-processeur à 10 processeurs à
100GHz dans 10 ans, et sera alors un traitement interactif.
Je conseillerais d'utiliser un peu VM (avec l'émulateur Hercules) pour
prendre quelques idées pour ce qui est du dialogue opérateur avec
plusieurs traitements par lot ou tâches de fond dans un terminal.
Le mieux serait peut être d'intégrer ces fonctionnalités à la gestion
des jobs du shell (bash).
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 ;
mv a.out nom-parlant ou simplement, utiliser l'option -o de gcc gcc mon-programme.c -o nom-parlant
- à 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é;
top Bon, si tu ne veux qu'une liste de processus donnés, tu peux faire: sudo useradd processus-donnes su - processus-donnes sh -c 'nom-parlant-1 &' su - processus-donnes sh -c 'nom-parlant-2 &' puis: top RET u processus-donnse RET
- de sélectionner facilement un processus pour le tuer, modifier sa priorité, etc.
Pareil, il y a des commandes dans top pour faire ça.
- 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
S'il faut gérer des sorties, passer par screen au lieu d'utiliser su directement:
screen -dmS su - processus-donnes nom-parlant-1 screen -dmS su - processus-donnes nom-parlant-2
Puis, quand on veux se connecter aux E/S standard du processus: su - processus-donnes screen -list # pour voir les processus disponibles su - processus-donnes screen -r ID # pour se connecter C-a C-d # pour se déconnecter.
- 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"
screen a une option pour écrire un journal des sortie. On peut utiliser more ou less sur ces journaux.
- 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.)
grep fait ça trés bien:
screen -L -dmS su - processus-donnes sh -c 'nom-parlant-1 | grep -v ligne-a-virer'
- de faire absolument tout ;-)
Unix fait absolument tout. Que veux tu de plus? Apprends à te servir d'unix!!
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.
Personnellement j'utilise rarement screen, car emacs fait presque tout ce que fait screen, de manière intégrée: on peut lancer plusieurs processus dans plusieurs tampons shell, on peut ouvrir des frame sur d'autres serveurs X, et maintenant avec le patch multitty, aussi sur des terminaux, etc.
Ceci dit, on peut effectivement considérer un tel outil, qui permet de centraliser les dialogues avec des programmes plutôt orientés traitement par lot. Sur unix, on a tendance à ne voir que les processus interactifs, et avec le progrès des processeurs, tout traitement par lot devient traitement interactif. Un traitement qui prend une heure (3600 secondes) aujourd'hui sur un processeur à 1GHz, ne prendra que 3.6 secondes sur un cell-processeur à 10 processeurs à 100GHz dans 10 ans, et sera alors un traitement interactif.
Je conseillerais d'utiliser un peu VM (avec l'émulateur Hercules) pour prendre quelques idées pour ce qui est du dialogue opérateur avec plusieurs traitements par lot ou tâches de fond dans un terminal.
Le mieux serait peut être d'intégrer ces fonctionnalités à la gestion des jobs du shell (bash).
In a World without Walls and Fences, who needs Windows and Gates?
Thomas Baruchel
mv a.out nom-parlant ou simplement, utiliser l'option -o de gcc gcc mon-programme.c -o nom-parlant
En fait, j'avais répondu à ta réponse avant que tu ne la donnes ; je n'avais pas été assez clair sur ce point, mais heureusement je connaissais mv, l'option -o et quelques autres trucs.
Sur top ou sur screen (sous lequel je travaille déjà exclusivement), cela va aussi.
Unix fait absolument tout. Que veux tu de plus? Apprends à te servir d'unix!! Et cela ne va pas trop mal de ce point de vue non plus, mais en fait
je décrivais plutôt une sorte de "tour de contrôle" qui me permettrait de naviguer avec les flèches entre mes sept ou huit processus, et simplement en appuyant sur une touche (voire même sans cela, pour peu qu'un panneau contienne la liste des processus, un autre la sortie standard du processus sélectionné) consulter les dix dernières lignes, etc.
Pour l'instant j'utilise déjà screen, mais j'aurais voulu quelque chose de centralisé et d'interactif. Je pensais que ma description le laissait penser.
Personnellement j'utilise rarement screen, car emacs fait presque tout ce que fait screen, de manière intégrée: on peut lancer plusieurs processus dans plusieurs tampons shell, on peut ouvrir des frame sur d'autres serveurs X, et maintenant avec le patch multitty, aussi sur des terminaux, etc. Oui, mais après dix ans de VIM, je ne vais pas me mettre à emacs,
et même si je suis conscient de tout cela, c'est un peu utiliser l'artillerie lourde pour un programme qui somme toute serait assez léger.
Le mieux serait peut être d'intégrer ces fonctionnalités à la gestion des jobs du shell (bash).
Certes, mais encore une fois, si je n'ai d'autre réponse que cela, je finirai par écrire quelque chose de plus pratique et interactif (d'autant que maintenant que tu m'as signalé 'mv' et -o pour gcc, cela va faciliter le travail de développement ;-) Il faudra juste que je reposte ici de temps en temps pour savoir comment on fait par exemple quand on veut effacer un fichier ou quand on veut ranger des fichiers d'une façon pratique, parce que là, avec (je crois, mais je ne sais pas trop comment vérifier, je compte de mémoire) 5000 fichiers dans mon HOME, je commence à ne pas trop m'y retrouver.
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)
mv a.out nom-parlant
ou simplement, utiliser l'option -o de gcc
gcc mon-programme.c -o nom-parlant
En fait, j'avais répondu à ta réponse avant que tu ne la donnes ;
je n'avais pas été assez clair sur ce point, mais heureusement
je connaissais mv, l'option -o et quelques autres trucs.
Sur top ou sur screen (sous lequel je travaille déjà exclusivement), cela
va aussi.
Unix fait absolument tout. Que veux tu de plus? Apprends à te servir d'unix!!
Et cela ne va pas trop mal de ce point de vue non plus, mais en fait
je décrivais plutôt une sorte de "tour de contrôle" qui me permettrait
de naviguer avec les flèches entre mes sept ou huit processus, et
simplement en appuyant sur une touche (voire même sans cela, pour peu
qu'un panneau contienne la liste des processus, un autre la sortie
standard du processus sélectionné) consulter les dix dernières lignes,
etc.
Pour l'instant j'utilise déjà screen, mais j'aurais voulu quelque chose
de centralisé et d'interactif. Je pensais que ma description le
laissait penser.
Personnellement j'utilise rarement screen, car emacs fait presque tout
ce que fait screen, de manière intégrée: on peut lancer plusieurs
processus dans plusieurs tampons shell, on peut ouvrir des frame sur
d'autres serveurs X, et maintenant avec le patch multitty, aussi sur
des terminaux, etc.
Oui, mais après dix ans de VIM, je ne vais pas me mettre à emacs,
et même si je suis conscient de tout cela, c'est un peu utiliser
l'artillerie lourde pour un programme qui somme toute serait assez
léger.
Le mieux serait peut être d'intégrer ces fonctionnalités à la gestion
des jobs du shell (bash).
Certes, mais encore une fois, si je n'ai d'autre réponse que cela,
je finirai par écrire quelque chose de plus pratique et interactif
(d'autant que maintenant que tu m'as signalé 'mv' et -o pour gcc,
cela va faciliter le travail de développement ;-) Il faudra juste
que je reposte ici de temps en temps pour savoir comment on fait
par exemple quand on veut effacer un fichier ou quand on veut
ranger des fichiers d'une façon pratique, parce que là, avec
(je crois, mais je ne sais pas trop comment vérifier, je compte
de mémoire) 5000 fichiers dans mon HOME, je commence à ne pas trop
m'y retrouver.
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)
mv a.out nom-parlant ou simplement, utiliser l'option -o de gcc gcc mon-programme.c -o nom-parlant
En fait, j'avais répondu à ta réponse avant que tu ne la donnes ; je n'avais pas été assez clair sur ce point, mais heureusement je connaissais mv, l'option -o et quelques autres trucs.
Sur top ou sur screen (sous lequel je travaille déjà exclusivement), cela va aussi.
Unix fait absolument tout. Que veux tu de plus? Apprends à te servir d'unix!! Et cela ne va pas trop mal de ce point de vue non plus, mais en fait
je décrivais plutôt une sorte de "tour de contrôle" qui me permettrait de naviguer avec les flèches entre mes sept ou huit processus, et simplement en appuyant sur une touche (voire même sans cela, pour peu qu'un panneau contienne la liste des processus, un autre la sortie standard du processus sélectionné) consulter les dix dernières lignes, etc.
Pour l'instant j'utilise déjà screen, mais j'aurais voulu quelque chose de centralisé et d'interactif. Je pensais que ma description le laissait penser.
Personnellement j'utilise rarement screen, car emacs fait presque tout ce que fait screen, de manière intégrée: on peut lancer plusieurs processus dans plusieurs tampons shell, on peut ouvrir des frame sur d'autres serveurs X, et maintenant avec le patch multitty, aussi sur des terminaux, etc. Oui, mais après dix ans de VIM, je ne vais pas me mettre à emacs,
et même si je suis conscient de tout cela, c'est un peu utiliser l'artillerie lourde pour un programme qui somme toute serait assez léger.
Le mieux serait peut être d'intégrer ces fonctionnalités à la gestion des jobs du shell (bash).
Certes, mais encore une fois, si je n'ai d'autre réponse que cela, je finirai par écrire quelque chose de plus pratique et interactif (d'autant que maintenant que tu m'as signalé 'mv' et -o pour gcc, cela va faciliter le travail de développement ;-) Il faudra juste que je reposte ici de temps en temps pour savoir comment on fait par exemple quand on veut effacer un fichier ou quand on veut ranger des fichiers d'une façon pratique, parce que là, avec (je crois, mais je ne sais pas trop comment vérifier, je compte de mémoire) 5000 fichiers dans mon HOME, je commence à ne pas trop m'y retrouver.
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)
Pascal Bourguignon
Thomas Baruchel writes:
Certes, mais encore une fois, si je n'ai d'autre réponse que cela, je finirai par écrire quelque chose de plus pratique et interactif (d'autant que maintenant que tu m'as signalé 'mv' et -o pour gcc, cela va faciliter le travail de développement ;-) Il faudra juste que je reposte ici de temps en temps pour savoir comment on fait par exemple quand on veut effacer un fichier ou quand on veut ranger des fichiers d'une façon pratique, parce que là, avec (je crois, mais je ne sais pas trop comment vérifier, je compte de mémoire) 5000 fichiers dans mon HOME, je commence à ne pas trop m'y retrouver.
Seulement 5000?
$ find $HOME -type f -print | wc -l 206637
Le truc, c'est d'utiliser aussi des répertoires, afin qu'à chaque niveau on n'ait qu'entre 5 et 9 sous-répertoires à visualiser.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Litter box not here. You must have moved it again. I'll poop in the sink.
Thomas Baruchel <baruchel@127.0.0.1> writes:
Certes, mais encore une fois, si je n'ai d'autre réponse que cela,
je finirai par écrire quelque chose de plus pratique et interactif
(d'autant que maintenant que tu m'as signalé 'mv' et -o pour gcc,
cela va faciliter le travail de développement ;-) Il faudra juste
que je reposte ici de temps en temps pour savoir comment on fait
par exemple quand on veut effacer un fichier ou quand on veut
ranger des fichiers d'une façon pratique, parce que là, avec
(je crois, mais je ne sais pas trop comment vérifier, je compte
de mémoire) 5000 fichiers dans mon HOME, je commence à ne pas trop
m'y retrouver.
Seulement 5000?
$ find $HOME -type f -print | wc -l
206637
Le truc, c'est d'utiliser aussi des répertoires, afin qu'à chaque
niveau on n'ait qu'entre 5 et 9 sous-répertoires à visualiser.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink.
Certes, mais encore une fois, si je n'ai d'autre réponse que cela, je finirai par écrire quelque chose de plus pratique et interactif (d'autant que maintenant que tu m'as signalé 'mv' et -o pour gcc, cela va faciliter le travail de développement ;-) Il faudra juste que je reposte ici de temps en temps pour savoir comment on fait par exemple quand on veut effacer un fichier ou quand on veut ranger des fichiers d'une façon pratique, parce que là, avec (je crois, mais je ne sais pas trop comment vérifier, je compte de mémoire) 5000 fichiers dans mon HOME, je commence à ne pas trop m'y retrouver.
Seulement 5000?
$ find $HOME -type f -print | wc -l 206637
Le truc, c'est d'utiliser aussi des répertoires, afin qu'à chaque niveau on n'ait qu'entre 5 et 9 sous-répertoires à visualiser.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Litter box not here. You must have moved it again. I'll poop in the sink.
Thomas Baruchel
$ find $HOME -type f -print | wc -l 206637
Le truc, c'est d'utiliser aussi des répertoires, afin qu'à chaque niveau on n'ait qu'entre 5 et 9 sous-répertoires à visualiser.
Ah OK. Et pour effacer un fichier ?
-- 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)
$ find $HOME -type f -print | wc -l
206637
Le truc, c'est d'utiliser aussi des répertoires, afin qu'à chaque
niveau on n'ait qu'entre 5 et 9 sous-répertoires à visualiser.
Ah OK. Et pour effacer un fichier ?
--
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 truc, c'est d'utiliser aussi des répertoires, afin qu'à chaque niveau on n'ait qu'entre 5 et 9 sous-répertoires à visualiser.
Ah OK. Et pour effacer un fichier ?
-- 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)
Thomas Baruchel
Avec "batch" dans le moteur de recherche de http://freshmeat.net/ il y a des réponses qui semblent plus ou moins correspondre à ce que tu décrit.
Premier regard rapide: peut-être abacus4 ?
Bon je vais regarder, cela a l'air au premier abord de correspondre à ce que je cherche. Je suis cependant surpris, au regard des autres réponses, que l'outil en question ne semble pas "évident". Le besoin est-il si rare ? Dans une optique de calcul scientifique intensif, il me semble pourtant que cela est bien pratique, et j'y ai souvent pensé à défaut d'avoir eu le temps de l'écrire.
On trouve bien ça et là de fonctionalités proches. Par exemple, des fonctions de 'monitoring', etc. Mais je m'imaginais qu'un outil complet, intégrant tout cela, de façon interactive, etc. avait dû être pensé avant moi. Je pense réellement que je vais m'y mettre car j'ai en fait une idée très nette de tout ce que je voudrais.
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)
Avec "batch" dans le moteur de recherche de http://freshmeat.net/
il y a des réponses qui semblent plus ou moins correspondre à
ce que tu décrit.
Premier regard rapide: peut-être abacus4 ?
Bon je vais regarder, cela a l'air au premier abord de correspondre
à ce que je cherche. Je suis cependant surpris, au regard des autres
réponses, que l'outil en question ne semble pas "évident". Le besoin
est-il si rare ? Dans une optique de calcul scientifique intensif,
il me semble pourtant que cela est bien pratique, et j'y ai souvent
pensé à défaut d'avoir eu le temps de l'écrire.
On trouve bien ça et là de fonctionalités proches. Par exemple, des
fonctions de 'monitoring', etc. Mais je m'imaginais qu'un outil complet,
intégrant tout cela, de façon interactive, etc. avait dû être pensé
avant moi. Je pense réellement que je vais m'y mettre car j'ai en fait
une idée très nette de tout ce que je voudrais.
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)
Avec "batch" dans le moteur de recherche de http://freshmeat.net/ il y a des réponses qui semblent plus ou moins correspondre à ce que tu décrit.
Premier regard rapide: peut-être abacus4 ?
Bon je vais regarder, cela a l'air au premier abord de correspondre à ce que je cherche. Je suis cependant surpris, au regard des autres réponses, que l'outil en question ne semble pas "évident". Le besoin est-il si rare ? Dans une optique de calcul scientifique intensif, il me semble pourtant que cela est bien pratique, et j'y ai souvent pensé à défaut d'avoir eu le temps de l'écrire.
On trouve bien ça et là de fonctionalités proches. Par exemple, des fonctions de 'monitoring', etc. Mais je m'imaginais qu'un outil complet, intégrant tout cela, de façon interactive, etc. avait dû être pensé avant moi. Je pense réellement que je vais m'y mettre car j'ai en fait une idée très nette de tout ce que je voudrais.
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)
Eric Levenez
Le 23/10/05 1:22, dans <435ac9a1$0$32753$, « Thomas Baruchel » a écrit :
$ find $HOME -type f -print | wc -l 206637
Le truc, c'est d'utiliser aussi des répertoires, afin qu'à chaque niveau on n'ait qu'entre 5 et 9 sous-répertoires à visualiser.
Ah OK. Et pour effacer un fichier ?
?? Et bien tu choisis le fichier et tu l'effaces.
Là je ne vois pas du tout ton problème. Si tu organises ton disque proprement, tu retrouves tout sans outil de recherche.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 23/10/05 1:22, dans <435ac9a1$0$32753$626a14ce@news.free.fr>, « Thomas
Baruchel » <baruchel@127.0.0.1> a écrit :
$ find $HOME -type f -print | wc -l
206637
Le truc, c'est d'utiliser aussi des répertoires, afin qu'à chaque
niveau on n'ait qu'entre 5 et 9 sous-répertoires à visualiser.
Ah OK. Et pour effacer un fichier ?
?? Et bien tu choisis le fichier et tu l'effaces.
Là je ne vois pas du tout ton problème. Si tu organises ton disque
proprement, tu retrouves tout sans outil de recherche.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 23/10/05 1:22, dans <435ac9a1$0$32753$, « Thomas Baruchel » a écrit :
$ find $HOME -type f -print | wc -l 206637
Le truc, c'est d'utiliser aussi des répertoires, afin qu'à chaque niveau on n'ait qu'entre 5 et 9 sous-répertoires à visualiser.
Ah OK. Et pour effacer un fichier ?
?? Et bien tu choisis le fichier et tu l'effaces.
Là je ne vois pas du tout ton problème. Si tu organises ton disque proprement, tu retrouves tout sans outil de recherche.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Thomas Baruchel
Premier regard rapide: peut-être abacus4 ?
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 ?
-- 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)
Premier regard rapide: peut-être abacus4 ?
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 ?
--
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)
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 ?
-- 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)
