[SOLVED] #!bin/sh script: variable in remote command

RagingRaven · 04-04-2017, 04:21 AM

I'm writing a script where I'm trying to place a variable in a remote command, but it's not working for some reason.

The part i'm having an issue with:

Code:

#!/bin/sh

#get root variables
. /root/.bashrc

remoteFileToCheck="/some/folder/on/remote/machine/file name with space.xls"

remoteAccessTime=`ssh <MyRemoteServerName> 'stat -c "%X" "${remoteFileToCheck}"'`

Where <MyRemoteServerName> is the hostname of my server.

The error on the last line is: cannot stat '': No such file or directory

When I replace ${remoteFileToCheck} with /some/folder/on/remote/machine/file name with space.xls it works just fine.
When I echo ${remoteFileToCheck} I get the correct filepath and name.

Things I've tried:
1. replace the backticks with $()
2. remove the single quotes (') around stat, but then it seems to split up the filename on the space
3. do `stat -c '%X' "${remoteFileToCheck}"` with remoteFileToCheck being a local file and this works fine.

So it appears to be a quoting problem, but I can't seem to find the correct way to quote in order to have it work.

Turbocapitalist · 04-04-2017, 04:34 AM

Yes, it's a quoting problem. The outermost quotes must be double quotes so that the variables are processed by the shell. Then as you work your way through you'll have to use either single quotes or escaped double quotes.

As a style change, there are a lot of advantages to $( ) for command substitution instead of backticks.

Last but not least I'd recommend *not* doing this as root.

r3sistance · 04-04-2017, 04:38 AM

Consider the differences here...

Code:

# myvar="test"
# echo $myvar
test
# `echo $myvar`
# 'echo $myvar'
bash: echo $myvar: command not found...
# "echo $myvar"
bash: echo test: command not found...

In this case, what you are probably after is $()

Code:

# myvar2=$(echo $myvar)
# echo $myvar2
test

RagingRaven · 04-04-2017, 07:12 AM

First off, thank you for your replies.

Quote:

Last but not least I'd recommend *not* doing this as root.

I'm not actually executing the script as root, but as a sudo user, I just need the varables of the root user for some other part of the actual script.
Also the connection to the other machine is using a vpn, so there shouldn't be too much of an issue anyway.

Lastly, I now changed the line to:

Code:

$(ssh <MyRemoteServerName> "stat -c '%X' '${remoteFileToCheck}'")

And it works!

So thanks again.

Turbocapitalist · 04-04-2017, 07:51 AM

Quote:

Originally Posted by RagingRaven

I'm not actually executing the script as root, but as a sudo user, I just need the varables of the root user for some other part of the actual script.

Glad it runs. I'd recommend copying the variables you need from the root directory and inserting them into the beginning of your script. That way it won't have to run as root. If you add the following line to your script, it will certainly output "root" if I read your script and guess at the context correctly:

Code:

whoami

sudo is useful enough that I'd recommend the following detailed presentation:

He has a useful and concise book as well, if you enjoy paper better: sudo Mastery

With either one, you'll learn the more powerful capabilities and how to avoid pitfalls.

RagingRaven · 04-05-2017, 03:46 AM

Thank you for the read turbo, I already knew most of the things said in the presentation though.

The reason I'm using the sudo way, is because I need to run some programs with root privileges which use the variables of root.
Yes I could copy the variables to the sudo user, but I would have to do this each time a change is made to the root variables.

Further more there are some files on the remote machine which are only writable by root, yes I could add a user to a group with the right privileges, but I would also have to do this on the remote machine and keeping everything synced would be pretty cumbersome.

As said the connection between both machines is using a VPN, so the security risks should be minimal.

So it's more of a risk vs time assessment.

That said, it's always good to learn more and there were a few things in there I didn't know yet, so thanks!