In concatenating two variables, the system expands the resulting path and returns unexpected results. How do I prevent this?

Question

Question 2.0:

Given the code:

SSLPasswordFilePath="$SSLFilesDir$SSLPasswordFile"

When I run:

"$SSLPasswordFilePath"

I get this unexpected result:

/tmp/ConfigFiles/SSL/Password.txt: line 1: *************redactedsuff*************: command not found

With the comments that I have gotten below (from version 1 of the question) and what I know of bash, I would have expected the following as the return:

/tmp/ConfigFiles/SSL/Password.txt

The variables I reference are, as follows:

SSLFilesDir="/tmp/ConfigFiles/SSL/" 
SSLPasswordFile="Password.txt"

I have found out that I can use echo to get the expected result:

echo "$SSLPasswordFilePath"

But when I try to force that value into the variable (notice "echo" and the "$()")

SSLPasswordFilePath=$(echo "$SSLFilesDir$SSLPasswordFile")

then call the variable by

"$SSLPasswordFilePath"

I still get the long, unexpected result.

As an attempt to bodge it I have tried:

"$SSLPasswordFilePath" | awk '{printf $1}'

But it prints the same unexpected string, so... I am still stuck.

I have poked around the wonderful web and the most prevalent solutions are suggestions on how to edit the PATH variable (Obviously not useful here.) Otherwise, I found:

1. Concatenate two paths But I cannot figure out how to apply it to my situation. The end of the first block in this thread is what is not returning correctly for me. (Export also seems a bit extreme for what I am trying to do: But what do I know?)

2. How can we prevent parameter expansion? on Unix & Linux Is not what I want as it deals with literal interpretations and I want the variables to resolve to just a complete path.

Again, I was able to do the simple "put it in a variable" method before this point and it worked. (Granted, they are all directories so they can't be printed in the same way.)

Thanks for any links/suggestions you all have.

EDIT: I will have several uses of the code. In all but one instance it will be used to set values to a REST API:

sudo fmsadmin -u ${ConsoleUser} -p ${ConsolePassword} certificate import -y "$SSLSignedCertPath" \
    --intermediateCA "$SSSLIntermediatePath" \
    --keyfile "$SSLKeyFilePath" \
    --keyfilepass ${SSLPassword}

For one other instance, I am simply going to get the value out of the file later:

SSLPassword=$(sudo cat ${SSLPasswordFilePath})

Edit2 Artur: I think I don't understand something that you do. I'm newish with bash so I may not know what I am saying when you say I am giving the answer. I understand the parts about string concatenation (you say I got that right.) I don't understand how the execution bit relates.

For starters, I am not in a script but typing it out in the terminal so the idea of ./yourscript.sh: line xx: /tmp/ConfigFiles/SSL/Password.txt: Permission denied coming back to me is still unexpected. The "Line 1" in the unexpected result, is the first and only line of the content of the text file.

My issue is not with "command not found" it's with the stuff that comes after the path in the section, I label "unexpected result". As I understand it: When I concatenate the two strings with the double quotes it should return /tmp/ConfigFile/SSL/Password.txt when I type the code "$SSLPasswordFilePath" into the command line.

Maybe your point is that the execution bit is what is causing the file to be printed like /tmp/ConfigFiles/SSL/Password.txt: line 1: *************redactedsuff*************: command not found? But based on what you show, turning the execution bit off would not give me the return I want when the variable is set and I put "$SSLPasswordFilePath" into the CLI either.

So if the execution bit is what is reading out the file, How do I get it to return only what is literally in the variable when I refer to it like so: "$SSLPasswordFilePath"? Is this simply natural behavior for this case?

Answer 1

I'm having some trouble understanding your exact problem, since you have basically given the answer yourself.

String concatenation

String concatenation in Bash is really simple, since you basically just line up the variables inside double quotes.

So what you have done:

InstallDir="/tmp/ConfigFiles/"
SSLFolder="SSL/"
SSLFilesDir="$InstallDir$SSLFolder"

Is exactly the right way to do it, and will give the result /tmp/ConfigFiles/SSL/, if you call the command echo "$SSLFilesDir" (which expands to echo "/tmp/ConfigFiles/SSL/").

Better readability

However, I prefer using curly braces for concatenated variables, since this increases readability in scripts.

So I would personally use:

InstallDir="/tmp/ConfigFiles/"
SSLFolder="SSL/"
SSLFilesDir="${InstallDir}${SSLFolder}"

This gives exactly the same result, but is easier to read inside the script.

Working with variables

If you don't need to assign the concatenated string to a new variable, you can just use the commands, so for instance you could do:

ls "${InstallDir}${SSLFolder}"

To run the command ls /tmp/ConfigFiles/SSL/, or:

cat "${InstallDir}${SSLFolder}${SSLPasswordFile}"

To run the command cat /tmp/ConfigFiles/SSL/Password.txt.

Why you get that specific error message

I can tell you one more thing: You file /tmp/ConfigFiles/SSL/Password.txt has the execution attribute set. How do I know this?

Because Bash is successfully running it as a command. Try and run:

chmod -x /tmp/ConfigFiles/SSL/Password.txt

And now run your script again. This time the error message will be different, and you'll instead get:

./yourscript.sh: line xx: /tmp/ConfigFiles/SSL/Password.txt: Permission denied

Or if you run from the command line:

-bash: /tmp/ConfigFiles/SSL/Password.txt: Permission denied

This is because you still try to run it as a command, but now the file (which Bash previously thought was a script) doesn't have the execution attribute, and the command fails.

What you're doing is the total equivalent of running /tmp/ConfigFiles/SSL/Password.txt from the command line - which will give a command not found error, since it isn't a script.

Final word

How do I get it to return only what is literally in the variable when I refer to it like so: "$SSLPasswordFilePath"? Is this simply natural behavior for this case?

If you would like Bash to do this, you fork the code and create your own brand of Bash which works like you want it to. What you describe is not how Bash works, and you can't force it to work in any other way, except if you create your own version. To display what's in the variable, you use echo "$SSLPasswordFilePath".

Answer 2

Use something like

echo "$SSLFilesDir$SSLPasswordFile"

or

NewVar="$SSLFilesDir$SSLPasswordFile"
echo "$Newvar"