[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: weird behaviour of quotes in bash variable assignments



On 2020-09-20 18:14, The Wanderer wrote:
On 2020-09-20 at 17:27, Gary Dale wrote:

I have the same bash script on two different Debian/Buster AMD64
servers. However on one it refused to run. I tracked it down quickly
to a variable substitution problem.

The line causing the problem reads: report="/root/clamscan-report"

On one server  echo $report  prints  /root/clamscan-report  while on
the other it prints  "/root/clamscan-report".

Needless to say clamscan can't print to the latter. I fixed it by
removing the quotes on the one server but now the scripts are
different between the two servers, which isn't what I want.
Given the lack of spaces or other potentially-problematic characters in
the path, why not remove them on both servers? Will there potentially be
cases where the path is different, and such characters may be present?

I'm in the habit of always quoting string constants in scripts. It's clearer and avoids potential problems with future edits...



More importantly, I don't understand why it refuses to remove the
quotes.

Where does this behaviour (keeping the quotes) get set?
First up: are you sure it's actually bash (rather than some other shell)
that's running the script in both cases?

Second, can you confirm that bash is the same version on both servers?
As reported by e.g 'bash --version'.

If both of those are confirmed, then it may be worth digging deeper. I'm
a bit reluctant to delve deep into the bash man page looking for
something like that without first ruling out other possibilities.

My first guess would be that one of the two might be using the shell
builtin command 'echo' and the other might be using /bin/echo, but
that's only a guess.

It's the same version of bash, as you would expect since both servers are running the same up-to-date version of Debian/Stable.

The echo command is reporting things accurately. I uncovered the problem by running the script manually and seeing the messages coming up showing that it was looking for a file enclosed in quotes. The other server was running the script without errors.


Reply to: