Return to Answer

In ordinary use, i.e. when you're just expanding variables, an unset variable is treated as empty in all Bourne/POSIX-style shells. The exception is when set -o unset a.k.a. set -u is in effect, in which case the shell will raise an error if you try to access the value of an unset variable (see godlygeek's answer).

There are ways to test whether a variable is unset or empty; for example, the construct ${foo-bar} expands to the value of foo if it is set (even if it's empty) and to bar if foo is unset;
${foo:-bar} (with an extra colon) treats an empty variable as if it were unset. Other similar expansion constructs ${foo+bar}, ${foo?bar}, ${foo=bar} behave similarly. An empty variable will also appear in the output of set and export (if exported), among other differences. You'll only run into these differences if you want to.

However, there is a different reason to always initialize variables: how do you know that the variable is really unset? The caller may have defined a similar variable for its own purposes. If the caller is some other part of the same script, then your use in a function will overwrite the caller's, unless you declare the variable as local (which is only possible in ksh/bash/zsh), so variable name clashes are a problem anyway. But it can also happen that the variable is present in the environment, because someone else picked the same variable name as you. There is a sort of convention to use lowercase names for shell variables and uppercase names for environment variables, but it doesn't solve all clashes and it isn't followed universally.

$ export DIM=1 SUM=42
$ bash
Oh, green world, 1don't desert me now...

In ordinary use, i.e. when you're just expanding variables, an unset variable is treated as empty in all Bourne/POSIX-style shells. The exception is when set -o unset a.k.a. set -u is in effect, in which case the shell will raise an error if you try to access the value of an unset variable (see godlygeek's answer).

There are ways to test whether a variable is unset or empty; for example, the construct ${foo-bar} expands to the value of foo if it is set (even if it's empty) and to bar if foo is unset;
${foo:-bar} (with an extra colon) treats an empty variable as if it were unset. Other similar expansion constructs ${foo+bar}, ${foo?bar}, ${foo=bar} behave similarly. An empty variable will also appear in the output of set and export (if exported), among other differences. You'll only run into these differences if you want to.

However, there is a different reason to always initialize variables: how do you know that the variable is really unset? The caller may have defined a similar variable for its own purposes. If the caller is some other part of the same script, then your use in a function will overwrite the caller's, unless you declare the variable as local (which is only possible in ksh/bash/zsh), so variable name clashes are a problem anyway. But it can also happen that the variable is present in the environment, because someone else picked the same variable name as you. There is a sort of convention to use lowercase names for shell variables and uppercase names for environment variables, but it doesn't solve all clashes and it isn't followed universally.

$ export DIM=1 SUM=42
$ bash
Oh, green world, 1don't desert me now...

In ordinary use, i.e. when you're just expanding variables, an unset variable is treated as empty in all Bourne/POSIX-style shells. The exception is when set -o unset a.k.a. set -u is in effect, in which case the shell will raise an error if you try to access the value of an unset variable (see godlygeek's answer).

There are ways to test whether a variable is unset or empty; for example, the construct ${foo-bar} expands to the value of foo if it is set (even if it's empty) and to bar if foo is unset;
${foo:-bar} (with an extra colon) treats an empty variable as if it were unset. Other similar expansion constructs ${foo+bar}, ${foo?bar}, ${foo=bar} behave similarly. An empty variable will also appear in the output of set and export (if exported), among other differences. You'll only run into these differences if you want to.

However, there is a different reason to always initialize variables: how do you know that the variable is really unset? The caller may have defined a similar variable for its own purposes. If the caller is some other part of the same script, then your use in a function will overwrite the caller's, unless you declare the variable as local (which is only possible in ksh/bash/zsh), so variable name clashes are a problem anyway. But it can also happen that the variable is present in the environment, because someone else picked the same variable name as you. There is a sort of convention to use lowercase names for shell variables and uppercase names for environment variables, but it doesn't solve all clashes and it isn't followed universally.

$ export DIM=1 SUM=42
$ bash
Oh, green world, 1don't desert me now...

In ordinary use, i.e. when you're just expanding variables, an unset variable is treated as empty in all Bourne/POSIX-style shells. The exception is when set -o unset a.k.a. set -u is in effect, in which case the shell will raise an error if you try to access the value of an unset variable (see godlygeek's answer).

