test with -n or -z not working

[Steve Givens]

I'm porting a script that runs fine on Sun and AIX, however fails on HP with the message:

"sh: 1: Parameter not set."

The code that is failing is:
if [[ -n ${1} ]] ;
then
...
else
...
fi

I've replaced the if statement with the following to get it to work:

if [ $# -eq 1 ] ;
then ...

Can someone explain what's going on?

Thanks,

Steve

[Peter Godron]

Steve,
have you tried:
#!/usr/bin/sh
echo $1
if [[ -n ${1} ]]
then
echo string found
else
echo emptry string
fi

Ensure spaces between -n and bracket and } and bracket.
It will test for the presence of a parameter

[Dennis Handly]

It appears you have used set -u to make all references to undefined variables as errors. There is nothing under -u that says you can use [[ -n ]] on them.

So you need to use the following instead:
if [[ -n ${1-} ]]; then ...

The "-" says to set it to null if it is not set.

[Jean-Yves Picard]

Hello,

the code tested with double brackets worked.
> cat test-2B.ksh
if [[ -n ${1} ]]
then
echo true
else
echo false
fi
> sh test-2B.ksh xxx
true
> sh test-2B.ksh
false


however if you use only one bracket, it will not.
> cat test.ksh
if [ -n ${1} ]
then
echo vrai
else
echo faux
fi
> sh test.ksh xxx
vrai
> sh test.ksh
test.ksh: test: Specify a parameter with this command.
faux
>

it is quite simple to understand, when ${1} resolve to nothing ($1 is not set)
the test is
if [ -n ]
and -n argument of test, expect a string.

solution is to quote the string : "${1}"

I can't see why it work on AIX/SUN, which shell are you using ? ksh ? bash ? csh ?

Jean-Yves Picard

[Steve Givens]

I've tried both sh and ksh. Same results. That is also true for using double quotes around ${1}. I'll try a couple of the other suggestions and get back to you all.

Thanks.

[Steve Givens]

Peter, your right. I found the "set -u" command in my .profile. That was set up that way before my time. What are the implications of taking that out? This is the oracle account in case that would make any difference.

[Dennis Handly · Accepted solution]

>Peter, you're right. I found the "set -u" command in my .profile.

(I thought I said that. ;-)

>What are the implications of taking that out?

Basically you don't have checking for poorly written shell scripts. As I mentioned, you can replace ${1} by ${1-} and you won't get that error.

[Bill Hassell]

set -u is one of those "oops" preventors. The default is for the shell to ignore undefined variables which could be disastrous in a root script. Consider the following snippet:

TMP=tmp/some_dir
rm -rf /$TEMP

Because of the spelling error, $TEMP was used in the rm command and with set +u in force, the rm command looks like this:

rm -rf /

Having made a similar (but less disastrous) spelling error that deleted files and directories on more than 200 computers, using set -u is mandatory in all my scripts. Putting it in /etc/profile or .profile is also a good idea.

One of the classic shell tasks is to be able to test 3 separate conditions:

1. not defined at all
2. defined with a null value
3. defined with a value

One technique is to assign a special value when the variable is not defined:

VAL=${VAL:-IamNOTdefined}

Now, VAL is either undefined and can be tested with "$VAL" = "IamNOTdefined" or null and can be tested with "$VAL". You can even retain the unset value later in the script like this:

VAL=${VAL:-IamNOTdefined}

... code ...

[ "$VAL" = "IamNOTdefined" ] && unset VAL