conf/94377 : [patch] /etc/rc.d/sshd improperly tests random dev state

[Brooks Davis]

On Thu, Jun 08, 2006 at 05:58:29PM -0700, Doug White wrote:
> On Thu, 8 Jun 2006, Brooks Davis wrote:
> 
> >On Thu, Jun 08, 2006 at 09:30:34PM +0000, Doug White wrote:
> >>The following reply was made to PR conf/94377; it has been noted by GNATS.
> >>
> >>From: Doug White <dwhite at gumbysoft.com>
> >>To: Rostislav Krasny <rosti.bsd at gmail.com>
> >>Cc: Florent Thoumie <flz at FreeBSD.org>, Doug White <dwhite at FreeBSD.org>,
> >>    bug-followup at FreeBSD.org
> >>Subject: Re: conf/94377 : [patch] /etc/rc.d/sshd improperly tests random 
> >>dev
> >> state
> >>Date: Thu, 8 Jun 2006 10:36:05 -0700 (PDT)
> >>
> >> On Thu, 8 Jun 2006, Rostislav Krasny wrote:
> >>
> >>> I've seen that patch just today, when it is already MFCed. I think it
> >>> could be simpler. Instead of
> >>>
> >>> [ "x${seeded}" != "x" ] && [ ${seeded} -eq 0 ]
> >>>
> >>> you can write just
> >>>
> >>> [ "${seeded}" = "0" ]
> >>>
> >>> and it will be still correct against sysctl failing and returning an
> >>> empty string.
> >>
> >> No, because if ${seeded} is empty, the shell interprets the test as
> >>
> >> [ = "0" ]
> >>
> >> which results in a syntax error. The 'x' in the first test is 
> >> significant.
> >
> >Not true.  The 'x' bit has been unnecessicary 31337 for quite some
> >time IMO.  If you didn't quote ${seeded} then it would be, but
> >"${variable_that_expands_to_null}" is "". Otherwise -z and -n wouldn't
> >work.
> 
> -z and -n are unary operations. They just check if the *have* an argument. 
> = is a comparison operation and requires two operands.

I think they do actually check the argument, but weird things happen if
you pass them an unquoted argument (both -z and -n return true if you
use normal [ testargs ]; syntax).  I'm not quite sure what's happening.

> If it offends you two that much then file a new PR. I honestly don't give 
> a crap.

I don't care about the change (at least not enough to do anything about
it).  It's fine, particularly since there's plenty of code like it in
the system.

I only responded because the belief that the x"${var}" idiom is
necessicary is widely held for no reason I can figure out except perhaps
that it's so widely used the obvious inference is that there must be
some reason for doing so. :)  I can only assume that some ancient system
didn't have -n and -z and didn't handle null arguments properly.  The
following test code illustrates that the proposed solution would work
and an oddity if you don't quote the arguments passed to -z and -n.

-- Brooks

---<cut>---
#!/bin/sh

nullvar=
zerovar=0

if [ -z "${nullvar}" ]; then
	echo "nullvar is empty"
else
	echo "nullvar is not empty"
fi

if [ "${nullvar}" = "0" ]; then
	echo "nullvar equals 0"
else
	echo "nullvar does not equal 0"
fi

if [ -z "${zerovar}" ]; then
	echo "zerovar is empty"
else
	echo "zerovar is not empty"
fi

if [ "${zerovar}" = "0" ]; then
	echo "zerovar equals 0"
else
	echo "zerovar does not equal 0"
fi

echo 'testing "-z ${nullvar}"'
if [ -z ${nullvar} ]; then
	echo true
else
	echo false
fi
echo 'testing "-n ${nullvar}"'
if [ -n ${nullvar} ]; then
	echo true
else
	echo false
fi
---<cut>---

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20060609/8280f0aa/attachment.pgp