Bonjour
Je tombe sur un os avec ssh.
# ssh utilisateur@machine bash -c "ls /"
(rien)
# ssh utilisateur@machine bash -c ";ls /"
bin
boot
dev
etc etc
# ssh utilisateur@machine bash -c "echo 123"
(ligne vide)
# ssh utilisateur@machine bash -c "echo 123;echo 456"
(ligne vide)
456
# ssh utilisateur@machine bash -c "echo 123;echo 456;echo 789"
(ligne vide)
456
789
Vraiment je ne comprends pas.
# Marrant ca...
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
ssh username@remotehost "echo 123" # avec ou sans quote
Et ca marche très bien :)
[^] # Re: Marrant ca...
Posté par NeoX . Évalué à 2.
[^] # Re: Marrant ca...
Posté par Damien (site web personnel) . Évalué à 2.
# [mode verbose on]
Posté par ecid . Évalué à 1.
# j'ai peut être l'explication...
Posté par genma (site web personnel) . Évalué à 4.
Ca doit venir de là. Dans bash -c "ls /", le ls / est compris comme un argument et non comme une commande...
# protections (quoting)
Posté par tuxce (site web personnel) . Évalué à 2.
bash -c echo 123;echo 456;echo 789
sans les ", bash quand à lui ne prend qu'un argument après le -c ->
echo
ce qui fait la ligne vide (le "ls" ne prend pas le / et doit lister le répertoire courant qui doit être vide)
en gros, si tu tiens absolument à tout envoyer avec le "bash -c":
ssh user@hote "bash -c 'echo 123;echo 456;echo 789'"
[^] # Re: protections (quoting)
Posté par Kerro . Évalué à 2.
scp toto@machine:"'source avec espaces'" cible
On peut faire aussi:
ssh user@hote bash -c "'echo 123;echo 456;echo 789'"
Ca surprend d'avoir "' puis '" :-)
[^] # Re: protections (quoting)
Posté par tuxce (site web personnel) . Évalué à 2.
[^] # Re: protections (quoting)
Posté par Kerro . Évalué à 1.
C'est référencé comme bug 419848 chez Debian. 89945 chez Ubuntu. Je n'ai pas cherché ailleurs.
La réponse des intégristes est "ce fonctionnement tordu est normal".
[^] # Re: protections (quoting)
Posté par wismerhill . Évalué à 4.
Le shell interprète la ligne avant de lancer la commande, donc ta ligne
ssh utilisateur@machine bash -c "echo 123;echo 456"
est d'abord interprétée par le shell, qui enlève les guillemets et ssh ne voit que
ssh utilisateur@machine bash -c echo 123;echo 456
qu'il envoie au serveur distant, qui lui verra
bash -c echo 123;echo 456
qui sera a son tour interprété par le shell distant, qui va séparer ça en deux commandes
bash -c echo 123
echo 456
Pour ce que tu veux faire tu aurais du essayer
ssh utilisateur@machine bash -c '"echo 123;echo 456"'
où les simple quote vont protéger les doubles qui seront passés tels quel à ssh qui va les envoyer comme ça au serveur distant, qui exécutera donc la commande
bash -c "echo 123;echo 456"
mais comme écrit par d'autres, un simple
ssh utilisateur@machine "echo 123;echo 456"
fait l'affaire (les double quote sont encore là pour protéger le point-virgule).
[^] # Re: protections (quoting)
Posté par tuxce (site web personnel) . Évalué à 3.
et si tu veux vraiment qu'une variable par exemple soit interprétée, tu fais comment? tu crées un moyen pour l'indiquer !
la ligne est interprétée à chaque étape; pour la question d'origine, c'est d'abord le shell puis ssh et enfin bash! et le problème de départ est la première ligne vide qui est due à la façon dont le bash traite l'argument "-c" qui ne prend qu'un seul argument, tu vas quand meme pas lui imposer d'en prendre 2 ou plus :p (ca en casserait des scripts)
pour ce qui est des bugs, celui de debian n'est pas considéré comme bug et celui d'ubuntu est résolu et ne concerne que l'affichage pas le succès de l'opération.
# Quotes !
Posté par gUI (Mastodon) . Évalué à 2.
ssh utilisateur@machine 'bash -c "ls /"'
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.