[PATCH] ctdb-doc: Provide an example script for migrating old configuration (bug 13550)

[Martin Schwenke]

Hi Rowland,

On Sat, 28 Jul 2018 10:25:07 +0100, Rowland Penny <rpenny at samba.org>
wrote:

> On Sat, 28 Jul 2018 17:11:38 +1000
> Martin Schwenke via samba-technical <samba-technical at lists.samba.org>
> wrote:
> 
> > Include an example ctdbd.conf-style file for testing.
> > 
> > CTDB in Samba 4.9 has a new style of configuration.  This can help
> > users migrate their configuration to the new style.  This is an
> > example, so is in doc/examples/.  Distros might decide to use a
> > variation of it.

> You seem to use the same variable name in multiple functions, wouldn't
> these be better declared as 'local' inside the functions ?

Unfortunately "local" isn't a POSIX-compliant shell feature.  :-(

I try to avoid a particular shell (bash has locals, so does dash) and
stay within the POSIX features.

That's why I use a convention of starting "local" variables with an
underscore.  It helps to indicate when a variable might be overridden
by a called function.

> You also send the file path and name to each function, why not put
> these inside the functions ? e.g. 
> local _out_file="${config_dir}/README.warn"

I wondered about this.  The function names give a strong hint about the
file that they're going to create, so it would be reasonable.  However,
I though that when glancing at the script, if the filenames were passed
to the functions in the "main" section, then the file created by each
called function would be more obvious.  I decided it was a 50:50 call
and chose redundancy rather than leaving the filenames (slightly)
implied at the top level.  :-)

> There is also this:
> 
> # Check if an option will convert to a ctdb.conf option
> check_ctdb_conf_option ()
> {
> 	_opt="$1"
> 
> 	_out=$(get_ctdb_conf_option "$_opt" "")
> 	[ -n "$_out" ]
> }
> 
> I understand it up to the last line, is there something missing, such
> as:
>        if [ -n "$_out" ]; then
>            return 0
>        else
>            return 1
>        fi

Informally, a shell function returns the value of the last command
executed.  I just tried reading the formal description of function calls
in the POSIX standard and I think I'll stick with the informal one.  :-)

So, at the end of a function:

  [ -n "$_out" ]

and

  if [ -n "$_out ] ; then
    return 0
  else
    return 1
  fi

accomplish exactly the same thing.  This is partly because the shell
doesn't have syntax for conditions.  Rather than being syntax,

  [ -n "$_out" ]

is just a command that exits with 0 or 1 depending on whether it
succeeds.

So, that makes the 2nd form, with explicit returns, somewhat redundant.

peace & happiness,
martin