From nobody@FreeBSD.org  Fri Feb 27 23:56:30 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A74A41065673
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 27 Feb 2009 23:56:30 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 950A88FC16
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 27 Feb 2009 23:56:30 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n1RNuUZl007369
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 27 Feb 2009 23:56:30 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n1RNuUTL007368;
	Fri, 27 Feb 2009 23:56:30 GMT
	(envelope-from nobody)
Message-Id: <200902272356.n1RNuUTL007368@www.freebsd.org>
Date: Fri, 27 Feb 2009 23:56:30 GMT
From: Jan Schaumann <jschauma@netmeister.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: uname(1) uses UNAME_<flag> variables even if those are empty
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         132182
>Category:       bin
>Synopsis:       uname(1) uses UNAME_<flag> variables even if those are empty
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Feb 28 00:00:12 UTC 2009
>Closed-Date:    Sun Apr 18 20:59:32 UTC 2010
>Last-Modified:  Sun Apr 18 20:59:32 UTC 2010
>Originator:     Jan Schaumann
>Release:        
>Organization:
>Environment:
>Description:
uname(1) on FreeBSD has the interesting feature that one can set, say, UNAME_r to a string and 'uname -r' will report that string.  However, it will also report that string if UNAME_r is set in the environment but empty.

I believe that is a bug, since the intention is to use the UNAME_r variable as specified by the user, but the user may wish to change this back to the default.

Yes, this can be worked around by using 'unset'; however, in some instances this isn't possible:  consider a crontab where an entry needs to execute using the variable, but other crontabs must not:

UNAME_r=foo
0 * * * * whatever
UNAME_r=
* * * * * another


Using 'unset' is not an option in this scenario, nor is "remembering" the previous value in a temporary variable a la "UNAME_r_orig=$(uname -r)".
>How-To-Repeat:
export UNAME_r="foo"
uname -r
export UNAME_r=
uname -r
>Fix:
diff -b -u -r1.14 uname.c
--- uname.c     1 Jul 2003 20:15:28 -0000       1.14
+++ uname.c     27 Feb 2009 23:52:52 -0000
@@ -134,7 +134,8 @@

 #define        CHECK_ENV(opt,var)                              \
 do {                                                   \
-       if ((var = getenv("UNAME_" opt)) == NULL) {     \
+       if (((var = getenv("UNAME_" opt)) == NULL) ||   \
+               (strlen(var) == 0)) {                   \
                get_##var = native_##var;               \
        } else {                                        \
                get_##var = (get_t)NULL;                \


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: kib 
State-Changed-When: Sun Apr 18 20:57:40 UTC 2010 
State-Changed-Why:  
I think that uname(1) behaviour is right. There is no reason to special-case 
any value for the environment variables. Somebody might really want the 
empty values for whatever reason. 

Your case is better handled by usual trick of wrapping the invocation 
of the program with env(1), where you can set or _unset_ any environment 
variable. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=132182 
>Unformatted:
