Bug 57230 - [ -n <string> ] does not behave correctly for undeclared variables
[ -n <string> ] does not behave correctly for undeclared variables
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-12-07 09:57 EST by Paul W. Frields
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-12-07 09:57:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul W. Frields 2001-12-07 09:57:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)

Description of problem:
According to bash-2.05 documentation, the following conditional 
expressions are equivalent:

    [ -n $FOO ]     # string is not null
    [ $FOO ]        # string exists

However, they evaluate differently.  For instance, I use a *text* login 
for RHL 7.2 -- no GUI -- and at a command prompt one has no $DISPLAY 
variable set.  (No GUI = no DISPLAY.)  This happens regardless of the 
variable name, and regardless of whether the variable has been explicitly 
declared, provided the variable is actually null.  (I.e. variables that 
are not declared are null -- cf. "Learning the bash Shell," Newham et al., 
2nd ed. O'Reilly, p. 65; and bash man page, section entitled "PARAMETERS.")


Version-Release number of selected component (if applicable):
2.05-8

How reproducible:
Always

Steps to Reproduce:
1. Choose an unset variable, for instance FOO.
2. Execute the following:
   [ -n $FOO ] && echo "FOO is not null"
   [ $FOO ] && echo "FOO is not null"
3. Results should be the same according to bash documentation, but are not.
	

Actual Results:  [ -n $FOO ] && echo "FOO is not null"
  -- produces the output "FOO is not null"
[ $FOO ] && echo "FOO is not null"
  -- produces null output (i.e. evaluates correctly)

Expected Results:  Both statements should produce null output.

Additional info:
GNU bash, version 2.05.8(1)-release (i386-redhat-linux-gnu)
uname -a:
Linux localhost.localdomain 2.4.9-13 #1 Tue Oct 30 20:05:14 EST 2001 i686 
unknown
Comment 1 Bernhard Rosenkraenzer 2001-12-13 10:31:28 EST
Intended behavior.

Note from the bash maintainer:

Date: Thu, 13 Dec 2001 10:27:41 -0500
From: Chet Ramey <chet@nike.ins.cwru.edu>
Reply-To: chet@po.CWRU.Edu
To: bero <bero@redhat.de>
Cc: bug-bash <bug-bash@gnu.org>, chet <chet@po.cwru.edu>
Subject: Re: [ -n ] != [ -n "" ] in 2.05a

> [ -n ] && echo "bug"
>
> will print "bug".

As it should.

> I'd have expected [ -n ] would be the same as [ -n "" ]...

Bad expectation.

> (Affects the variants thereof, as well, e.g.
> unset FOO
> [ -n $FOO ] && echo "bug")

Bad programming practice.

Look at question E1 in the Bash FAQ for an explanation.  Equivalent
text appears in the bash man page.


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/

Comment 2 Paul W. Frields 2001-12-13 15:45:46 EST
Found the problem.  The shell evaluates (due to expansion) as follows, when 
$FOO is either null or undefined:
    [ -n $FOO ]     becomes ===>    [ -n ]
This makes only one argument, and since "-n" is not null, evaluates as true.

To solve the problem (i.e. good programming practice),
    [ -n "$FOO" ]   becomes ===>    [ -n "" ]
Since "" is a second argument and is actually null, statement evaluates as 
false (correct behavior).

Thanks for the assistance, sorry to waste your time!

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