ssh user@server ls $DOSSIER
ssh user@server command X
ssh user@server command Y
À chaque commande, il va recréer une connexion, j'imagine (à moins qu'il y ait une logique dans ssh pour ne pas fermer une connexion immédiatement à la fin de la commande, mais après un timeout, pour pouvoir la réutiliser; mais j'en doute fortement; pour cela d'une il faudrait un daemon côté client aussi, de deux, ce serait une faille de sécurité potentielle donc ne devrait être accessible que par option). Donc déjà ça va rallonger la durée du script (pour un script court et des machines dans un réseau local, pas forcément de beaucoup, certes).
Mais surtout cela veut dire que ça recrée un nouvel environnement à chaque commande, donc toutes les variables d'environnement créées précédemment seront perdues.
Alors ça reste faisable en mettant toutes les variables d'environnement au début de chaque commande (et non d'en faire des commandes elle-même).
PLOP=value PLIP=value2 command
Sauf que ça ne marchera pas lorsque tu utilises les variables directement dans la ligne de commande (car le shell les transforme sans prendre en compte la ligne de commande), ex:
PLOP=value echo $PLOP
Ne marchera pas. Tu voudras faire à la place (par exemple si ton shell est bash):
PLOP=value bash -c 'echo $PLOP'
Pareil lorsqu'il y a des pipes, etc.
Mais franchement, je trouve que c'est se compliquer la vie pour pas grand chose. En gros, je prendrais la solution A: envoie le script sur le serveur juste avant l'exécution et exécute le en local.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: 2 possibilités
Posté par Jehan (site web personnel, Mastodon) . En réponse au message execution d'un script local sur des machines distantes. Évalué à 3.
À chaque commande, il va recréer une connexion, j'imagine (à moins qu'il y ait une logique dans ssh pour ne pas fermer une connexion immédiatement à la fin de la commande, mais après un timeout, pour pouvoir la réutiliser; mais j'en doute fortement; pour cela d'une il faudrait un daemon côté client aussi, de deux, ce serait une faille de sécurité potentielle donc ne devrait être accessible que par option). Donc déjà ça va rallonger la durée du script (pour un script court et des machines dans un réseau local, pas forcément de beaucoup, certes).
Mais surtout cela veut dire que ça recrée un nouvel environnement à chaque commande, donc toutes les variables d'environnement créées précédemment seront perdues.
Alors ça reste faisable en mettant toutes les variables d'environnement au début de chaque commande (et non d'en faire des commandes elle-même).
Sauf que ça ne marchera pas lorsque tu utilises les variables directement dans la ligne de commande (car le shell les transforme sans prendre en compte la ligne de commande), ex:
Ne marchera pas. Tu voudras faire à la place (par exemple si ton shell est bash):
Pareil lorsqu'il y a des pipes, etc.
Mais franchement, je trouve que c'est se compliquer la vie pour pas grand chose. En gros, je prendrais la solution A: envoie le script sur le serveur juste avant l'exécution et exécute le en local.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]