Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Aug 2010 16:01:18 +0200
From:      Jilles Tjoelker <jilles@stack.nl>
To:        Alexander Leidinger <Alexander@Leidinger.net>
Cc:        jhell <jhell@DataIX.net>, FreeBSD Stable <freebsd-stable@freebsd.org>
Subject:   Re: daily run output 800.scrub-zfs fixups
Message-ID:  <20100822140118.GA42636@stack.nl>
In-Reply-To: <20100822150842.00005129@unknown>
References:  <4C6F5344.6040808@DataIX.net> <20100822150842.00005129@unknown>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 22, 2010 at 03:08:42PM +0200, Alexander Leidinger wrote:
> On Sat, 21 Aug 2010 00:17:08 -0400 jhell <jhell@DataIX.net> wrote:
> > Hi Alexander,

> > Attached is a fix for one problem and one slight overlook for
> > 800.scrub-zfs.

> > The first & second change was probably just an oversight but none the
> > less they both give a false impression of actions taken.

> > Change1:
> > 	${daily_scrub_zfs_default_threshold=30} is missng the ':'
> > which would ultimately reset the users supplied value in
> > periodic.conf to 30.

> Sorry, but it is not missing the ':'. There is one in front of it. A
> lot of start scripts in ports use this. You need to use a := instead of
> a = if you use
>   var=${var:=default_val}
> but not if you use
>   : ${var=default_val}

> I have the impression that the ':' in front of the variable is the way
> it is supposed to be in the start scripts in ports. I adopted this
> style (one variable name less to type... specially with expressive
> names this is some amount less to type).

As described in sh(1) and POSIX, ${var=default_val} assigns the default
if var was not set, while ${var:=default_val} assigns the default if var
was not set or if it was set to the empty string.

The double assignment in the construct
  var=${var:=default_val}
is a workaround for bugs in very old Bourne shells (see Autoconf
documentation for more). Our sh(1) has never had that bug, so simply
  : "${var:=default_val}"
is better.

The double-quotes prevent unnecessary pathname generation, which could
be slow. However, even without the double-quotes, the correct value is
assigned and no other side effects occur.

> And I remember to have tested a lot of cases for the timeout value,
> overriding a pool specific value and overriding the default where some
> of them and all worked.

> If you have a case where it does not work, it would be nice if you
> could add a "set -x" in the beginning of the script and send me the
> output of a failing run.

-- 
Jilles Tjoelker



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100822140118.GA42636>