ouvrir un script dans une console en double cliquant sur un fichier
15 réponses
Keul
Bonjour
Pourriez-vous me dire comment faire pour que quand on doube clique sur
un fichier (.sh ou .py), celui-ci ouvre une fen=EAtre de terminal dans
laquelle il s'execute. (et uniquement por ce fichier et pas tous
les .sh du syst=E8me.
Je suis sous feroda core 4
Pourriez-vous me dire comment faire pour que quand on doube clique sur un fichier (.sh ou .py), celui-ci ouvre une fenêtre de terminal dans laquelle il s'execute. (et uniquement por ce fichier et pas tous les .sh du système. Je suis sous feroda core 4
merci d'avance.
La plupart des gestionnaires de fenetres te permettent cela en créant un raccourci du script et en cochant la case qui va bien dans les parametres du raccourci.
Bonjour
Pourriez-vous me dire comment faire pour que quand on doube clique sur
un fichier (.sh ou .py), celui-ci ouvre une fenêtre de terminal dans
laquelle il s'execute. (et uniquement por ce fichier et pas tous
les .sh du système.
Je suis sous feroda core 4
merci d'avance.
La plupart des gestionnaires de fenetres te permettent cela en créant un
raccourci du script et en cochant la case qui va bien dans les
parametres du raccourci.
Pourriez-vous me dire comment faire pour que quand on doube clique sur un fichier (.sh ou .py), celui-ci ouvre une fenêtre de terminal dans laquelle il s'execute. (et uniquement por ce fichier et pas tous les .sh du système. Je suis sous feroda core 4
merci d'avance.
La plupart des gestionnaires de fenetres te permettent cela en créant un raccourci du script et en cochant la case qui va bien dans les parametres du raccourci.
octane
On 4 juil, 15:08, Keul wrote:
Pourriez-vous me dire comment faire pour que quand on doube clique sur un fichier (.sh ou .py), celui-ci ouvre une fenêtre de terminal dans laquelle il s'execute. (et uniquement por ce fichier et pas tous les .sh du système. Je suis sous feroda core 4
Pour qu'un fichier lance terminal et le script, tu dois pouvoir t'en
sortir en utilsant:
#! /bin/bash xterm -e /chemin/vers/le/fichier.sh
que tu rends executable avec un chmod +x, et ca doit faire le truc.
On 4 juil, 15:08, Keul <keul...@gmail.com> wrote:
Pourriez-vous me dire comment faire pour que quand on doube clique sur
un fichier (.sh ou .py), celui-ci ouvre une fenêtre de terminal dans
laquelle il s'execute. (et uniquement por ce fichier et pas tous
les .sh du système.
Je suis sous feroda core 4
Pour qu'un fichier lance terminal et le script, tu dois pouvoir t'en
sortir
en utilsant:
#! /bin/bash
xterm -e /chemin/vers/le/fichier.sh
que tu rends executable avec un chmod +x, et ca doit faire le truc.
Pourriez-vous me dire comment faire pour que quand on doube clique sur un fichier (.sh ou .py), celui-ci ouvre une fenêtre de terminal dans laquelle il s'execute. (et uniquement por ce fichier et pas tous les .sh du système. Je suis sous feroda core 4
Pour qu'un fichier lance terminal et le script, tu dois pouvoir t'en
sortir en utilsant:
#! /bin/bash xterm -e /chemin/vers/le/fichier.sh
que tu rends executable avec un chmod +x, et ca doit faire le truc.
Keul
On 4 juil, 15:35, wrote:
On 4 juil, 15:08, Keul wrote:> Pourriez-vous me dire comment faire pour que quand on doube clique sur
un fichier (.sh ou .py), celui-ci ouvre une fenêtre de terminal dans laquelle il s'execute. (et uniquement por ce fichier et pas tous les .sh du système. Je suis sous feroda core 4
Pour qu'un fichier lance terminal et le script, tu dois pouvoir t'en sortir en utilsant:
#! /bin/bash xterm -e /chemin/vers/le/fichier.sh
que tu rends executable avec un chmod +x, et ca doit faire le truc.
On 4 juil, 15:08, Keul <keul...@gmail.com> wrote:> Pourriez-vous me dire comment faire pour que quand on doube clique sur
un fichier (.sh ou .py), celui-ci ouvre une fenêtre de terminal dans
laquelle il s'execute. (et uniquement por ce fichier et pas tous
les .sh du système.
Je suis sous feroda core 4
Pour qu'un fichier lance terminal et le script, tu dois pouvoir t'en
sortir
en utilsant:
#! /bin/bash
xterm -e /chemin/vers/le/fichier.sh
que tu rends executable avec un chmod +x, et ca doit faire le truc.
On 4 juil, 15:08, Keul wrote:> Pourriez-vous me dire comment faire pour que quand on doube clique sur
un fichier (.sh ou .py), celui-ci ouvre une fenêtre de terminal dans laquelle il s'execute. (et uniquement por ce fichier et pas tous les .sh du système. Je suis sous feroda core 4
Pour qu'un fichier lance terminal et le script, tu dois pouvoir t'en sortir en utilsant:
#! /bin/bash xterm -e /chemin/vers/le/fichier.sh
que tu rends executable avec un chmod +x, et ca doit faire le truc.
-- SuZE/Linux: première distribution sur bistrotwatch.com
Quand tu bosse sur un poste pas connecté au net, dans une boite de 3 employés, sur un système qui utilise le réseau pour tester des produits avec ethtool et ifconfig sans être conencté au net, t'a autre chose faire que passer 3 heures à savoir comment les faire tourner dans une session normal... Le vrai danger, c'est plutôt quand je vois les distributeurs banquaires qui tournent sous windows. (et qu'on vois même des message d'erreur dessus)
On 4 juil, 19:41, "Thierry B." <t...@prout.stex> wrote:
--
SuZE/Linux: première distribution sur bistrotwatch.com
Quand tu bosse sur un poste pas connecté au net, dans une boite de 3
employés, sur un système qui utilise le réseau pour tester des
produits avec ethtool et ifconfig sans être conencté au net, t'a autre
chose faire que passer 3 heures à savoir comment les faire tourner
dans une session normal...
Le vrai danger, c'est plutôt quand je vois les distributeurs
banquaires qui tournent sous windows. (et qu'on vois même des message
d'erreur dessus)
-- SuZE/Linux: première distribution sur bistrotwatch.com
Quand tu bosse sur un poste pas connecté au net, dans une boite de 3 employés, sur un système qui utilise le réseau pour tester des produits avec ethtool et ifconfig sans être conencté au net, t'a autre chose faire que passer 3 heures à savoir comment les faire tourner dans une session normal... Le vrai danger, c'est plutôt quand je vois les distributeurs banquaires qui tournent sous windows. (et qu'on vois même des message d'erreur dessus)
Christophe PEREZ
Le Thu, 05 Jul 2007 07:33:56 +0000, Keul a écrit:
Quand tu bosse sur un poste pas connecté au net, dans une boite de 3 employés, sur un système qui utilise le réseau pour tester des produits avec ethtool et ifconfig sans être conencté au net, t'a autre chose faire que passer 3 heures à savoir comment les faire tourner dans une session normal...
Ça dépend. Un rm -rf * en étant dans / et en se croyant dans son $HOME fera des dégâts, même sur un poste complètement isolé ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Thu, 05 Jul 2007 07:33:56 +0000, Keul a écrit:
Quand tu bosse sur un poste pas connecté au net, dans une boite de 3
employés, sur un système qui utilise le réseau pour tester des
produits avec ethtool et ifconfig sans être conencté au net, t'a autre
chose faire que passer 3 heures à savoir comment les faire tourner
dans une session normal...
Ça dépend. Un rm -rf * en étant dans / et en se croyant dans son $HOME
fera des dégâts, même sur un poste complètement isolé ;-)
Quand tu bosse sur un poste pas connecté au net, dans une boite de 3 employés, sur un système qui utilise le réseau pour tester des produits avec ethtool et ifconfig sans être conencté au net, t'a autre chose faire que passer 3 heures à savoir comment les faire tourner dans une session normal...
Ça dépend. Un rm -rf * en étant dans / et en se croyant dans son $HOME fera des dégâts, même sur un poste complètement isolé ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Serge Lavayssière
Le Thu, 05 Jul 2007 16:26:23 -0400, Christophe PEREZ a écrit :
Le Thu, 05 Jul 2007 07:33:56 +0000, Keul a écrit:
Quand tu bosse sur un poste pas connecté au net, dans une boite de 3 employés, sur un système qui utilise le réseau pour tester des produits avec ethtool et ifconfig sans être conencté au net, t'a autre chose faire que passer 3 heures à savoir comment les faire tourner dans une session normal...
Ça dépend. Un rm -rf * en étant dans / et en se croyant dans son $HOME fera des dégâts, même sur un poste complètement isolé ;-)
Oui, mais ça, ce n'est pas sous X ! Le problème encore une fois n'est pas dans X, mais potentiellement entre la chaise et le clavier.
Le Thu, 05 Jul 2007 16:26:23 -0400, Christophe PEREZ a écrit :
Le Thu, 05 Jul 2007 07:33:56 +0000, Keul a écrit:
Quand tu bosse sur un poste pas connecté au net, dans une boite de 3
employés, sur un système qui utilise le réseau pour tester des
produits avec ethtool et ifconfig sans être conencté au net, t'a autre
chose faire que passer 3 heures à savoir comment les faire tourner
dans une session normal...
Ça dépend. Un rm -rf * en étant dans / et en se croyant dans son $HOME
fera des dégâts, même sur un poste complètement isolé ;-)
Oui, mais ça, ce n'est pas sous X !
Le problème encore une fois n'est pas dans X, mais potentiellement entre
la chaise et le clavier.
Le Thu, 05 Jul 2007 16:26:23 -0400, Christophe PEREZ a écrit :
Le Thu, 05 Jul 2007 07:33:56 +0000, Keul a écrit:
Quand tu bosse sur un poste pas connecté au net, dans une boite de 3 employés, sur un système qui utilise le réseau pour tester des produits avec ethtool et ifconfig sans être conencté au net, t'a autre chose faire que passer 3 heures à savoir comment les faire tourner dans une session normal...
Ça dépend. Un rm -rf * en étant dans / et en se croyant dans son $HOME fera des dégâts, même sur un poste complètement isolé ;-)
Oui, mais ça, ce n'est pas sous X ! Le problème encore une fois n'est pas dans X, mais potentiellement entre la chaise et le clavier.
Le Fri, 06 Jul 2007 13:32:06 +0200, Serge Lavayssière a écrit:
Ça dépend. Un rm -rf * en étant dans / et en se croyant dans son $HOME fera des dégâts, même sur un poste complètement isolé ;-)
Oui, mais ça, ce n'est pas sous X !
Ah bon ? À quoi le voyez-vous ?
Le problème encore une fois n'est pas dans X,
Ai-je dit qu'il l'était ?
mais potentiellement entre la chaise et le clavier.
Oui, mais ça, c'est d'une évidence... comme une très grande majorité des problèmes. Cela doit-il pour autant empêcher de s'en prémunir ?
-- Christophe PEREZ Écrivez moi sans _faute !
Serge Lavayssière
Le Fri, 06 Jul 2007 13:08:40 -0400, Christophe PEREZ a écrit :
Le Fri, 06 Jul 2007 13:32:06 +0200, Serge Lavayssière a écrit:
Ça dépend. Un rm -rf * en étant dans / et en se croyant dans son $HOME fera des dégâts, même sur un poste complètement isolé ;-)
Oui, mais ça, ce n'est pas sous X !
Ah bon ? À quoi le voyez-vous ?
A priori, ligne de commande est le propre d'une absence (ou d'une non utilisation) d'interface graphique (même si l'un n'empêche pas l'autre)
En graphique, la fenêtre ouverte montre bien si on est dans / ou dans son $HOME, alors qu'en ligne de commande, on peut effectivement se tromper.
Préférant le plus souvent l'interface graphique à la ligne de commande (même si j'ouvre de temps en temps le console, en "su", horreur !) j'aurais envie de reprendre l'argument à mon compte :
Danger sans interface graphique,
Un rm -rf * en étant dans / et en se croyant dans son $HOME fera des dégâts, même sur un poste complètement isolé alors qu'avec une fenêtre on voit clairement où on est.
Le Fri, 06 Jul 2007 13:08:40 -0400, Christophe PEREZ a écrit :
Le Fri, 06 Jul 2007 13:32:06 +0200, Serge Lavayssière a écrit:
Ça dépend. Un rm -rf * en étant dans / et en se croyant dans son
$HOME fera des dégâts, même sur un poste complètement isolé ;-)
Oui, mais ça, ce n'est pas sous X !
Ah bon ? À quoi le voyez-vous ?
A priori, ligne de commande est le propre d'une absence (ou
d'une non utilisation) d'interface graphique (même si l'un n'empêche pas
l'autre)
En graphique, la fenêtre ouverte montre bien si on est dans / ou dans son
$HOME, alors qu'en ligne de commande, on peut effectivement se tromper.
Préférant le plus souvent l'interface graphique à la ligne de commande
(même si j'ouvre de temps en temps le console, en "su", horreur !)
j'aurais envie de reprendre l'argument à mon compte :
Danger sans interface graphique,
Un rm -rf * en étant dans / et en se croyant dans son
$HOME fera des dégâts, même sur un poste complètement isolé
alors qu'avec une fenêtre on voit clairement où on est.
Le Fri, 06 Jul 2007 13:08:40 -0400, Christophe PEREZ a écrit :
Le Fri, 06 Jul 2007 13:32:06 +0200, Serge Lavayssière a écrit:
Ça dépend. Un rm -rf * en étant dans / et en se croyant dans son $HOME fera des dégâts, même sur un poste complètement isolé ;-)
Oui, mais ça, ce n'est pas sous X !
Ah bon ? À quoi le voyez-vous ?
A priori, ligne de commande est le propre d'une absence (ou d'une non utilisation) d'interface graphique (même si l'un n'empêche pas l'autre)
En graphique, la fenêtre ouverte montre bien si on est dans / ou dans son $HOME, alors qu'en ligne de commande, on peut effectivement se tromper.
Préférant le plus souvent l'interface graphique à la ligne de commande (même si j'ouvre de temps en temps le console, en "su", horreur !) j'aurais envie de reprendre l'argument à mon compte :
Danger sans interface graphique,
Un rm -rf * en étant dans / et en se croyant dans son $HOME fera des dégâts, même sur un poste complètement isolé alors qu'avec une fenêtre on voit clairement où on est.
