>>>>> "joe" == joe writes:

joe> All, I hope someone can help me out here. I often use ssh to run
joe> a local script against a list of multiple servers. The syntax I
joe> use for the ssh portion is as follows;

joe> ssh userid@server.domain "sh < localscriptname"

joe> This format works quite well for self-contained scripts, but I've
joe> run into a roadblock when I want to pass arguments to the script
joe> to the remote server. For example, I have a script that takes a
joe> file path name as an argument. Obviously, the script works fine
joe> locally.

Is there a reason you don't just make the script executable?

--
Richard Silverman
res@qoxp.net

joe wrote:
> I hope someone can help me out here. I often use ssh to run a local
> script against a list of multiple servers. The syntax I use for the ssh
> portion is as follows;

> ssh userid@server.domain "sh < localscriptname"

Why the redirect?

> This format works quite well for self-contained scripts, but I've run
> into a roadblock when I want to pass arguments to the script to the
> remote server. For example, I have a script that takes a file path name
> as an argument. Obviously, the script works fine locally.

> I've tried many variations of the above syntax, changing the quoting
> mostly, but to no avail.

> ssh userid@server.domain "sh < localscriptname /path/to/file"
> ssh userid@server.domain "sh < "localscriptname /path/to/file""
> ssh userid@server.domain "sh < localscriptname "/path/to/file""

ssh userid@server.domain "sh localscriptname /path/to/file"

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

Richard E. Silverman wrote:
>>>>>>"joe" == joe writes:
>
>
> joe> All, I hope someone can help me out here. I often use ssh to run
> joe> a local script against a list of multiple servers. The syntax I
> joe> use for the ssh portion is as follows;
>
> joe> ssh userid@server.domain "sh < localscriptname"
>
> joe> This format works quite well for self-contained scripts, but I've
> joe> run into a roadblock when I want to pass arguments to the script
> joe> to the remote server. For example, I have a script that takes a
> joe> file path name as an argument. Obviously, the script works fine
> joe> locally.
>
> Is there a reason you don't just make the script executable?
>


Okay, obviously I did not clearly explain my situation.

I am on server "A" and the script, lets call it checker.sh, exists in my
home directory on server A and is executable and works fine on server A.

I am part of a team that manages over 700 servers. Lets call them
server 0 to server 699. Often times, I need to run checker.sh against
all 700 servers. For cases like this, I have another standard script on
server A that loops through a list of servers and runs checker.sh
against each one of those servers.

roughly....

for node in `cat $list`
do
ssh root@$node "sh < checker.sh"
done

This works great...unless I want to add arguments to the script call. I
don't want to have to edit checker.sh between every run and hard code
the argument directly into the script. Also makes it tough to write a
reusable script.

Does this information help any?

tb

"joe" wrote in message
news:1JiZf.911981$xm3.704284@attbi_s21...
> Richard E. Silverman wrote:
>>>>>>>"joe" == joe writes:
>>
>>
>> joe> All, I hope someone can help me out here. I often use ssh to
>> run
>> joe> a local script against a list of multiple servers. The syntax I
>> joe> use for the ssh portion is as follows;
>>
>> joe> ssh userid@server.domain "sh < localscriptname"
>>
>> joe> This format works quite well for self-contained scripts, but
>> I've
>> joe> run into a roadblock when I want to pass arguments to the script
>> joe> to the remote server. For example, I have a script that takes a
>> joe> file path name as an argument. Obviously, the script works fine
>> joe> locally.
>>
>> Is there a reason you don't just make the script executable?
>>
>
>
> Okay, obviously I did not clearly explain my situation.
>
> I am on server "A" and the script, lets call it checker.sh, exists in my
> home directory on server A and is executable and works fine on server A.
>
> I am part of a team that manages over 700 servers. Lets call them server
> 0 to server 699. Often times, I need to run checker.sh against all 700
> servers. For cases like this, I have another standard script on server A
> that loops through a list of servers and runs checker.sh against each one
> of those servers.
>
> roughly....
>
> for node in `cat $list`
> do
> ssh root@$node "sh < checker.sh"
> done
>
> This works great...unless I want to add arguments to the script call. I
> don't want to have to edit checker.sh between every run and hard code the
> argument directly into the script. Also makes it tough to write a
> reusable script.
>
> Does this information help any?

