How to execute bash script on remote server via local bash script? :D

trusty33

Another frustrating question/topic title, sorry.

I am connecting thru KiTTY (improved PuTTY) terminal app into Linux CentOS 6 server 1 where i run bash script which is executing another bash script located on remote server (same OS - Linux CentOS6). I do it via SSH command inside first server bash script:
ssh -p 22 remoteuser@remoteIP "/bin/bash /home/remoteuser/remotescript 1820 1.2.3.4 5.6.7.8"
...you can see i am adding parameters $1 $2 $3 to that script

i expect to see interactive output of that remote script (prompts) - i made that remote script to prompt in case it is missing any of the parameters, but it says:
TERM environment variable not set.
and prints some outputs of that remote script and the output looks like if the parameters was not recoded/accepted.

Any idea what i should define in the script (which one) and or if the ssh command should be otherwise please?

ITLabs

Try passing the parameters using -o option:

Sets any option that can be configured using a configuration file keyword. For a list of keywords and their meanings, see ssh2_config(5). Syntax alternatives are shown below. Use quotation marks to contain expressions that include spaces.

-o key1=value

To configure multiple options, use multiple -o switches.

-o key1=value -o key2=value

trusty33

You appear to be quoting from "sftp" manual page, but i am not using sftp nor ftp. I am using SSH and need to add parameters to a bash script.. i believe :-/

ITLabs

@trusty33 said:
You appear to be quoting from "sftp" manual page, but i am not using sftp nor ftp. I am using SSH and need to add parameters to a bash script.. i believe :-/

https://www.attachmate.com/documentation/rsit-unix-802/rsit-unix-guide/data/ssh_options_ap.htm

In your first script try passing the arguments this way:

ssh -o arg1=$1 -o arg2=$2 -p 22 remoteuser@remoteIP "/bin/bash /home/remoteuser/remotescript"

trusty33

Thanks, though i do not understand how to use it to make sense, for example this does not make much sense to me and NOT worked:
A )
ssh -o key1=$pa -o key2=$pb -o key3=$pc -p 22 remoteuser@remoteIP "/bin/bash /home/remoteuser/remotescript $pa $pb $pc"
B )
ssh -o key1=$pa -o key2=$pb -o key3=$pc -p 22 remoteuser@remoteIP "/bin/bash /home/remoteuser/remotescript $key1 $key2 $key3"

ITLabs

Mmmm... take a look at this:

https://unix.stackexchange.com/questions/87405/how-can-i-execute-local-script-on-remote-machine-and-include-arguments

uptime

hello ...

try this - on your local machine, do something like this to confirm the parameters that think you are sending:

(for example)

echo pa: ${pa}, pb: ${pb}, pc: ${pc}
echo key1: ${key1}, key2: ${key2}, key3: ${key3}

what is the result?

farsighter

Try to add -t option to your ssh command.

You can also try and run everything from an 'expect' script

uptime

I'm guessing that the problem may have more to do with the remote script than anything else. Let's do another simple test to rule out that possibility.

On your remote system, create a file called my_args.sh with the following lines:

#!/bin/bash
echo first arg: $1
echo second arg: $2
echo third arg: $3

then, still on the remote system, type chmod +x my_args.sh

now, on your local system, in kitty or whatever:

ssh -p 22 remoteuser@remoteIP "./my_args.sh one two three"

(or if you created the file in some directory called "somedir" rather than the home directory then you'll want to use the absolute path /home/remoteuser/somedir/my_args.sh instead of ./my_args.sh)

what does that do for you?

Also - if you want to get rid of the TERM undefined warning, try

ssh -p 22 remoteuser@remoteIP "TERM=dumb ./my_args.sh one two three"

(might also try "TERM=vt100" or something like that ... shouldn't matter unless you need fancier terminal capabilities for ncurses or whatever)

Anyway ... if the "my_args.sh" test works then you know to debug that other script on your remote machine.

Keep in mind a lot of this is just being methodical and applying some logic and scientific method to eliminate variables. It may seem overwhelming at first especially if you're in the habit of just thrashing around asking vague questions and taking the random advice that you get in response.

But everybody gets one. (You got two.)

Capiche?

EDIT2:

And if it turns out that your remote "script" does not begin with the #!/bin/bash then that might explain why the arguments are not being picked up - since the file then just contain a series of commands to be executed in the current environment, rather than a proper script in a subshell which treats the $1 etc positional parameters as intended ... This would be masked by sending the "/bin/bash" directive as part of the ssh command (rather than embedding it as a "shebang" directive ("#!/bin/bash") in the remote file itself.

Simple, right? (j/k)

EDIT3:

So, if you end up needing to add that "shebang" directive to your remote script, then also be aware you'll want to also do a chmod +x remotescript (on the remote machine) to make it executable. (And, while you can then actually leave the now-superfluous "/bin/bash" in your ssh command - you may as well take it out - since less typing means less chance for typos and random confusion.)

welcome to the wonderful world of shell programming. Enjoy.

trusty33

Thanks all.

I think that what helped was these two things:

chmod +x remotescriptname

and adding "TERM=dumb " prefix to the SSH command sent to the remote server:
ssh -p 22 remoteuser@remoteIP "TERM=dumb ./my_args.sh one two three"

yes, it worked @uptime thank you for help 👍

The parameters was read well by the script, but somewhere in the middle of the script it got nulled maybe. Now it works.

ITLabs

@trusty33 Your opinion matters!

Please rate our support.

Thanks.

uptime

Lulz ...

ITLabs

C'mon guys... it's a serious survey.

farsighter

You probably skipped my short answer because adding the -t option serves the same purpose for you....
Anyway @uptime obviously put a lot more effort into explaining you things so he should be the winner.:)

Ticket closed.

ITLabs

@farsighter said:
Anyway @uptime obviously put a lot more effort into explaining you things so he should be the winner.:)

@uptime please receive my heartiest congratulations on winning the "Great Answer Award".

This is a tribute bestowed only on those who are recognized by the Academy of Low End Talks for their effort, dedication, energy, sacrifice and skills.

This trophy acknowledges how it is good to have someone of your caliber here.

Keep up the good work and may God bless your heart.