<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 12, 2015 at 10:46 AM, Christopher Larson <span dir="ltr"><<a href="mailto:clarson@kergoth.com" target="_blank">clarson@kergoth.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div class="gmail_quote">On Wed, Aug 12, 2015 at 9:56 AM, Khem Raj <span dir="ltr"><<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Aug 12, 2015 at 2:49 AM, <<a href="mailto:Mikko.Rapeli@bmw.de" target="_blank">Mikko.Rapeli@bmw.de</a>> wrote:<br>
> This reminded me of the problems I've seen with various oe-core shell scripts:<br>
> they are missing systematic error handling.<br>
><br>
> IMO using bash and 'set -euxo pipefail' are a good approach to catch errors<br>
> early in shell scripts. Manually checking for $? is error prone and things<br>
> like pipes can hide them. Using undefined variables is another thing<br>
> which should fail early before things go horribly wrong. And in build automation<br>
> I'd rather see output of -x since things can fail in mysterious ways.<br>
> And then there's quoting....<br>
><br>
> One useful guide is to use shellcheck as static analysis tool for shell scripts.<br>
><br>
> I guess internally <span><span class="il">bitbake</span></span> uses at least set -e.<br>
><br>
> Comments?<br>
<br>
</span>all these are good suggestions, I would recommend to open bugs for all<br>
of these some of them might need<br>
to cite the scripts which need fixing.</blockquote></div><br></span>Agreed, it's important to check the behavior of shell scripts is kosher and standards-compliant. shellcheck is extremely useful, I recommend it as well, but combined with the vim syntastic plugin, so every time you save the file all the errors and warnings are identified :) Makes it harder to ignore or forget about.</blockquote></div><br>That reminds me, there's a shell portability issue / standards-complaince issue that's not identified by shellcheck. Typically, to negate a bracket expression in a regular expression, one uses ^, e.g. [^a-z] is everything that isn't in the range a to z, but that's not the case in shell, e.g. at a prompt or in a ${foo#<pattern>}:</div><div class="gmail_extra"><br></div><div class="gmail_extra"> "[...]a bracket expression as in XBD <i>RE Bracket
Expression</i> , except that the <exclamation-mark> character ( <tt>'!'</tt> ) shall replace the <circumflex>
character ( <tt>'^'</tt> ) in its role in a non-matching list in the regular expression notation"</div><div class="gmail_extra"><br></div><div class="gmail_extra">So in shell, you'd want [!a-z] rather than [^a-z]. Nearly all shells handle both, but the behavior of the latter is actually unspecified according to the standard:</div><div class="gmail_extra"><br></div><div class="gmail_extra"> "A bracket expression starting with an unquoted <circumflex> character produces unspecified results."</div><div class="gmail_extra"><br></div><div class="gmail_extra">I recently got bitten by this with one of my shell scripts on a system running dash.<br>-- <br><div class="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>