Bash Variable Assignment Not Working Expected

Bash variable assignment not working expected

This line is OK - it assigns the value 0 to the variable status:

status=0

This is wrong:

$status=1

By putting a $ in front of the variable name you are dereferencing it, i.e. getting its value, which in this case is 0. In other words, bash is expanding what you wrote to:

0=1

Which makes no sense, hence the error.

If your intent is to reassign a new value 1 to the status variable, then just do it the same as the original assignment:

status=1

Prefixing variable assignment doesn't work with echo

The variable will be passed in the environment of the command following it, not when the command is being evaluated (expanded). Any variable expansion will be done earlier by shell.

$ V=1 env | grep V=
V=1

To get it working:

$ V=1; echo $V
1

Bash variable assignment strange behaviour

Some commands might need 2>&1 at the end to get any output:

MSG=$(java -version 2>&1)

It sends any standard error(2) to wherever standard output(1) is redirected.

Shell script (assign to variable) not working

VARIABLE is set in the process that runs the script, not the process which called the script. If you want to set it in your current environment, you need to source the file instead.

. script_01.sh "file"

variable in bash script not working as expected

The problem was that the script had Windows style line breaks (I used notepad). After I used Nano the write the script it was solved.

Thanks for the answers!

Linux shell bug? Variable assignment in pipe does not work

common issue which is caused because you're piping into the while, which is therefore run in a subshell, which can't pass environment variables back to its parent. I'm guessing that "unix" is different in this regard as you're running a different shell there (ksh?)

piping to the while loop may not be required. could you use this idiom instead?

for item in /tmp/$$.*; do
    ....
done

If you must use a subshell, then you'll have to do something external to the processes like:

touch /tmp/file_found

Why does a space in a variable assignment give an error in Bash?

It's not a convention in bash (or, more generally, POSIX-family shells).

As for "why", that's because the various ways of doing it wrong all have valid meanings as commands. If you made NUM2 = 4 an assignment, then you couldn't pass = as a literal argument without quoting it. Consequently, any such change would be backwards-incompatible, rather than being placed in undefined space (where extensions to the POSIX sh standard need to live to avoid constituting violations of that standard).

NUM2= 4 # runs "4" as a command, with the environment variable NUM2 set to an empty string
NUM2 =4 # runs "NUM2" as a command, with "=4" as its argument
NUM2 = 4 # runs "NUM2" as a command, with "=" as its first argument, and "4" as another

Variable assignment in command substitution

Here's man bash:

SIMPLE COMMAND EXPANSION
   When a simple command is executed, the shell performs the fol‐
   lowing expansions, assignments, and redirections, from left to
   right.

   1.     The  words  that  the  parser  has  marked  as variable
          assignments (those  preceding  the  command  name)  and
          redirections are saved for later processing.

   2.     The words that are not variable assignments or redirec‐
          tions are expanded.  If any words remain  after  expan‐
          sion,  the  first  word  is taken to be the name of the
          command and the remaining words are the arguments.
   [...]

In your case, the simple command has a single word $(echo var=foo).

Since there are no words marked as variable assignments (because this word is instead a command substitution), step 1 doesn't apply.

We then move on to step 2, where the word $(echo var=foo) is expanded into var=foo. We don't go back to the first step, we just do what step 2 says: "take the first word as the name of the command".

This is why var=foo is executed as a command instead of being interpreted as an assignment.

---

Related Topics