misc/132182: uname(1) uses UNAME_<flag> variables even if those are
empty
Jan Schaumann
jschauma at netmeister.org
Fri Feb 27 16:00:13 PST 2009
>Number: 132182
>Category: misc
>Synopsis: uname(1) uses UNAME_<flag> variables even if those are empty
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Feb 28 00:00:12 UTC 2009
>Closed-Date:
>Last-Modified:
>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:
>Unformatted:
More information about the freebsd-bugs
mailing list