j'ai des commandes terminal que j'utilise lors de chaque démarrage (par
exemple pour lancer un proxxy OGR sur un serveur).
pour l'instant, la méthode la plus rapide est d'ouvrir un fichier
textedit dans lequel j'ai ces commandes, et de faire un copié collé.
j'avais lu un truc permettant de faire mieux, mais comment automatiser
la chose ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Engel
j'ai des commandes terminal que j'utilise lors de chaque démarrage (par exemple pour lancer un proxxy OGR sur un serveur).
pour l'instant, la méthode la plus rapide est d'ouvrir un fichier textedit dans lequel j'ai ces commandes, et de faire un copié collé. j'avais lu un truc permettant de faire mieux, mais comment automatiser la chose ?
Sous OS X, tu as toute la panoplie des outils Unix en plus des outils Apple, pour ce faire.
Côté Apple, tu as les "éléments de démarrage", dans lesquels tu peux facilement introduire un script, que ce soit un AppleScript ou un script bash (c-a-d ligne de commande)
Côté Unix, tu as la crontab, qui est une table reliant des commandes et des indications de temps, qui te permet de programmer l'éxécution régulière de ces commandes. Par exemple, au démarrage, toutes les cinq minutes, tous les premier jour du mois, etc. Il y a une crontab générique pour le système, et une crontab par utilisateur, dans laquelle tu peux mettre l'appel de ton script (il sera effectivement plus pratique pour toi de faire un script regroupant toutes tes commandes, et ensuite de mettre un appel à ce script dans la crontab, plutôt que de mettre directement tous les appels aux commandes dans la crontab).
En gros, en cherchant la documentation Bash et la documentation crontab, tu devrais pouvoir trouver ton bonheur. Fais juste bien attention à prendre la documentation pour la crontab de Mac OS X, parce qu'il y a certaines subtilités par rapport aux crontabs des autres unix. Pour ce qui est de Bash, tout est standard sur le mac, à part les noms des prériphériques et des points de montage de ceux-ci, donc les docs *BSD et Linux sont tout-à-fait applicables.
j'ai des commandes terminal que j'utilise lors de chaque démarrage (par
exemple pour lancer un proxxy OGR sur un serveur).
pour l'instant, la méthode la plus rapide est d'ouvrir un fichier
textedit dans lequel j'ai ces commandes, et de faire un copié collé.
j'avais lu un truc permettant de faire mieux, mais comment automatiser
la chose ?
Sous OS X, tu as toute la panoplie des outils Unix en plus des outils
Apple, pour ce faire.
Côté Apple, tu as les "éléments de démarrage", dans lesquels tu peux
facilement introduire un script, que ce soit un AppleScript ou un script
bash (c-a-d ligne de commande)
Côté Unix, tu as la crontab, qui est une table reliant des commandes et
des indications de temps, qui te permet de programmer l'éxécution
régulière de ces commandes. Par exemple, au démarrage, toutes les cinq
minutes, tous les premier jour du mois, etc. Il y a une crontab
générique pour le système, et une crontab par utilisateur, dans laquelle
tu peux mettre l'appel de ton script (il sera effectivement plus
pratique pour toi de faire un script regroupant toutes tes commandes, et
ensuite de mettre un appel à ce script dans la crontab, plutôt que de
mettre directement tous les appels aux commandes dans la crontab).
En gros, en cherchant la documentation Bash et la documentation crontab,
tu devrais pouvoir trouver ton bonheur. Fais juste bien attention à
prendre la documentation pour la crontab de Mac OS X, parce qu'il y a
certaines subtilités par rapport aux crontabs des autres unix. Pour ce
qui est de Bash, tout est standard sur le mac, à part les noms des
prériphériques et des points de montage de ceux-ci, donc les docs *BSD
et Linux sont tout-à-fait applicables.
j'ai des commandes terminal que j'utilise lors de chaque démarrage (par exemple pour lancer un proxxy OGR sur un serveur).
pour l'instant, la méthode la plus rapide est d'ouvrir un fichier textedit dans lequel j'ai ces commandes, et de faire un copié collé. j'avais lu un truc permettant de faire mieux, mais comment automatiser la chose ?
Sous OS X, tu as toute la panoplie des outils Unix en plus des outils Apple, pour ce faire.
Côté Apple, tu as les "éléments de démarrage", dans lesquels tu peux facilement introduire un script, que ce soit un AppleScript ou un script bash (c-a-d ligne de commande)
Côté Unix, tu as la crontab, qui est une table reliant des commandes et des indications de temps, qui te permet de programmer l'éxécution régulière de ces commandes. Par exemple, au démarrage, toutes les cinq minutes, tous les premier jour du mois, etc. Il y a une crontab générique pour le système, et une crontab par utilisateur, dans laquelle tu peux mettre l'appel de ton script (il sera effectivement plus pratique pour toi de faire un script regroupant toutes tes commandes, et ensuite de mettre un appel à ce script dans la crontab, plutôt que de mettre directement tous les appels aux commandes dans la crontab).
En gros, en cherchant la documentation Bash et la documentation crontab, tu devrais pouvoir trouver ton bonheur. Fais juste bien attention à prendre la documentation pour la crontab de Mac OS X, parce qu'il y a certaines subtilités par rapport aux crontabs des autres unix. Pour ce qui est de Bash, tout est standard sur le mac, à part les noms des prériphériques et des points de montage de ceux-ci, donc les docs *BSD et Linux sont tout-à-fait applicables.
fra
manet wrote:
j'ai des commandes terminal que j'utilise lors de chaque démarrage (par exemple pour lancer un proxxy OGR sur un serveur).
pour l'instant, la méthode la plus rapide est d'ouvrir un fichier textedit dans lequel j'ai ces commandes, et de faire un copié collé. j'avais lu un truc permettant de faire mieux, mais comment automatiser la chose ?
Si tu renommes ton fichier texedit en mettant .command à la fin et en le mettant dans les éléments d'ouverture ça marche ou pas ? -- Fra
manet <pmanet@invivo.edu> wrote:
j'ai des commandes terminal que j'utilise lors de chaque démarrage (par
exemple pour lancer un proxxy OGR sur un serveur).
pour l'instant, la méthode la plus rapide est d'ouvrir un fichier
textedit dans lequel j'ai ces commandes, et de faire un copié collé.
j'avais lu un truc permettant de faire mieux, mais comment automatiser
la chose ?
Si tu renommes ton fichier texedit en mettant .command à la fin et en le
mettant dans les éléments d'ouverture ça marche ou pas ?
--
Fra
j'ai des commandes terminal que j'utilise lors de chaque démarrage (par exemple pour lancer un proxxy OGR sur un serveur).
pour l'instant, la méthode la plus rapide est d'ouvrir un fichier textedit dans lequel j'ai ces commandes, et de faire un copié collé. j'avais lu un truc permettant de faire mieux, mais comment automatiser la chose ?
Si tu renommes ton fichier texedit en mettant .command à la fin et en le mettant dans les éléments d'ouverture ça marche ou pas ? -- Fra
Nicolas.MICHEL
manet wrote:
j'ai des commandes terminal que j'utilise lors de chaque démarrage (par exemple pour lancer un proxxy OGR sur un serveur).
pour l'instant, la méthode la plus rapide est d'ouvrir un fichier textedit dans lequel j'ai ces commandes, et de faire un copié collé. j'avais lu un truc permettant de faire mieux, mais comment automatiser la chose ?
1) Fais un script shell.
Pour ça, c'est pas compliqué, tu met tes commandes dans un fichier text, les unes à la suite des autres, une commande par ligne. Pour bien faire, tu peux commencer ton fichier par #!/bin/sh
Attention toutes fois, le fichier text doit être du text unix, c'est à dire que textedit et son format rtf ne convient pas.
Pour pas te planter, fais comme ceci : - ouvre ton fichier de commandes dans textedit et copie le tout puis dans le terminal : -vi ~/Library/loginscript.command #t'ouvre dans vi un fichier nomé # loginscript.command et qui se # trouve dans ton dossier # Bibliothèque -appuie sur la touche "i" pour entrer en mode saisie -[pomme v] pour coller tes commandes -[esc] :wq # touche "exc", touche [deux points], touche "w" puis "q" # pour respectivement sortir du mode saisie, enregistrer # puis quitter.
2) Rends ton script exécutable Pour ça, tu écris sudo chmod +x ~/Library/loginscript.command
L'extention .command dans le nom fait que ce script est double-clicable
3) Tu fais que ce script s'exécute au démarage. Là, les possibilités sont nombreuses. Essaie déjà de le mettre dans les startup items de l'utilisateur. Sinon, il y a le freeware "loginwindow manager" qui te permet de définir un script de login. Tu peux aussi créer un "service" dans /Library/StartupItems. Enfin tu peux mettre ce script dans /etc/rc si tu veux qu'il s'exécute avant que le reseau ne soit debout, ou avant que les disques ne soient montés, mais là c'est un peu extrème.
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
manet <pmanet@invivo.edu> wrote:
j'ai des commandes terminal que j'utilise lors de chaque démarrage (par
exemple pour lancer un proxxy OGR sur un serveur).
pour l'instant, la méthode la plus rapide est d'ouvrir un fichier
textedit dans lequel j'ai ces commandes, et de faire un copié collé.
j'avais lu un truc permettant de faire mieux, mais comment automatiser
la chose ?
1) Fais un script shell.
Pour ça, c'est pas compliqué, tu met tes commandes dans un fichier text,
les unes à la suite des autres, une commande par ligne.
Pour bien faire, tu peux commencer ton fichier par
#!/bin/sh
Attention toutes fois, le fichier text doit être du text unix, c'est à
dire que textedit et son format rtf ne convient pas.
Pour pas te planter, fais comme ceci :
- ouvre ton fichier de commandes dans textedit et copie le tout
puis dans le terminal :
-vi ~/Library/loginscript.command #t'ouvre dans vi un fichier nomé
# loginscript.command et qui se
# trouve dans ton dossier
# Bibliothèque
-appuie sur la touche "i" pour entrer en mode saisie
-[pomme v] pour coller tes commandes
-[esc] :wq # touche "exc", touche [deux points], touche "w" puis "q"
# pour respectivement sortir du mode saisie, enregistrer
# puis quitter.
2) Rends ton script exécutable
Pour ça, tu écris
sudo chmod +x ~/Library/loginscript.command
L'extention .command dans le nom fait que ce script est double-clicable
3) Tu fais que ce script s'exécute au démarage.
Là, les possibilités sont nombreuses. Essaie déjà de le mettre dans les
startup items de l'utilisateur.
Sinon, il y a le freeware "loginwindow manager" qui te permet de définir
un script de login.
Tu peux aussi créer un "service" dans /Library/StartupItems.
Enfin tu peux mettre ce script dans /etc/rc si tu veux qu'il s'exécute
avant que le reseau ne soit debout, ou avant que les disques ne soient
montés, mais là c'est un peu extrème.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
j'ai des commandes terminal que j'utilise lors de chaque démarrage (par exemple pour lancer un proxxy OGR sur un serveur).
pour l'instant, la méthode la plus rapide est d'ouvrir un fichier textedit dans lequel j'ai ces commandes, et de faire un copié collé. j'avais lu un truc permettant de faire mieux, mais comment automatiser la chose ?
1) Fais un script shell.
Pour ça, c'est pas compliqué, tu met tes commandes dans un fichier text, les unes à la suite des autres, une commande par ligne. Pour bien faire, tu peux commencer ton fichier par #!/bin/sh
Attention toutes fois, le fichier text doit être du text unix, c'est à dire que textedit et son format rtf ne convient pas.
Pour pas te planter, fais comme ceci : - ouvre ton fichier de commandes dans textedit et copie le tout puis dans le terminal : -vi ~/Library/loginscript.command #t'ouvre dans vi un fichier nomé # loginscript.command et qui se # trouve dans ton dossier # Bibliothèque -appuie sur la touche "i" pour entrer en mode saisie -[pomme v] pour coller tes commandes -[esc] :wq # touche "exc", touche [deux points], touche "w" puis "q" # pour respectivement sortir du mode saisie, enregistrer # puis quitter.
2) Rends ton script exécutable Pour ça, tu écris sudo chmod +x ~/Library/loginscript.command
L'extention .command dans le nom fait que ce script est double-clicable
3) Tu fais que ce script s'exécute au démarage. Là, les possibilités sont nombreuses. Essaie déjà de le mettre dans les startup items de l'utilisateur. Sinon, il y a le freeware "loginwindow manager" qui te permet de définir un script de login. Tu peux aussi créer un "service" dans /Library/StartupItems. Enfin tu peux mettre ce script dans /etc/rc si tu veux qu'il s'exécute avant que le reseau ne soit debout, ou avant que les disques ne soient montés, mais là c'est un peu extrème.
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
pmanet
Nicolas MICHEL wrote:
là c'est un peu extrème.
merci à tous, en 3 réponses j'ai appris énormément de choses j'essayerais vendredi, mais comme c'est un serveur que je redemarre rarement, je ne devrais pas avoir rapidement l'occasion de vérifier que ça fonctionne bien... je vais faire des essais anodins sur une autre machine en attendant, mais elle est sous panther et lui sous jaguar.
Dernier point : l'une des applis est proxyper, le proxy de distribution de calculs de dnetc (OGR et RC5).
Pour lancer ce truc, il faut : 1) se placer dans le repertoire du machin : cd xxx/proxu 2) lancer le bouzin : ./proxyper
et il tourne dans la fenetre du terminal
Q1 : si j'ai bien compris la doc, ils disent qu'il n'y a pas d'option permettant de le mettre en détaché ; il est donc indispensable de garder la fenetre du terminal ouverte ?
Q2 : je crois comprendre que mettre d'abord le terminal dans le repertoire de l'appli permet à celle-ci de trouver facilement ses fichiers ; n'y a-t-il pas moyen de mettre la localisation et le lancement de l'appli danas la meme ligne avec un pipe ? j'ai essayé, ça ne fonctionne pas : pas de repertoire ayant ce nom
-- Philippe Manet
Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:
là c'est un peu extrème.
merci à tous, en 3 réponses j'ai appris énormément de choses
j'essayerais vendredi, mais comme c'est un serveur que je redemarre
rarement, je ne devrais pas avoir rapidement l'occasion de vérifier que
ça fonctionne bien... je vais faire des essais anodins sur une autre
machine en attendant, mais elle est sous panther et lui sous jaguar.
Dernier point :
l'une des applis est proxyper, le proxy de distribution de calculs de
dnetc (OGR et RC5).
Pour lancer ce truc, il faut :
1) se placer dans le repertoire du machin : cd xxx/proxu
2) lancer le bouzin : ./proxyper
et il tourne dans la fenetre du terminal
Q1 :
si j'ai bien compris la doc, ils disent qu'il n'y a pas d'option
permettant de le mettre en détaché ; il est donc indispensable de garder
la fenetre du terminal ouverte ?
Q2 :
je crois comprendre que mettre d'abord le terminal dans le repertoire de
l'appli permet à celle-ci de trouver facilement ses fichiers ; n'y
a-t-il pas moyen de mettre la localisation et le lancement de l'appli
danas la meme ligne avec un pipe ? j'ai essayé, ça ne fonctionne pas :
pas de repertoire ayant ce nom
merci à tous, en 3 réponses j'ai appris énormément de choses j'essayerais vendredi, mais comme c'est un serveur que je redemarre rarement, je ne devrais pas avoir rapidement l'occasion de vérifier que ça fonctionne bien... je vais faire des essais anodins sur une autre machine en attendant, mais elle est sous panther et lui sous jaguar.
Dernier point : l'une des applis est proxyper, le proxy de distribution de calculs de dnetc (OGR et RC5).
Pour lancer ce truc, il faut : 1) se placer dans le repertoire du machin : cd xxx/proxu 2) lancer le bouzin : ./proxyper
et il tourne dans la fenetre du terminal
Q1 : si j'ai bien compris la doc, ils disent qu'il n'y a pas d'option permettant de le mettre en détaché ; il est donc indispensable de garder la fenetre du terminal ouverte ?
Q2 : je crois comprendre que mettre d'abord le terminal dans le repertoire de l'appli permet à celle-ci de trouver facilement ses fichiers ; n'y a-t-il pas moyen de mettre la localisation et le lancement de l'appli danas la meme ligne avec un pipe ? j'ai essayé, ça ne fonctionne pas : pas de repertoire ayant ce nom
-- Philippe Manet
patpro
In article <2004012120094430476765@[10.0.0.1]>, (manet) wrote:
Q1 : si j'ai bien compris la doc, ils disent qu'il n'y a pas d'option permettant de le mettre en détaché ; il est donc indispensable de garder la fenetre du terminal ouverte ?
etonnant...
Q2 : je crois comprendre que mettre d'abord le terminal dans le repertoire de l'appli permet à celle-ci de trouver facilement ses fichiers ; n'y a-t-il pas moyen de mettre la localisation et le lancement de l'appli danas la meme ligne avec un pipe ? j'ai essayé, ça ne fonctionne pas : pas de repertoire ayant ce nom
pour enchainer plusieurs commandes sur une ligne il faut les séparer par des ;
ex : $ cd toto/tata ; ls ; echo "fini"
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
In article <2004012120094430476765@[10.0.0.1]>,
pmanet@invivo.edu (manet) wrote:
Q1 :
si j'ai bien compris la doc, ils disent qu'il n'y a pas d'option
permettant de le mettre en détaché ; il est donc indispensable de garder
la fenetre du terminal ouverte ?
etonnant...
Q2 :
je crois comprendre que mettre d'abord le terminal dans le repertoire de
l'appli permet à celle-ci de trouver facilement ses fichiers ; n'y
a-t-il pas moyen de mettre la localisation et le lancement de l'appli
danas la meme ligne avec un pipe ? j'ai essayé, ça ne fonctionne pas :
pas de repertoire ayant ce nom
pour enchainer plusieurs commandes sur une ligne il faut les séparer par
des ;
ex :
$ cd toto/tata ; ls ; echo "fini"
patpro
--
je cherche un poste d'admin UNIX/Mac
http://patpro.net/cv.php
In article <2004012120094430476765@[10.0.0.1]>, (manet) wrote:
Q1 : si j'ai bien compris la doc, ils disent qu'il n'y a pas d'option permettant de le mettre en détaché ; il est donc indispensable de garder la fenetre du terminal ouverte ?
etonnant...
Q2 : je crois comprendre que mettre d'abord le terminal dans le repertoire de l'appli permet à celle-ci de trouver facilement ses fichiers ; n'y a-t-il pas moyen de mettre la localisation et le lancement de l'appli danas la meme ligne avec un pipe ? j'ai essayé, ça ne fonctionne pas : pas de repertoire ayant ce nom
pour enchainer plusieurs commandes sur une ligne il faut les séparer par des ;
ex : $ cd toto/tata ; ls ; echo "fini"
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
fra
patpro wrote:
pour enchainer plusieurs commandes sur une ligne il faut les séparer par des ;
Ca doit en plus éviter les éventuels emmerdes des sauts de lignes non unix non ? -- Fra
patpro <patpro@boleskine.patpro.net> wrote:
pour enchainer plusieurs commandes sur une ligne il faut les séparer par
des ;
Ca doit en plus éviter les éventuels emmerdes des sauts de lignes non
unix non ?
--
Fra
pour enchainer plusieurs commandes sur une ligne il faut les séparer par des ;
Ca doit en plus éviter les éventuels emmerdes des sauts de lignes non unix non ?
non, parce que si c'est pour faire un script shell il te faudra deux lignes (#!/bin/sh sur la premiere ligne, et tes commandes sur la/les suivante/s)
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
EcceAngelo
manet wrote:
Nicolas MICHEL wrote:
là c'est un peu extrème.
merci à tous, en 3 réponses j'ai appris énormément de choses j'essayerais vendredi, mais comme c'est un serveur que je redemarre rarement, je ne devrais pas avoir rapidement l'occasion de vérifier que ça fonctionne bien... je vais faire des essais anodins sur une autre machine en attendant, mais elle est sous panther et lui sous jaguar.
Dernier point : l'une des applis est proxyper, le proxy de distribution de calculs de dnetc (OGR et RC5).
Pour lancer ce truc, il faut : 1) se placer dans le repertoire du machin : cd xxx/proxu 2) lancer le bouzin : ./proxyper
et il tourne dans la fenetre du terminal
Q1 : si j'ai bien compris la doc, ils disent qu'il n'y a pas d'option permettant de le mettre en détaché ; il est donc indispensable de garder la fenetre du terminal ouverte ?
en général, sous unix, si tu lances ta commande en la faisant suivre d'un "&", tu récupères la main. Le problème ne se posera pas si tu lances ta commande via la crontab, ou via un script, puisque tu n'as pas de "fenêtre terminal" qui s'ouvre, normalement, donc pas de fenêtre que tu dois garder sans la fermer. Ex:
----- #!/bin/bash
./proxyper &
# le reste de tes commandes -----
Q2 : je crois comprendre que mettre d'abord le terminal dans le repertoire de l'appli permet à celle-ci de trouver facilement ses fichiers ; n'y a-t-il pas moyen de mettre la localisation et le lancement de l'appli danas la meme ligne avec un pipe ? j'ai essayé, ça ne fonctionne pas : pas de repertoire ayant ce nom
Si tu fais un pipe, il éxécute tes commandes au même niveau, mais en passant la sortie de l'un à l'entrée de l'autre.
Si tu utilises un ";", il éxécute tes commandes les unes à la suite de l'autre.
Si tu utilises un "&&" (double, donc) il éxécute tes commandes l'une à la suite de l'autre, mais il n'éxécute la commande suivante que si la commande précédente 1) est terminée, 2) a renvoyé un code de sortie normal (0, de tête?).
Donc dans ton exemple, le plus approprié est (même si selon moi le dernier & n'est pas absolument nécessaire):
----- cd /chemin/complet/xxx/proxu && ./proxyper & -----
Ceci à mon avis tu ferais mieux d'apprendre les bases d'unix et de son terminal, ça te sera plus profitable que de demander point après point tout ce dont tu as besoin. ("Si tu donnes un poisson à un homme..." ;) )
manet wrote:
Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:
là c'est un peu extrème.
merci à tous, en 3 réponses j'ai appris énormément de choses
j'essayerais vendredi, mais comme c'est un serveur que je redemarre
rarement, je ne devrais pas avoir rapidement l'occasion de vérifier que
ça fonctionne bien... je vais faire des essais anodins sur une autre
machine en attendant, mais elle est sous panther et lui sous jaguar.
Dernier point :
l'une des applis est proxyper, le proxy de distribution de calculs de
dnetc (OGR et RC5).
Pour lancer ce truc, il faut :
1) se placer dans le repertoire du machin : cd xxx/proxu
2) lancer le bouzin : ./proxyper
et il tourne dans la fenetre du terminal
Q1 :
si j'ai bien compris la doc, ils disent qu'il n'y a pas d'option
permettant de le mettre en détaché ; il est donc indispensable de garder
la fenetre du terminal ouverte ?
en général, sous unix, si tu lances ta commande en la faisant suivre
d'un "&", tu récupères la main. Le problème ne se posera pas si tu
lances ta commande via la crontab, ou via un script, puisque tu n'as pas
de "fenêtre terminal" qui s'ouvre, normalement, donc pas de fenêtre que
tu dois garder sans la fermer. Ex:
-----
#!/bin/bash
./proxyper &
# le reste de tes commandes
-----
Q2 :
je crois comprendre que mettre d'abord le terminal dans le repertoire de
l'appli permet à celle-ci de trouver facilement ses fichiers ; n'y
a-t-il pas moyen de mettre la localisation et le lancement de l'appli
danas la meme ligne avec un pipe ? j'ai essayé, ça ne fonctionne pas :
pas de repertoire ayant ce nom
Si tu fais un pipe, il éxécute tes commandes au même niveau, mais en
passant la sortie de l'un à l'entrée de l'autre.
Si tu utilises un ";", il éxécute tes commandes les unes à la suite de
l'autre.
Si tu utilises un "&&" (double, donc) il éxécute tes commandes l'une à
la suite de l'autre, mais il n'éxécute la commande suivante que si la
commande précédente 1) est terminée, 2) a renvoyé un code de sortie
normal (0, de tête?).
Donc dans ton exemple, le plus approprié est (même si selon moi le
dernier & n'est pas absolument nécessaire):
-----
cd /chemin/complet/xxx/proxu && ./proxyper &
-----
Ceci à mon avis tu ferais mieux d'apprendre les bases d'unix et de son
terminal, ça te sera plus profitable que de demander point après point
tout ce dont tu as besoin. ("Si tu donnes un poisson à un homme..." ;) )
merci à tous, en 3 réponses j'ai appris énormément de choses j'essayerais vendredi, mais comme c'est un serveur que je redemarre rarement, je ne devrais pas avoir rapidement l'occasion de vérifier que ça fonctionne bien... je vais faire des essais anodins sur une autre machine en attendant, mais elle est sous panther et lui sous jaguar.
Dernier point : l'une des applis est proxyper, le proxy de distribution de calculs de dnetc (OGR et RC5).
Pour lancer ce truc, il faut : 1) se placer dans le repertoire du machin : cd xxx/proxu 2) lancer le bouzin : ./proxyper
et il tourne dans la fenetre du terminal
Q1 : si j'ai bien compris la doc, ils disent qu'il n'y a pas d'option permettant de le mettre en détaché ; il est donc indispensable de garder la fenetre du terminal ouverte ?
en général, sous unix, si tu lances ta commande en la faisant suivre d'un "&", tu récupères la main. Le problème ne se posera pas si tu lances ta commande via la crontab, ou via un script, puisque tu n'as pas de "fenêtre terminal" qui s'ouvre, normalement, donc pas de fenêtre que tu dois garder sans la fermer. Ex:
----- #!/bin/bash
./proxyper &
# le reste de tes commandes -----
Q2 : je crois comprendre que mettre d'abord le terminal dans le repertoire de l'appli permet à celle-ci de trouver facilement ses fichiers ; n'y a-t-il pas moyen de mettre la localisation et le lancement de l'appli danas la meme ligne avec un pipe ? j'ai essayé, ça ne fonctionne pas : pas de repertoire ayant ce nom
Si tu fais un pipe, il éxécute tes commandes au même niveau, mais en passant la sortie de l'un à l'entrée de l'autre.
Si tu utilises un ";", il éxécute tes commandes les unes à la suite de l'autre.
Si tu utilises un "&&" (double, donc) il éxécute tes commandes l'une à la suite de l'autre, mais il n'éxécute la commande suivante que si la commande précédente 1) est terminée, 2) a renvoyé un code de sortie normal (0, de tête?).
Donc dans ton exemple, le plus approprié est (même si selon moi le dernier & n'est pas absolument nécessaire):
----- cd /chemin/complet/xxx/proxu && ./proxyper & -----
Ceci à mon avis tu ferais mieux d'apprendre les bases d'unix et de son terminal, ça te sera plus profitable que de demander point après point tout ce dont tu as besoin. ("Si tu donnes un poisson à un homme..." ;) )
blanc
EcceAngelo wrote:
en général, sous unix, si tu lances ta commande en la faisant suivre d'un "&", tu récupères la main. Le problème ne se posera pas si tu lances ta commande via la crontab, ou via un script, puisque tu n'as pas de "fenêtre terminal" qui s'ouvre, normalement, donc pas de fenêtre que tu dois garder sans la fermer. Ex:
----- #!/bin/bash
./proxyper &
# le reste de tes commandes -----
Ceci ne marche que si ta commande (proxyper) n'affiche rien dans le terminal. Si par contre elle affiche des messages dans le terminal (et en supposant que ces messages ne t'intéressent pas), alors il faut en outre rediriger la sortie standard vers /dev/null qui est un puit dans lequel il se perdront :
./proxyper >/dev/null &
ou bien vers un fichier quelconque où tu pourras les lire ensuite :
./proxyper>tonfichier &
Donc dans ton exemple, le plus approprié est (même si selon moi le dernier & n'est pas absolument nécessaire):
----- cd /chemin/complet/xxx/proxu && ./proxyper & -----
En outre, si tu souhaites te retrouver dans le répertoire initial après exécution de cette ligne de commande, il te suffit de l'englober dans des accolades : { cd /chemin/complet/xxx/proxu && ./proxyper & }
ou dans des parenthèses (mais dans ce cas, cela lance un sous-shell).
en général, sous unix, si tu lances ta commande en la faisant suivre
d'un "&", tu récupères la main. Le problème ne se posera pas si tu
lances ta commande via la crontab, ou via un script, puisque tu n'as pas
de "fenêtre terminal" qui s'ouvre, normalement, donc pas de fenêtre que
tu dois garder sans la fermer. Ex:
-----
#!/bin/bash
./proxyper &
# le reste de tes commandes
-----
Ceci ne marche que si ta commande (proxyper) n'affiche rien dans le
terminal. Si par contre elle affiche des messages dans le terminal (et
en supposant que ces messages ne t'intéressent pas), alors il faut en
outre rediriger la sortie standard vers /dev/null qui est un puit dans
lequel il se perdront :
./proxyper >/dev/null &
ou bien vers un fichier quelconque où tu pourras les lire ensuite :
./proxyper>tonfichier &
Donc dans ton exemple, le plus approprié est (même si selon moi le
dernier & n'est pas absolument nécessaire):
-----
cd /chemin/complet/xxx/proxu && ./proxyper &
-----
En outre, si tu souhaites te retrouver dans le répertoire initial après
exécution de cette ligne de commande, il te suffit de l'englober dans
des accolades :
{ cd /chemin/complet/xxx/proxu && ./proxyper & }
ou dans des parenthèses (mais dans ce cas, cela lance un sous-shell).
en général, sous unix, si tu lances ta commande en la faisant suivre d'un "&", tu récupères la main. Le problème ne se posera pas si tu lances ta commande via la crontab, ou via un script, puisque tu n'as pas de "fenêtre terminal" qui s'ouvre, normalement, donc pas de fenêtre que tu dois garder sans la fermer. Ex:
----- #!/bin/bash
./proxyper &
# le reste de tes commandes -----
Ceci ne marche que si ta commande (proxyper) n'affiche rien dans le terminal. Si par contre elle affiche des messages dans le terminal (et en supposant que ces messages ne t'intéressent pas), alors il faut en outre rediriger la sortie standard vers /dev/null qui est un puit dans lequel il se perdront :
./proxyper >/dev/null &
ou bien vers un fichier quelconque où tu pourras les lire ensuite :
./proxyper>tonfichier &
Donc dans ton exemple, le plus approprié est (même si selon moi le dernier & n'est pas absolument nécessaire):
----- cd /chemin/complet/xxx/proxu && ./proxyper & -----
En outre, si tu souhaites te retrouver dans le répertoire initial après exécution de cette ligne de commande, il te suffit de l'englober dans des accolades : { cd /chemin/complet/xxx/proxu && ./proxyper & }
ou dans des parenthèses (mais dans ce cas, cela lance un sous-shell).
