This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 845927 - test -n always returns 0 if evaluating variable
test -n always returns 0 if evaluating variable
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: coreutils (Show other bugs)
5.8
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Ondrej Vasik
qe-baseos-daemons
:
Depends On: 845925
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-06 03:16 EDT by Martin Kyral
Modified: 2012-08-06 03:30 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 845925
Environment:
Last Closed: 2012-08-06 03:30:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Martin Kyral 2012-08-06 03:16:22 EDT
+++ This bug was initially created as a clone of Bug #845925 +++

Description of problem:
According to the man page, "test -n STRING" returns true (0) if the STRING's length is non-zero and that it equivalent to "test STRING" (and contrary to "test -z STRING").

Version-Release number of selected component (if applicable):
coreutils-5.97-34.el5

How reproducible:
Always


Steps to Reproduce:
1. VAR=''
2. test -n $VAR ; echo $?
3. test $VAR ; echo $?

  
Actual results:
In step 2, the output is 0 (true in shell semantics).


Expected results:
In step 2, the output is 0 (false in shell semantics).

Additional info:
"test -n $VAR" returns 0 on both empty and non-empty string $VAR value. "test $VAR" and "test -z $VAR" give the expected values, ie. 0,1 on non-empty and 1,0 on empty $VAR values. Also, "test -n" gives correct output if a direct value is given.
Comment 1 Martin Kyral 2012-08-06 03:24:07 EDT
Expected results:
In step 2, the output is 1 (false in shell semantics).

Sorry for the typo..
Comment 2 Kamil Dudka 2012-08-06 03:30:04 EDT
see bug #845925 comment #2

Note You need to log in before you can comment on or make changes to this bug.