What is the portable and canonical way to test if variable is empty/undefined in a shell script? It should work in all sh-like shells. What I do now is something like:
if [ -z "$var" ] ; then
...
and for reverse, doing something when variable is not empty/undefined:
if [ -n "$var" ] ; then
...
And while these work for the scripts I write now, I'd like to know a way, that will work in any reasonably compatible sh-like shell, even on some more obscure environment than a Linux PC with GNU userland and bash or dash.
I'm looking for an "expert answer" from someone who is experienced in different shell environments and knows the pitfalls of different ways of doing things, not an opinion like "that should work".
Portable and canonical are two different things.
For portable, the test I see in several autoconf scripts is:
This tests for emptiness, not absence.
Disclaimer: I don't consider myself an expert in shells.
AFAIK, the
test
command and the-z
and-n
flags are part of the POSIX standard, so you should be fine by using them across many platforms.It's important to remember that an empty shell variable is not the same thing as an unset shell variable - though this distinction cannot be made using either form of
[ test ]
. All thattest
can do is report on the value of a variable's expansion - it is parameter expansion that determines that. For example:Again:
With
[ test ]
:Hopefully this drives it home:
If you want to portably determine if a variable is empty this will do it:
I think you could make very good use of the shell's parameter expansion for cases like these and in some cases even kill two birds with one stone (see the first example). This should definitely be portable. What follows is an incomplete copy/paste from the open group's POSIX shell guidelines found here: http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02
${parameter:-word}
unset
ornull
, the expansion of word shall be substituted; otherwise, the value of parameter shall be substituted.${parameter:=word}
unset
ornull
, the expansion of word shall be assigned to parameter. In all cases, the final value of parameter shall be substituted. Only variables, not positional parameters or special parameters, can be assigned in this way.${parameter:?[word]}
unset
ornull
, the expansion of word (or a message indicating it is unset if word is omitted) shall be written to standard error and the shell exits with a non-zero exit status. Otherwise, the value of parameter shall be substituted. An interactive shell need not exit.${parameter:+word}
unset
ornull
,null
shall be substituted; otherwise, the expansion of word shall be substituted.EXAMPLES:
${parameter:-word}
ls
is executed only ifx
isnull
orunset
. (The$( ls)
command substitution notation is explained in Command Substitution.)${x:-$(ls)}
${parameter:=word}
EDIT:
I just noticed Ashish's one-liner, and because it felt kinda cheap just pasting that in, I'd like to do something. So here's a POSIX parameter expansion set-test one-liner:
Well, still cheap, I guess.
EDIT2:
So I just noticed this: "...while these work for the scripts I write now, I'd like to know a way, that will work in any reasonably compatible sh-like shell, even on some more obscure environment than a Linux PC with GNU userland and bash or dash..."
I am sorry I'm not personally an expert, but I first picked up the following method of defining important shell variables from arguments that may or may not have been passed after digging through some fairly expertly written initramfs busybox scripts. It will work as expected pretty much everywhere.
It's kinda beautiful because you only set the variables to the default condition if the user doesn't define them without any extra work to check if they did, really. There are tons of other uses of course, I'm just not smart enough to use them like I should.
EDIT3:
phs was right to specify that his method tests for empty variables not absent ones as was posed in the question. This method can do the same depending on whether the center colon is used. I've copied from the POSIX guidelines below a sort of a crap table to demonstrate this.
The bracket construction
[...]
is part of the POSIX standard, and safe to just about everywhere. So, to test if a variable is empty theif
case used in the question is perfect:As long as you remember than:
Always quote the variables
A non-quoted variable is subject to word splitting, so that if you use
[ -z $STRING ]
(without quotes around$STRING
) and$STRING
contains spaces, or is empty, the shell will see[ -z SEVERAL WORDS ]
or[ -z ]
which are both syntax errors – i.e. not what you want.Always use just one equal sign
An alternative way if testing if a string in a POSIX shell is empty is to use
=
.Note however that you should never use double equal signs (
==
) inside[...]
! (This only works isbash
, or whensh
is a link tobash
– but if run on a different machine wheresh
links to something else, it will not work.) If you want to use the double equal sign, you should also have double brackets[[...]]
(which only works inzsh
,bash
etc., but not plain POSIX shells likedash
).Don't use
&&
or||
inside[...]
It might work in some shells, but it sure won't work in all of them. Instead, for 'and' write
[...] && [...]
or[... -a ...]
. And for 'or' write[...] || [...]
or[... -o ...]
.Ancient stuff
Sometimes, in really ancient shell scripts you'll see stuff like the following, to test for an empty variable. This is still perfectly valid (but looks kind of clunky in my eyes) and I've never encountered a shell that requires this (though, admittedly, my experience is limited outside Linux – maybe there are BSD shells that still need this?)
The prepending of a period is to avoid the bracket construction
[...]
from being confused if$STRING
happen to contain-e
,-o
and other options that[...]
uses. By prepending a period, it is turned into a non-option.I have never seen a shell need this workaround, though. (Dash does certainly not need them.) So it is presumably safe to ignore this.
You don't have to go in if else ladder unless you have big codes running in testing variables
one linner example
Click here For more examples.