exécuter un script à distance

In article <slrngddbeu.5ni.stephane.chazelas@spam.is.invalid>,
Stephane CHAZELAS <stephane_chazelas@yahoo.fr> wrote:

2008-09-21, 14:00(+02), Thomas:
[...]
>> > ssh ordi-distant < script-local
[...]
> par contre, le shell distant va être "en mode interactif" et va croire
> que le contenu de script-local est tapé au clavier, c'est bien ça ?

Non, comme le stdin de ssh n'est pas un terminal, ssh ne lance
pas un shell interactif a l'autre bout.

ah ça y est, en relisant 3 fois je crois que j'ai compris :-)

C'est comme si tu faisais:

"$SHELL" < script-local

donc
"$SHELL"
lance un shell interactif,
mais
"$SHELL" < script-local
lance un shell pas interactif

c'est ça ? :-)

> est ce que je peux (continuer à) écrire script-local comme si il allait
> être exécuté en tant que script ? ça ne risque pas de poser de pb ?

Non, a part que si ton script lit son entree standard, ca va
lire le contenu du script!

ok merci :-)

> par exemple, tous mes scripts commencent par
> #!/bin/sh -x -
> qu'est ce que ça fait ?

C'est un commentaire pour le shell, donc ca ne fait rien.

ok,
maintenant que j'ai compris pourquoi le shell ne sera pas interactif, je
suis tranquille :-)

Si tu veux activer l'option x quelle que soit la facon dont le
script est lancé, utilise plutot "set -x".

finalement, à force d'insistance, je me suis décidé à transformer mes
tetes de script de

#!/bin/sh -x -
DOSSIERPARENT=`dirname "$0" || exit "$?"`

en

#!/bin/sh -
DOSSIERPARENT=`dirname "$0" || echo " erreur dirname : $? "`
set -x

... et finalement, c'est mieux :-)


mais ta solution m'a fait penser à une autre :

echo 'commandes' | ssh ordi-distant

il ne me reste plus qu'un souci mineur :
j'ai pas bien compris le fonctionnement de "<retour>"

il vaut mieux que je l'utilise dans ou en dehors des guillemets ?

apparemment, le résultat est sur une seule ligne : les retours ne sont
pas intégrés à la chaîne, ils disparaissent
il suffit que je rajoute des ";" pour séparer les commandes, ou il y a
autre chose de mieux ?

>> j'aurais plutot mis : ssh ordi-distant sh < script-local
>
> merci, qu'est ce que ça fait exactement ?
>
> - est ce que c'est juste au cas où le shell de login ne serais pas sh ?
[...]

Oui.

ok merci :-)


par contre j'aimerais comprendre comment marchent - et -c stp :-)

par exemple,
pourquoi en tête de script on met

#!/bin/sh -

et pas

#!/bin/sh -c

et pourquoi ssh utilise -c quand on lui demande d'exécuter une commande
précise ?

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/

2008-10-14, 16:46(+02), Thomas:
[...]

donc
"$SHELL"
lance un shell interactif,

Si l'entree standard est un terminal.

mais
"$SHELL" < script-local
lance un shell pas interactif

c'est ça ? :-)

Ce sont les memes arguments passés au $SHELL. Ce qui change est
que ton shell redirige l'entree standard depuis un fichier avant
de lancer $SHELL.

[...]

#!/bin/sh -
DOSSIERPARENT=`dirname "$0" || echo " erreur dirname : $? "`
set -x

... et finalement, c'est mieux :-)


mais ta solution m'a fait penser à une autre :

echo 'commandes' | ssh ordi-distant

il ne me reste plus qu'un souci mineur :
j'ai pas bien compris le fonctionnement de "<retour>"

il vaut mieux que je l'utilise dans ou en dehors des guillemets ?

apparemment, le résultat est sur une seule ligne : les retours ne sont
pas intégrés à la chaîne, ils disparaissent
il suffit que je rajoute des ";" pour séparer les commandes, ou il y a
autre chose de mieux ?

Je ne comprends pas la question. A quoi fais-tu reference.

Tu peux faire:

echo '
commande1
commande2
' | ssh ordi-distant

ou

ssh ordi-distant << EOF
commande1
commande2
EOF

ou

ssh ordi-distant << EOF
commande $(pas expandé par le shell local)
EOF

>> j'aurais plutot mis : ssh ordi-distant sh < script-local
>
> merci, qu'est ce que ça fait exactement ?
>
> - est ce que c'est juste au cas où le shell de login ne serais pas sh ?
[...]

Oui.

ok merci :-)


par contre j'aimerais comprendre comment marchent - et -c stp :-)

"-", c'est pour mettre fin aux options, pour etre sur que sh -
-c, execute le script qui se trouve dans le fichier "-c".

