est ce que c'est possible d'exécuter en parallèle et attendre la fin ?
du genre :
commande1 &
commande2 &
on attend que commande1 et commande2 soient terminées
commande3
parce que c'est plus rapide d'exécuter commande1 et commande2 en
parallèle, par exemple parce qu'elles n'utilisent pas les mêmes
ressources,
mais on a besoin d'attendre qu'elles soient terminées pour pouvoir
exécuter commande3
--
j'agis contre l'assistanat, je travaille dans une SCOP !
qq c'est ? (juste une curiosité, help me suffit pour l'instant :-) ) [...]
Tape
info zsh
puis "i" pour avoir l'index, puis wai<Tab> puis <Enter>.
-- Stéphane
Thomas
In article , Stephane Chazelas wrote:
2007-09-15, 01:21(+02), Thomas: [...]
il y a un script que je termine par commande > dossier/log &
je ne veux surtout pas attendre la fin de commande parce que je veux que ce script se termine très vite
mais, si possible, j'aimerais quand même être prévenu (avec un code d'erreur, comme quand la dernière commande retourne une erreur) si commande ne peut pas être lancé correctement (si commande n'existe pas, si commande n'est pas exécutable, si le dossier du log n'existe pas, ...) est ce que c'est possible de façon pas trop compliquée ? :-)
Faudra faire les tests a la main:
if type commande > /dev/null; then exec > dossier/log commande & fi
parce que j'étais pas sur qu'avec le if ça renvoie un code d'erreur si lancement-des-sous-scripts n'est pas exécutable
là, j'ai vérifié, je suis bien prévenu pour chaque problème que j'ai pu imaginer :-)
exec fait terminer le shell s'il echoue.
reste un pb mineur : apparemment exec ne fait pas "rien" si il n'y a pas de pb, puisqu'on ne peut pas récupérer le texte qui sort des commandes qui sont après
il n'y a pas l'équivalent sans cet inconvénient ? (si non, tant pis, c'est pas grave)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <slrnfen648.5d3.stephane.chazelas@spam.is.invalid>,
Stephane Chazelas <cette.adresse@est.invalid> wrote:
2007-09-15, 01:21(+02), Thomas:
[...]
il y a un script que je termine par
commande > dossier/log &
je ne veux surtout pas attendre la fin de commande parce que je veux que
ce script se termine très vite
mais, si possible, j'aimerais quand même être prévenu (avec un code
d'erreur, comme quand la dernière commande retourne une erreur) si
commande ne peut pas être lancé correctement
(si commande n'existe pas, si commande n'est pas exécutable, si le
dossier du log n'existe pas, ...)
est ce que c'est possible de façon pas trop compliquée ? :-)
Faudra faire les tests a la main:
if type commande > /dev/null; then
exec > dossier/log
commande &
fi
parce que j'étais pas sur qu'avec le if ça renvoie un code d'erreur si
lancement-des-sous-scripts n'est pas exécutable
là, j'ai vérifié, je suis bien prévenu pour chaque problème que j'ai pu
imaginer :-)
exec fait terminer le shell s'il echoue.
reste un pb mineur :
apparemment exec ne fait pas "rien" si il n'y a pas de pb, puisqu'on ne
peut pas récupérer le texte qui sort des commandes qui sont après
il n'y a pas l'équivalent sans cet inconvénient ?
(si non, tant pis, c'est pas grave)
--
j'agis contre l'assistanat, je travaille dans une SCOP !
il y a un script que je termine par commande > dossier/log &
je ne veux surtout pas attendre la fin de commande parce que je veux que ce script se termine très vite
mais, si possible, j'aimerais quand même être prévenu (avec un code d'erreur, comme quand la dernière commande retourne une erreur) si commande ne peut pas être lancé correctement (si commande n'existe pas, si commande n'est pas exécutable, si le dossier du log n'existe pas, ...) est ce que c'est possible de façon pas trop compliquée ? :-)
Faudra faire les tests a la main:
if type commande > /dev/null; then exec > dossier/log commande & fi
parce que j'étais pas sur qu'avec le if ça renvoie un code d'erreur si lancement-des-sous-scripts n'est pas exécutable
là, j'ai vérifié, je suis bien prévenu pour chaque problème que j'ai pu imaginer :-)
exec fait terminer le shell s'il echoue.
reste un pb mineur : apparemment exec ne fait pas "rien" si il n'y a pas de pb, puisqu'on ne peut pas récupérer le texte qui sort des commandes qui sont après
il n'y a pas l'équivalent sans cet inconvénient ? (si non, tant pis, c'est pas grave)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
Cyrille Lefevre
In article , Stephane Chazelas wrote:
2007-09-15, 01:21(+02), Thomas: [...]
il y a un script que je termine par commande > dossier/log &
je ne veux surtout pas attendre la fin de commande parce que je veux que ce script se termine très vite
mais, si possible, j'aimerais quand même être prévenu (avec un code d'erreur, comme quand la dernière commande retourne une erreur) si commande ne peut pas être lancé correctement (si commande n'existe pas, si commande n'est pas exécutable, si le dossier du log n'existe pas, ...) est ce que c'est possible de façon pas trop compliquée ? :-) Faudra faire les tests a la main:
if type commande > /dev/null; then exec > dossier/log commande & fi
j'ai fait
type `dirname "$0"`/lancement-des-sous-scripts > /dev/null || exit
DIRNAME=$(dirname "$0")
if [ ! -f "${DIRNAME}"/script ]; then echo "${DIRNAME}"/script: introuvable" >&2 exit 1 fi
if [ ! -x "${DIRNAME}"/script ]; then echo "${DIRNAME}"/script: non executable" >&2 exit 1 fi
suffira puisque tu as un exec juste au dessus, ou alors, l'exec est inutile...
parce que j'étais pas sur qu'avec le if ça renvoie un code d'erreur si lancement-des-sous-scripts n'est pas exécutable
si, si.
là, j'ai vérifié, je suis bien prévenu pour chaque problème que j'ai pu imaginer :-)
exec fait terminer le shell s'il echoue.
reste un pb mineur : apparemment exec ne fait pas "rien" si il n'y a pas de pb, puisqu'on ne peut pas récupérer le texte qui sort des commandes qui sont après
exec sert soit à faire des redirections d'entrées/sorties, soit à remplacer le shell courant par la commande spécifiée. autrement dit, tu sembles confondre "exec > fichier" et "exec commande". dans le 1er cas, exec rend toujours la main, même en cas d'erreurs. alors que dans le second, il ne rend jamais la main, même en cas d'erreurs (sauf sous bash... bien sur, saleté de bash, va :).
Regards, Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre. remove "%nospam" and ".invalid" to answer me.
In article <slrnfen648.5d3.stephane.chazelas@spam.is.invalid>,
Stephane Chazelas <cette.adresse@est.invalid> wrote:
2007-09-15, 01:21(+02), Thomas:
[...]
il y a un script que je termine par
commande > dossier/log &
je ne veux surtout pas attendre la fin de commande parce que je veux que
ce script se termine très vite
mais, si possible, j'aimerais quand même être prévenu (avec un code
d'erreur, comme quand la dernière commande retourne une erreur) si
commande ne peut pas être lancé correctement
(si commande n'existe pas, si commande n'est pas exécutable, si le
dossier du log n'existe pas, ...)
est ce que c'est possible de façon pas trop compliquée ? :-)
Faudra faire les tests a la main:
if type commande > /dev/null; then
exec > dossier/log
commande &
fi
j'ai fait
type `dirname "$0"`/lancement-des-sous-scripts > /dev/null || exit
DIRNAME=$(dirname "$0")
if [ ! -f "${DIRNAME}"/script ]; then
echo "${DIRNAME}"/script: introuvable" >&2
exit 1
fi
if [ ! -x "${DIRNAME}"/script ]; then
echo "${DIRNAME}"/script: non executable" >&2
exit 1
fi
suffira puisque tu as un exec juste au dessus, ou alors, l'exec est
inutile...
parce que j'étais pas sur qu'avec le if ça renvoie un code d'erreur si
lancement-des-sous-scripts n'est pas exécutable
si, si.
là, j'ai vérifié, je suis bien prévenu pour chaque problème que j'ai pu
imaginer :-)
exec fait terminer le shell s'il echoue.
reste un pb mineur :
apparemment exec ne fait pas "rien" si il n'y a pas de pb, puisqu'on ne
peut pas récupérer le texte qui sort des commandes qui sont après
exec sert soit à faire des redirections d'entrées/sorties, soit à
remplacer le shell courant par la commande spécifiée. autrement dit,
tu sembles confondre "exec > fichier" et "exec commande".
dans le 1er cas, exec rend toujours la main, même en cas d'erreurs.
alors que dans le second, il ne rend jamais la main, même en cas
d'erreurs (sauf sous bash... bien sur, saleté de bash, va :).
Regards, Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
remove "%nospam" and ".invalid" to answer me.
il y a un script que je termine par commande > dossier/log &
je ne veux surtout pas attendre la fin de commande parce que je veux que ce script se termine très vite
mais, si possible, j'aimerais quand même être prévenu (avec un code d'erreur, comme quand la dernière commande retourne une erreur) si commande ne peut pas être lancé correctement (si commande n'existe pas, si commande n'est pas exécutable, si le dossier du log n'existe pas, ...) est ce que c'est possible de façon pas trop compliquée ? :-) Faudra faire les tests a la main:
if type commande > /dev/null; then exec > dossier/log commande & fi
j'ai fait
type `dirname "$0"`/lancement-des-sous-scripts > /dev/null || exit
DIRNAME=$(dirname "$0")
if [ ! -f "${DIRNAME}"/script ]; then echo "${DIRNAME}"/script: introuvable" >&2 exit 1 fi
if [ ! -x "${DIRNAME}"/script ]; then echo "${DIRNAME}"/script: non executable" >&2 exit 1 fi
suffira puisque tu as un exec juste au dessus, ou alors, l'exec est inutile...
parce que j'étais pas sur qu'avec le if ça renvoie un code d'erreur si lancement-des-sous-scripts n'est pas exécutable
si, si.
là, j'ai vérifié, je suis bien prévenu pour chaque problème que j'ai pu imaginer :-)
exec fait terminer le shell s'il echoue.
reste un pb mineur : apparemment exec ne fait pas "rien" si il n'y a pas de pb, puisqu'on ne peut pas récupérer le texte qui sort des commandes qui sont après
exec sert soit à faire des redirections d'entrées/sorties, soit à remplacer le shell courant par la commande spécifiée. autrement dit, tu sembles confondre "exec > fichier" et "exec commande". dans le 1er cas, exec rend toujours la main, même en cas d'erreurs. alors que dans le second, il ne rend jamais la main, même en cas d'erreurs (sauf sous bash... bien sur, saleté de bash, va :).
Regards, Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre. remove "%nospam" and ".invalid" to answer me.
