Bug 57230 - [ -n <string> ] does not behave correctly for undeclared variables
Summary: [ -n <string> ] does not behave correctly for undeclared variables
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-12-07 14:57 UTC by Paul W. Frields
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-12-07 14:57:20 UTC
Embargoed:


Attachments (Terms of Use)

Description Paul W. Frields 2001-12-07 14:57:16 UTC
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 15:31:28 UTC
Intended behavior.

Note from the bash maintainer:

Date: Thu, 13 Dec 2001 10:27:41 -0500
From: Chet Ramey <chet.cwru.edu>
Reply-To: chet.Edu
To: bero <bero>
Cc: bug-bash <bug-bash>, chet <chet.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.Edu    http://cnswww.cns.cwru.edu/~chet/



Comment 2 Paul W. Frields 2001-12-13 20:45:46 UTC
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.