test command gives no output (true or false)

[Mark Vollmers]

I've got a wierd problem that probably has a real simple solution, but I can't find it. I've got a search script will look at input entered (three fields) and then run a grep command depending on what was entered. I have set up a test command to determine if the entered field is blank (non-zero length) or not. I have if statements defined for the test:

if [ -n part ]
then command
echo "true"
else command
echo "false"

The oputput to the screen from the echo commands always shows that it calls the test false, even if part is blank or not.
I put it straight into a prompt:

example=bob
test -n "$example"

and I don't get a 0 or a 1, it just gives me a new prompt. Using:

test 7=7

does the same thing. Just typing test (no arguments) also does the same thing. What am I doing wrong? Why won't the test command give me any output? Help, as always, is greatly appreciated. Thnanks!

Mark

[Prashun Gupta]

are you using proper shell to execute
/bin/ksh
Prashun

[Mark Vollmers]

the script calls the bourne shell (#!/bin/sh), and the prompt is also using bourne. I did not think that the test command was shell-specific. Am I wrong?

mark

[Curtis Larson]

many shells have a test function that is built-in, which does make the test "command" shell specific, though usually this is just difference in which things can be tested by which syntax.

test doesn't not generate any output. What it does is return an exit status. 0 is true and non-zero is false. What you need to be looking at is the return code of your test, i.e. $?

[Mark Vollmers]

I thought that the exit status would be returned to the screen (it would show a 0 or 1, depending on if it was true). For the script, I wanted to assign the exit status to a variable. Maybe I can't do this? I have attached the script, so you can see what I was wanting to do. It is probably not the best way to do it, but it made sense in my mind when I wrote it. Thanks.

[James R. Ferguson · Accepted solution]

Hi Mark:

A couple of comments.

Get in the habit of putting quotation marks around your variables when you do 'test's:

if [ -z "X" ]
then
echo "empty variable"
else
echo "the value is $X"
fi

When evaluating an expression, 'test' returns a zero (true) exit status if the expression is "true"; otherwise, a nonzero (false) exit status. You can echo this to stdout by doing:

# echo $?

...as:

# X=
# [ -z "$X" ];echo $?

...JRF...

[James R. Ferguson]

Hi again:

I forgot to add -- if you want to capture an exit status (as for instance from a 'test') and reference it later, all you need to is this:

# [ -z "$X" ]
# RC=$?
# echo "Ready to see the ReturnValue?"
# read anything
# echo "The test returned $RC"

That is, assign the variable $? to one of your choice immediately after the statement you're interesting in interrogating.

...JRF...

[Mark Vollmers]

Thanks for the help so far. I've already cleaned up the script some, as advised. I still have a question about the test command, though. Now that I can see the exit status, I tested it at the prompt.

bob=seven
test -n "$bob" ( I also tried "bob" )
echo $? gives an output of 0

How can the variable be assigned a value but still have a zero length? (using the -z option is true) Echo "$bob" gives an output of seven, so it should be filled. This doesn't make any sense to me, but maybe I have it all screwed up in my head. I don't know. Thanks.

mark

[Bill Hassell]

A couple of notes:

If you are running HP-UX 10.xx or higher then you are not using the Bourne shell, it's the POSIX shell. /usr/bin/sh is the POSIX shell and is virtually identical to ksh. Bourne shell is located in /usr/old/bin if you really want it. Also note that there is no /bin directory--hasn't been since 10.xx was released about 7 years ago. The /bin directory is /usr/bin (just like Solaris) but for old code and scripts, a symbolic link is present (see man tlinstall).

-----------

Always start every script with the desired interpreter. The first line of every script should be:

#!/usr/bin/sh

(or /usr/bin/ksh or whatever the script uses).

----------

A variable can be undefined or defined but with no value (null), or defined with a value which can be a zero length string or a simple string/value. Each is a defined state and testing for each state can be tricky. Here are examples:

X=
which defines the variable with no value

X=""
which defines X with a zero length value

X="Y"
which defines X with a value of "Y"

I don't know of a way to see the difference between X= or X="" or X='' which are all null or zero length values.

I always code scripts with set -u which means undefined variables will cause an error exit when tested or used on the right side of an assignment. Therefore, to test for an undefined variable I must assign a default value if it isn't already defined like this:

UNSET=IamNOTset
DT=${DT:-$UNSET}
VUE=${VUE:-$UNSET}
TERM=${TERM:-$UNSET}
DISPLAY=${DISPLAY:-$UNSET}
SESSIONTYPE=${SESSIONTYPE:-$UNSET}

To see if the variable is not defined, just see if the variable is equal to "$UNSET" Once tested, you can restore the original state with something like this:

[ $DT = $UNSET ] && unset DT
[ $VUE = $UNSET ] && unset VUE
[ $TERM = $UNSET ] && unset TERM
[ $DISPLAY = $UNSET ] && unset DISPLAY
[ $SESSIONTYPE = $UNSET ] && unset SESSIONTYPE

To test for zero length, use test -n or -z depending on which true exit you want.

[Bill Thorsteinson]

test -n does not return the length of the string. It
returns 0 (true) if the sting is not empty, and 1 (false)
if the string is empty. Unbound variables may give
different results depending on quoting.

You can force the result for unbound variables with the
syntax test -n ${var:-''} or test -n "${var:-''}" even if
set -u has been done. You may need this when using
variables from the environment as they may not be set.

Syntax to check for an undefined variable is:
test ${HOME:-'x'} = ${HOME:-''}

You can force use of the standalone test command with
/usr/bin/test instead of test or [ ]. I always rely on the
shell built-in.

[Mark Vollmers]

Thank you to everyone for helping me out. It was a combination of bad scripting and bad variable definition. I've finally got everything fixed (for this part, at least). James- thanks for the scripting help. It pays to write clean code. Bill- thanks for clearing up the shell thing. I never knew that was how it was set up. I really appreciate all the help.

Mark