[PATCH] update autogen-waf.sh

[Rowland Penny]

On Fri, 11 Aug 2017 20:32:11 +1000
Martin Schwenke <martin at meltin.net> wrote:

> On Fri, 11 Aug 2017 11:21:00 +0100, Rowland Penny via samba-technical
> <samba-technical at lists.samba.org> wrote:
> 
> > On Fri, 11 Aug 2017 18:53:16 +1000
> > Martin Schwenke <martin at meltin.net> wrote:
> > 
> > > Hi Rowland,
> > > 
> > > On Thu, 10 Aug 2017 14:21:34 +0100, Rowland Penny via
> > > samba-technical <samba-technical at lists.samba.org> wrote:
> > >   
> > > > OK, here is the first one, this is basically just running the
> > > > script through 'shellcheck' and fixing any errors found, it
> > > > should not change how the script works.  
> > > 
> > > It all looks good.  Can I suggest a minor improvement in a few
> > > places?
> > > 
> > > Instead of doing:
> > > 
> > >   "$p"/Makefile
> > > 
> > > it is probably better to do:
> > > 
> > >   "$p/Makefile"
> > > 
> > > That way the quotes are around the whole string and future edits
> > > are less likely to be fragile.
> > > 
> > > However, you need to be careful with examples like this:
> > > 
> > >   "$p"/include/config*.h*
> > > 
> > > If you double-quote the wildcards then they don't get expanded.
> > > There are a few answers to this, including:
> > > 
> > >   "$p/include/config"*.h*
> > > 
> > > Deciding where to end the quotes is quite subjective.  :-)
> > > 
> > > Personally, I tend to "over-punctuate" my shell scripts.  I would
> > > write the first example as:
> > > 
> > >   "${p}/Makefile"  
> > 
> > I understand all this Martin and as I said earlier, where do you
> > stop ?
> 
> Cool.  I'm just over-communicating given the usual time turnaround
> for long distance email conversations...  :-)
> 
> > > While the braces aren't necessary in this case, I believe that
> > > they make the variable expansion more obvious... especially in
> > > cases where there are multiple expansions in a string.  The only
> > > place I don't use the braces is when the variable expansion is
> > > the whole string, as in "$p".  
> > 
> > I normally use them in every case, just in case ;-) but in this
> > case, I am just following 'shellcheck' and fixing obvious errors.
> 
> Yeah, shellcheck often provides hints that the code could be better.
> 
> > I think I will start again, follow 'shellcheck' but add what I would
> > normally do and also fix any errors. I will also take on board what
> > you say about the ctdb tests and ignore them.
> 
> I think that's a good move.
> 
> That said, if you really do want to attack the CTDB tests then I think
> the order could be:
> 
> 1. Fix shellcheck hits in unit tests
> 2. Fix shellcheck hits in the (bash) integration tests
> 3. Convert bash to POSIX sh
> 
> However, it is a major undertaking...
> 
> TV time.  :-)
> 
> peace & happiness,
> martin

OK, I have been working through samba-master looking at .sh files and I
am now wondering whether this is where to start. The problem is that I
am coming across files I didn't know exist and I am now thinking that
some of these would be better fixed by deleting them. Most of these are
in the 'examples' dir, why is Samba in the 'telling how to create rpms'
business ? (especially as it doesn't seem to work any more) why do we
have an old 'auto.smb' file ? etc etc

Comments please.

Rowland