Re: [lmi] Check bashisms in makefiles

[Greg Chicares]

On 2016-10-23 17:33, Vadim Zeitlin wrote:
> On Sun, 23 Oct 2016 16:07:18 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2016-10-23 13:06, Vadim Zeitlin wrote:
> GC> > On Sun, 23 Oct 2016 11:38:58 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> Vadim, do you know of a better tool to check for bashisms in 
> makefiles
> GC> > GC> than 'checkbashisms'?
> GC> [...]
> GC> > https://github.com/koalaman/shellcheck/blob/master/shellcheck.1.md
> GC> [...]
> GC> > makefiles would need to be preprocessed and shell code extracted from 
> them.
[...]
>  Immediately after posting this, I realized that this could, perhaps, be as
> simple as just piping the commands shown by "make -n" through shellcheck.
> This might not cover everything (although I have trouble coming up with any
> examples), but wouldn't this be still useful?

I had forgotten about 'make -n'. Trying that with 'checkbashisms' because
I've already gone to the trouble of installing it:

/opt/lmi/src/lmi[0]$make -n fardel 2>&1 | checkbashisms --extra --force --posix

No output...because that script apparently doesn't read stdin; but if we
save a temporary file, then an 'echo -n' warning is given:

/opt/lmi/src/lmi[0]$make -n fardel 2>&1 >eraseme; checkbashisms --extra --force 
--posix eraseme
script eraseme does not appear to have a #! interpreter line;
you may get strange results
possible bashism in eraseme line 19 (echo -n):
d0=`date +%Y-%m-01`; d1=`date --utc --date="$d0 + 1 month " +%s`; d2=`date 
--utc --date="$d0 + 2 months" +%s`; j1=`expr 2440588 + $d1 / 86400`; j2=`expr 
2440588 + $d2 / 86400`; echo -n "$j1 $j2" >expiry; 
/opt/lmi/src/lmi[1]$

> GC> No, thanks. I've tried to avoid nonportable features (in the past, I used
> GC> 'ash' to detect problems), so I don't imagine there are many problems.
> 
>  As usual, my main concern is not about finding all the problems now, as
> I'm indeed quite confident that you will do it and probably in less time
> than trying to automate it, but in ensuring no problems are introduced
> again in the future -- and an automatic check would be really useful for
> that.

I'm doing all new work on debian GNU/Linux, where /bin/sh is dash, so
the only new shell-portability problems I can introduce are those that
dash supports--but AFAICT dash is POSIX with very few extensions (like
'echo -n' and 'local'), so I don't see much danger here.