There are ways to test whether a variable is unset or empty; for example, the construct ${foo-bar} expands to the value of foo if it is set (even if it's empty) and to bar if foo is unset;
${foo:-bar} (with an extra colon) treats an empty variable as if it were unset. Other similar expansion constructs ${foo+bar}, ${foo?bar}, ${foo=bar} behave similarly. An empty variable will also appear in the output of set and export (if exported), among other differences. You'll only run into these differences if you want to.

However, there is a different reason to always initialize variables: how do you know that the variable is really unset? The caller may have defined a similar variable for its own purposes. If the caller is some other part of the same script, then your use in a function will overwrite the caller's, unless you declare the variable as local (which is only possible in ksh/bash/zsh), so variable name clashes are a problem anyway. But it can also happen that the variable is present in the environment, because someone else picked the same variable name as you. There is a sort of convention to use lowercase names for shell variables and uppercase names for environment variables, but it doesn't solve all clashes and it isn't followed universally.

$ export DIM=1 SUM=42
$ bash
Oh, green world, 1don't desert me now...

In ordinary use, i.e. when you're just expanding variables, an unset variable is treated as empty in all Bourne/POSIX-style shells. The exception is when set -o unset a.k.a. set -u is in effect, in which case the shell will raise an error if you try to access the value of an unset variable (see godlygeek's answer).

There are ways to test whether a variable is unset or empty; for example, the construct ${foo-bar} expands to the value of foo if it is set (even if it's empty) and to bar if foo is unset; ${foo:-bar}(with an extra column) treats an empty variable as if it was unset. Other similar expansion constructs${foo+bar}, ${foo?bar}, ${foo=bar}$ behave similarly. An empty variable will also appear in the output of set and export (if exported), among other differences. You'll only run into these differences if you want to.

However, there is a different reason to always initialize variables: how do you know that the variable is really unset? The caller may have defined a similar variable for its own purposes. If the caller is some other part of the same script, then your use in a function will overwrite the caller's, unless you declare the variable as local (which is only possible in ksh/bash/zsh), so variable name clashes are a problem anyway. But it can also happen that the variable is present in the environment, because someone else picked the same variable name as you. There is a sort of convention to use lowercase names for shell variables and uppercase names for environment variables, but it doesn't solve all clashes and it isn't followed universally.

$ export DIM=1 SUM=42
$ bash
Oh, green world, 1don't desert me now...

In ordinary use, i.e. when you're just expanding variables, an unset variable is treated as empty in all Bourne/POSIX-style shells. The exception is when set -o unset a.k.a. set -u is in effect, in which case the shell will raise an error if you try to access the value of an unset variable (see godlygeek's answer).

There are ways to test whether a variable is unset or empty; for example, the construct ${foo-bar} expands to the value of foo if it is set (even if it's empty) and to bar if foo is unset;
${foo:-bar} (with an extra colon) treats an empty variable as if it were unset. Other similar expansion constructs ${foo+bar}, ${foo?bar}, ${foo=bar} behave similarly. An empty variable will also appear in the output of set and export (if exported), among other differences. You'll only run into these differences if you want to.

However, there is a different reason to always initialize variables: how do you know that the variable is really unset? The caller may have defined a similar variable for its own purposes. If the caller is some other part of the same script, then your use in a function will overwrite the caller's, unless you declare the variable as local (which is only possible in ksh/bash/zsh), so variable name clashes are a problem anyway. But it can also happen that the variable is present in the environment, because someone else picked the same variable name as you. There is a sort of convention to use lowercase names for shell variables and uppercase names for environment variables, but it doesn't solve all clashes and it isn't followed universally.

$ export DIM=1 SUM=42
$ bash
Oh, green world, 1don't desert me now...