Yes. The redirect is giving you grief: why are you using it?

Instead, please go examine the manual page for bash, and learn what this
would do. It's over engineered, but I like to avoid vagaries of different
versions of /bin/sh.

#!/bin/sh
ARGS=$@
export ARGS

echo "Executing: checker.sh $ARGS"
for node in `cat $list`; do
ssh root@$node "sh checker.sh $ARGS"
done

On Thu, 6 Apr 2006 21:20:13 -0400, "Nico Kadel-Garcia" wrote:

>
>"joe" wrote in message
>news:1JiZf.911981$xm3.704284@attbi_s21...
>> Richard E. Silverman wrote:
>>>>>>>>"joe" == joe writes:
>>>
>>>
>>> joe> All, I hope someone can help me out here. I often use ssh to
>>> run
>>> joe> a local script against a list of multiple servers. The syntax I
>>> joe> use for the ssh portion is as follows;
>>>
>>> joe> ssh userid@server.domain "sh < localscriptname"
>>>
>>> joe> This format works quite well for self-contained scripts, but
>>> I've
>>> joe> run into a roadblock when I want to pass arguments to the script
>>> joe> to the remote server. For example, I have a script that takes a
>>> joe> file path name as an argument. Obviously, the script works fine
>>> joe> locally.
>>>
>>> Is there a reason you don't just make the script executable?
>>>
>>
>>
>> Okay, obviously I did not clearly explain my situation.
>>
>> I am on server "A" and the script, lets call it checker.sh, exists in my
>> home directory on server A and is executable and works fine on server A.
>>
>> I am part of a team that manages over 700 servers. Lets call them server
>> 0 to server 699. Often times, I need to run checker.sh against all 700
>> servers. For cases like this, I have another standard script on server A
>> that loops through a list of servers and runs checker.sh against each one
>> of those servers.
>>
>> roughly....
>>
>> for node in `cat $list`
>> do
>> ssh root@$node "sh < checker.sh"
>> done
>>
>> This works great...unless I want to add arguments to the script call. I
>> don't want to have to edit checker.sh between every run and hard code the
>> argument directly into the script. Also makes it tough to write a
>> reusable script.
>>
>> Does this information help any?
>
>Yes. The redirect is giving you grief: why are you using it?
>
>Instead, please go examine the manual page for bash, and learn what this
>would do. It's over engineered, but I like to avoid vagaries of different
>versions of /bin/sh.
>
>#!/bin/sh
>ARGS=$@
>export ARGS
>
>echo "Executing: checker.sh $ARGS"
>for node in `cat $list`; do
> ssh root@$node "sh checker.sh $ARGS"
>done

I think everyone is missing the point but the OP and me.

To the OP, why don't you write a little sed or perl script to modify a
scratch copy of checker.sh on your local server and loop through your
700 odd servers? Use a local file to hold the arguments, something
like this:

server0 arg1 arg2 arg3
server1 arg1 arg2 arg3
....
server700 arg1 arg2 arg3

All you have to do is edit this file once, or as needed when things
change. If you're smart about it, and a lot of servers have exactly
the same arguments, then so much the better.

Your for loop will read successive lines from this file and parse the
server name, and the args. Your sed or perl script will modify your
scratch copy of checker.sh.

So your for loop ends up executing the ssh call with only the scratch
script and no other arguments.

How's that sound?

joe wrote:
> I am on server "A" and the script, lets call it checker.sh, exists in my
> home directory on server A and is executable and works fine on server A.

