Bash – Check if a file exists on a remote machine with spaces in the filename and/or path

bashscriptingstring

I have a simple bash script; I basically want to make sure that the file exists on a remote machine. I've found numerous examples of how to do this, but the missing component is how to do this with spaces in the path and/or filename being evaluated.

#!/bin/bash

HOST=server.local
DIR=/foo/bar
FILE="Foo Bar File With Spaces"


if ssh $HOST [[ -f ${DIR}/${FILE} ]]
then
   echo "The file exists"
else
   echo "The file doesn't exist."
fi

So, it fails. It gets me a syntax error in conditional expression. However, if I change the FILE variable to say:

FILE="Foo\ Bar\ File\ With\ Spaces"

The script works (it finds the file since it's there).

I have tried the following variations to my conditional expression:

if ssh $HOST [[ -f "${DIR}/${FILE}" ]]

and

if ssh $HOST [[ -f "${DIR}"/"${FILE}" ]]

Neither of which work; I know that I am missing something simple. Can someone please point me in the right direction?

Best Answer

Add an extra pair of quotes so there's one for the local shell and one for the remote shell that ssh runs.

$ dir=/tmp; file="foo bar"; 
$ ssh somewhere ls -l "'$dir/$file'"
-rw-r--r-- 1 foo foo 4194304 Oct 19 18:05 /tmp/foo bar
$ ssh somewhere [[ -f  "'$dir/$file'" ]] ; echo $?
0

You want the double-quotes on the outside so that the local shell expands the variables before the ssh command runs. With a single-quote on the inside, the remote shell won't expand special characters further.

Unless the file name contains single-quotes, that is. In which case you'll run into trouble.

To work around that, you'll need something that adds the necessary escapes to the string. Some systems have printf "%q", new versions of Bash have the ${var@Q} expansion which should do something similar similar.

$ dir=/tmp; file="\$foo' bar"
$ fullpath="$(printf "%q" "$dir/$file")"
$ ssh somewhere ls -l "$fullpath"
-rw-r--r-- 1 foo foo 0 Oct 19 18:45 /tmp/$foo' bar

Related Solutions

Bash – Checking and changing file permission with script

It's weird that you're using sudo to change the permissions on the file, even though it's in your home directory. Does the file belong to you? chmod u+w only gives write permission to the owner of the file. If you are the owner, you don't need sudo. If you aren't the owner, you do need sudo, but chmod u+w only gives the owner write permission, it doesn't grant you permission to write to the file. So after running chmod u+w, the file is still not writable by you, which is what [ -w … ] tests.

Run ls -l ~/scripts/text.txt to check the ownership and permissions on the file.

Aside from this, always put double quotes around variable substitutions. (Or you can learn all the rules and make your script hard to maintain by people who don't know all the rules.) Annoyingly, $file in shell syntax doesn't mean “take the value of the variable file”, it means “take the value of the variable file, parse it as a list of wildcard patterns, and replace each pattern by the list of matching files if there are matching files”. This extra stuff is turned off if the substitution happens inside double quotes: "$file" means “take the value of the variable file”.

Also, you don't need all these braces.

if [ ! -w "$file" ]
then
  sudo chmod u+w "$file" && echo "The file is now writable"
elif [ -w "$file" ]
then
  echo "The file is already writable"
fi

Since [ -w "$file" ] is the negation of [ ! -w "$file" ], the elif test will always succeed if it is reached. (Unless there's a race condition, in which case the elif test that tests the same condition again may return a different result, which is bad.) So you can and should simplify this to

if [ ! -w "$file" ]
then
  sudo chmod u+w "$file" && echo "The file is now writable"
else
  echo "The file is already writable"
fi

Bash – Wait for key in shell script that may get piped to /bin/bash

This is really easy, actually, First, you need to set aside your stdin in some remembered descriptor:

exec 9<&0

There. You've made a copy. Now, let's pipe our commands at our shell.

echo 'echo foo; read <&9; echo bar' | bash

...well, that was easy. Of course, we're not really done yet. We should clean up.

exec 9<&-

Ok, now we're done.

But we can avoid the cleanup if we just group our commands a little...

{ echo 'echo foo; read <&9; echo bar' | bash; } 9<&0

The descriptor only survives as long as its assigned compound command does in that case.

Best Answer

Related Solutions

Bash – Checking and changing file permission with script

Bash – Wait for key in shell script that may get piped to /bin/bash

Related Question