je souhaite exécuter un script sur un ordi distant
je n'ai pas suffisamment confiance en l'ordi distant pour mettre le
script là bas une fois pour toutes, puis l'exécuter en une commande ssh
sans vérifier son intégrité
ce que j'aimerais faire, c'est :
avoir le script sur mon ordi,
et demander à ssh quand je l'exécute, de prendre le script sur mon ordi
et de l'exécuter sur l'ordi distant
est ce que c'est possible, ça ?
(pour l'instant j'ai un script chez moi avec ssh à chaque ligne, ça me
parait pas le meilleur choix)
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
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 ?
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
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 ?
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
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 ?
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
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.
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);
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
Thomas
In article , Stephane CHAZELAS 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
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)
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
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)
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
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)