Fine.

> I am part of a team that manages over 700 servers. Lets call them
> server 0 to server 699. Often times, I need to run checker.sh against
> all 700 servers. For cases like this, I have another standard script on
> server A that loops through a list of servers and runs checker.sh
> against each one of those servers.

> roughly....

> for node in `cat $list`
> do
> ssh root@$node "sh < checker.sh"
> done

But that line and your description disagree. Here you're running the
"sh" executable on 'node', and you're feeding in checker.sh from 'node'
also. The fact that checker.sh is on 'A' doesn't come into this at all.

You can get rid of the redirect if this is how you're actually running
it.
ssh root@$node "sh checker.sh"
would be equivalent.

If you did want to feed sh the checker.sh on your local host (A) you'd
need to put the redirect outside the quotes.

Here I created a file 'in.sh' that just does a couple of echos. I put
it on my local and remote host. It shows where it is and prints the
argument list.

If we run your example, the remote side is the one run....

$ ssh remote "sh < in.sh"
File from remote host
arguments:

On the other hand this runs the local in.sh...

$ ssh remote "sh" < in.sh
File from local host
arguments:

> This works great...unless I want to add arguments to the script call. I
> don't want to have to edit checker.sh between every run and hard code
> the argument directly into the script. Also makes it tough to write a
> reusable script.

sh compatible shells should take a -s flag. From the Solaris "sh" page:

-s If the -s flag is present or if no arguments
remain, commands are read from the standard
input. Any remaining arguments specify the
positional parameters. Shell output (except
for Special Commands) is written to file
descriptor 2.
So...

$ ssh remote "sh -s one two" < in.sh
Password:
Running from remote host
arguments: one two

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

Darren Dunham wrote:
> joe wrote:
>
>>I am on server "A" and the script, lets call it checker.sh, exists in my
>>home directory on server A and is executable and works fine on server A.
>
>
> Fine.
>
>
>>I am part of a team that manages over 700 servers. Lets call them
>>server 0 to server 699. Often times, I need to run checker.sh against
>>all 700 servers. For cases like this, I have another standard script on
>>server A that loops through a list of servers and runs checker.sh
>>against each one of those servers.
>
>
>>roughly....
>
>
>>for node in `cat $list`
>>do
>> ssh root@$node "sh < checker.sh"
>>done
>
>
> But that line and your description disagree. Here you're running the
> "sh" executable on 'node', and you're feeding in checker.sh from 'node'
> also. The fact that checker.sh is on 'A' doesn't come into this at all.
>
> You can get rid of the redirect if this is how you're actually running
> it.
> ssh root@$node "sh checker.sh"
> would be equivalent.
>
> If you did want to feed sh the checker.sh on your local host (A) you'd
> need to put the redirect outside the quotes.
>
> Here I created a file 'in.sh' that just does a couple of echos. I put
> it on my local and remote host. It shows where it is and prints the
> argument list.
>
> If we run your example, the remote side is the one run....
>
> $ ssh remote "sh < in.sh"
> File from remote host
> arguments:
>
> On the other hand this runs the local in.sh...
>
> $ ssh remote "sh" < in.sh
> File from local host
> arguments:
>
>
>>This works great...unless I want to add arguments to the script call. I
>>don't want to have to edit checker.sh between every run and hard code
>>the argument directly into the script. Also makes it tough to write a
>>reusable script.
>
>
> sh compatible shells should take a -s flag. From the Solaris "sh" page:
>
> -s If the -s flag is present or if no arguments
> remain, commands are read from the standard
> input. Any remaining arguments specify the
> positional parameters. Shell output (except
> for Special Commands) is written to file
> descriptor 2.
> So...
>
> $ ssh remote "sh -s one two" < in.sh
> Password:
> Running from remote host
> arguments: one two
>

Darren,

Thanks much! That works perfectly and I appreciate the guidance.

tb