1

I'm trying to use the -I option of pssh (parallel ssh) in a bash script and am having difficulties. This option should allow you to execute a script on your local machine on a remote machine. I've tried doing a very simple one for testing but can't seem to figure out the problem. I found this thread but pssh was run from the command line instead, that part works.

First, I have 3 different scripts

test - this gets put into the remote server's /tmp directory. it's not bash, just plain text used for a program's shell

testa - calls a command that uses test.

test3 - uses pscp to send test to /tmp and pssh to run testa.sh on the remote system

test3 contains the following:

#!/bin/bash
set -x
send="pscp.pssh -H 10.1.1.1 -l user /home/user/test /tmp/"
axe="pssh -H 10.1.1.1 -l user -I<./testa -x -tt"
${send}
${axe}
set +x

Here is the error I get:

+ pssh -H 10.1.1.1 -l user '-I<./testa' -x -tt
Usage: pssh [OPTIONS] command [...]

pssh: error: no such option: -<
+ set +x

The pscp part works fine, and I've just been sending both test and testa with pscp and executing testa on the remote server as a workaround, but I'd rather not send that one. From the debug it looks like single quotes are getting added around the -I for some reason. I've tried using -I<(./testa.sh) and still the same thing, though I can run the same command from the command line without a problem. This is on Centos 7 by the way, pssh version 2.3.1 and bash 4.2.46

Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
  • 2
    See [BashFAQ #50](http://mywiki.wooledge.org/BashFAQ/050): *I'm trying to put a command in a variable, but the complex cases always fail!* – Charles Duffy Feb 10 '21 at 21:04
  • Also, before following any advice that involves `eval`, be sure you carefully read [BashFAQ #48](http://mywiki.wooledge.org/BashFAQ/048). – Charles Duffy Feb 10 '21 at 21:06
  • Anyhow -- what's the point of the variables in the first place here, instead of just running `pssh -H 10.1.1.1 -l user -I<./testa -x -tt` as a command _directly_ in your script? – Charles Duffy Feb 10 '21 at 21:09
  • @CharlesDuffy I tried doing the command not in a variable at first and it didn't work, but I tried it just now and it did, so I must have had another issue earlier ¯\_(ツ)_/¯ Anyway it does work that way, had only done the variable for testing. I think my issue was trying to do the redirection inside the variable, because ssh worked with ```reg="ssh user@10.1.1.1 -tt"``` and then ```${reg}<./testa.sh``` – Chris Schneider Feb 10 '21 at 22:40
  • the redirection is not the _only_ thing that'll break it -- any syntax that uses a parsing step that happens before string-splitting will have the same effect. That includes things like quotes and escaping, for example. – Charles Duffy Feb 10 '21 at 23:13
  • `${axe} -I<./testa` _also_ fails if IFS is changed such that the contents of `axe` are split on a different set of characters than you expect. It _really_ shouldn't be done at all. – Charles Duffy Feb 11 '21 at 05:26
  • BTW, `SOLVED` shouldn't be edited into titles here. When your question is answered, that's reflected by the color it changes to after you select an answer as "accepted". Answers should _never_ be edited into the question itself. (In this case, the status of being closed as a duplicate tells anyone who's looking that the question is solved, because only a solved duplicate can be used to close a question). – Charles Duffy Feb 13 '21 at 20:36

0 Answers0