Bash – observing different behaviour of echo

bashechoquoting

I observed the below behavior of echo

#!/bin/bash

x=" hello"

echo $x
echo "$x"

Now when I run the above code I get

ronnie@ronnie:~$ bash test.sh
hello
 hello
ronnie@ronnie:~$

So, can someone explain to me why whitespace in first case is not present in output and also points me to the documentation where this behavior is defined.

Best Answer

It is not the echo behavior. It is a bash behavior. When you use echo $x form the bash get the following command to process (treat ␣ as space):

echo␣␣hello

Then this command is tokenized and bash get two tokens: echo and hello thus the output is just hello

When you use the echo "$x" form then the bash has the following at the input of tokenizer:

echo␣"␣hello"

thus it has two tokens echo and ␣hello, so the output is different.

Related Solutions

Bash – Why Does echo [9876543210] Display 1 4 5 6?

The open bracket [ is a special character to the shell; it opens up a pattern matching algorithm that says "match any of the characters inside the brackets". Because you have 4 files named as: 1, 4, 5, and 6 in your current directory, when the characters inside the brackets contain any of those digits, your shell replaces the pattern-match with those filenames. When you instead use echo [ 9876543210 ] you are calling echo with 3 parameters: [, 9876543210, and ].

You should quote your echo statement's parameters to prevent the shell from seeing it as a pattern matching request.

$ echo '[9876543210]'
[9876543210]

(or remove the files named 1, 4, 5, and 6 -- but that's a workaround to demonstrate the behavior, not a fix).

Bash – Why is the behavior of `command 1>file.txt 2>file.txt` different from `command 1>file.txt 2>&1`

You need to know two things:

An open file descriptor known to the application-mode side of a process references an internal kernel object known as a file description, which is an instance of an open file. There can be multiple file descriptions per file, and multiple file descriptors sharing a file description.
The current file position is an attribute of a file description. So if multiple file descriptors map to a single file description, they all share the same current file position, and a change to the file position enacted using one such file descriptor affects all of the other such file descriptors.
Such changes are enacted by processes calling the read()/readv(), write()/writev(), lseek(), and suchlike system calls. The echo command calls write()/writev() of course.

So what happens is this:

command 1>file.txt 2>&1 only creates one file description, because the shell only opens a file once. The shell makes both the standard output and standard error file descriptors map to that single file description. It duplicates standard output onto standard error. So a write via either file descriptor will move the shared current file position: each write goes after the previous write the common file description. And as you can see the results of the echo commands do not overwrite one another.
command 1>file.txt 2>file.txt creates two file descriptions, because the shell opens the same file twice, in response to the two explicit redirections. The standard output and standard error file descriptors map to two different file descriptions, which then in turn map to the same single file. The two file descriptions have entirely independent current file positions, and each write goes immediately the previous write on the same file description. And as you can see the result is that what is written via one can overwrite what is written via the other, in various different ways according to what order you execute the writes in.

Best Answer

Related Solutions

Bash – Why Does echo [9876543210] Display 1 4 5 6?

Bash – Why is the behavior of `command 1>file.txt 2>file.txt` different from `command 1>file.txt 2>&1`

Further reading

Related Question