-c c'est pour passer le contenu d'un script en ligne de
commande.

sh -c 'cmd1; cmd2'
execute la commande line "cmd1; cmd2", sans que tu aies a la
mettre dans un fichier.

par exemple,
pourquoi en tête de script on met

#!/bin/sh -

et pas

#!/bin/sh -c

Si tu mettais #! /bin/sh -c

dans un fichier "myscript" et que tu faisais:

./myscript

Le systeme lancerait:

/bin/sh -c ./myscript

qui dirait a sh d'executer la ligne de commande "./myscript", et
donc demanderait au systeme d'executer ce fichier, qui ferait un
/bin/sh -c ./myscript etc en boucle.

et pourquoi ssh utilise -c quand on lui demande d'exécuter une commande
précise ?

Parce que c'est comme ca qu'on dit a un shell d'executer une
commande precise. Si tu fais system("echo foo") en C, ca fera
aussi a execl("/bin/sh", "/bin/sh", "-c", "echo foo", 0);


--
Stéphane

In article <slrngf9f2m.ldr.stephane.chazelas@spam.is.invalid>,
Stephane CHAZELAS <stephane_chazelas@yahoo.fr> wrote:

2008-10-14, 16:46(+02), Thomas:
[...]
> donc
> "$SHELL"
> lance un shell interactif,

Si l'entree standard est un terminal.

> mais
> "$SHELL" < script-local
> lance un shell pas interactif
>
> c'est ça ? :-)

Ce sont les memes arguments passés au $SHELL. Ce qui change est
que ton shell redirige l'entree standard depuis un fichier avant
de lancer $SHELL.

merci, je pense que j'ai compris :-)

> mais ta solution m'a fait penser à une autre :
>
> echo 'commandes' | ssh ordi-distant
>
> il ne me reste plus qu'un souci mineur :
> j'ai pas bien compris le fonctionnement de "<retour>"
>
> il vaut mieux que je l'utilise dans ou en dehors des guillemets ?
>
> apparemment, le résultat est sur une seule ligne : les retours ne sont
> pas intégrés à la chaîne, ils disparaissent
> il suffit que je rajoute des ";" pour séparer les commandes, ou il y a
> autre chose de mieux ?

Je ne comprends pas la question. A quoi fais-tu reference.

echo '
commande1
commande2
' | ssh ordi-distant

Tu peux faire:

echo '
commande1
commande2
' | ssh ordi-distant

ah, super :-))
je savais pas que c'était possible !


bon ben j'ai encore mieux que tout le reste :

ssh ordi-distant '
commande1
commande2
'


merci bcp pour toute ton aide :-)

ou

ssh ordi-distant << EOF
commande1
commande2
EOF

ou

ssh ordi-distant << EOF
commande $(pas expandé par le shell local)
EOF

je comprends pas en détail, mais je pense que je n'en ai pas besoin :-)
(si ?)

>> >> j'aurais plutot mis : ssh ordi-distant sh < script-local
>> >
>> > merci, qu'est ce que ça fait exactement ?
>> >
>> > - est ce que c'est juste au cas où le shell de login ne serais pas sh ?
>> [...]
>>
>> Oui.
>
> ok merci :-)
>
>
> par contre j'aimerais comprendre comment marchent - et -c stp :-)

"-", c'est pour mettre fin aux options, pour etre sur que sh -
-c, execute le script qui se trouve dans le fichier "-c".

-c c'est pour passer le contenu d'un script en ligne de
commande.

sh -c 'cmd1; cmd2'
execute la commande line "cmd1; cmd2", sans que tu aies a la
mettre dans un fichier.

j'ai encore du mal à saisir les nuances
je ne connais pas assez le fonctionnement du shell et des appels système

en gros,
"sh - fichier" c'est seulement si fichier existe, sans aucune
interprétation, et en plus ça ne peut pas être un exécutable, ça doit
impérativement être un script shell ?
et "sh -c 'commande'" ça peut être le contenu entier d'un script si on
veut ?
en fin de compte, à part dans le cas particulier de la tête de script,
si on peut faire "sh - fichier" on peut faire "sh -c fichier", ça marche
toujours ?


et pour ce qui me concerne,
pour parer au cas où le shell de login ne serais pas sh,
il suffit de faire

ssh ordi-distant 'sh -c '''
commande1
commande2
''

et ça roule ?

en fait, pour faire un truc parfaitement sur, il faudrait que je le
fasse pour chaque connexion ssh qui exécute une commande ?
ça ne risque pas de faire trop lourd ? (je veux dire, pas pour moi, le
fait qu'il y ait des sh les uns sur les autres)

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/