Bash script doesn't set environment variable correctly

Question

I am trying to set environment variables in a bash script to be read by another bash script, but they are not getting set properly. I am on Ubuntu 20.04.

setting environment variables in a script:

setenv.env
  export DB1_IMAGE="postgres:latest"

run it: . setenv.env

test it:  echo $DB1_IMAGE
result: postgres:latest

script to test the environment variable value:

test.sh
#!/bin/bash
echo $DB1_IMAGE
if [[ $DB1_IMAGE ==  "postgres:latest" ]]
then
  echo "equals"
else
  echo "not equals"
fi

run the test script: . test.sh

result:  
     postgres:latest
     not equals

now set the environment variable with command line:

export DB1_IMAGE="postgres:latest"

now run the test script again: . test.sh

result:  
     postgres:latest
     equals

Summary: When an environment variable is set with a bash script, that value will fail an equals comparison in another bash script. When that same environment variable is set with a command line, it passes the equals test. I can't explain why this is. I feel like I'm missing something obvious. How could the == test fail? Are there unprintable characters being inserted somehow? Please help..

Possible duplicate: https://stackoverflow.com/a/52818152/596285 — BMitch, Jun 13 '21 at 20:46
Maybe I shouldn't have listed this a a docker problem. Sorry for the mis-understanding. It manifested itself as docker problem, but I've traced it to the root cause of a bash script problem. I should have explained myself better. This should be a bash script problem. It is in fact reproducible from the .env file and the test script file. It would only take anyone a few minutes to re-create it. — Sam Melehy, Jun 13 '21 at 22:53
Hi @SamMelehy - do you get the same behaviour with single `[` rather than doubles `[[` - see https://tldp.org/LDP/abs/html/comparison-ops.html#SCOMPARISON1 — Mr R, Jun 13 '21 at 23:42
Make sure `setenv.env` does not have DOS-style `\r\n` line endings. You won't be able to see the `\r` with `echo` but the extra character will make the comparison not equal. — glenn jackman, Jun 13 '21 at 23:46
@glennjackman I suspected that, but i'm not sure how to tell. I was originally using a windows based editor Komodo, with remote ftp connection to the source files on the Ubuntu server. I then tried to recreate the file with SSH and nano. Same result. How can I tell definitively if there are dos-style line breaks? — Sam Melehy, Jun 13 '21 at 23:49
@glennjackman You're right. I ran $ file setenv.env and the result is setenv.env: ASCII text, with CRLF line terminators. It's DOS. Thank you! — Sam Melehy, Jun 13 '21 at 23:53
If you do `cat -A setenv.env` then the carriage returns should show up something like `^M` — glenn jackman, Jun 14 '21 at 00:02

score 0 · Answer 1 · answered Jun 14 '21 at 00:14

0

Thanks to @glennjackman, the cause of this was that the bash script file (setenv.env) was DOS-formatted as opposed to UNIX-formatted. This means it had \r\n line breaks, which cause hidden characters to be inserted into the environment variables. The fix is to run dos2unix on the file (sudo apt install dos2unix)

answered Jun 14 '21 at 00:14

Sam Melehy

85
1
9

Please don't add "thank you" as an answer. Instead, **[accept the answer](https://stackoverflow.com/help/accepted-answer)** that you found most helpful. - [From Review](/review/low-quality-posts/29330454) – komeil majidi Jul 05 '21 at 07:06
2

@komeilmajidi: They can't. The answer they found most useful was left as a comment, not an answer, so they can't accept it. It's pretty standard practice for OPs to reiterate an answer from the comment in order to confirm that their question was resolved, and to allow them to mark the answer as accepted. (Personally, I usually submit these answers as community wiki's and give the original commenter the opportunity to submit their own answer, but that's obviously not required.) – Jeremy Caney Jul 05 '21 at 23:38
@JeremyCaney the question has been closed as dupe, so I'm not sure this apply here – Aserre Jul 09 '21 at 08:02

Bash script doesn't set environment variable correctly

1 Answers1