<div dir="ltr">Hi<div><br></div><div>Apart from special cases like the ramdisk's /init, which is a script that needs to run in busybox's shell, everything should be using bash. There's no point us tying ourselves in knots trying to achieve POSIX compliance for the sake of it, when bashisms are super useful.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>Chris</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 14 April 2014 17:26, Ben Nemec <span dir="ltr"><<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">tldr: I propose we use bash explicitly for all diskimage-builder scripts (at least for the short-term - see details below).<br>
<br>
This is something that was raised on my linting changes to enable set -o pipefail. That is a bash-ism, so it could break in the diskimage-builder scripts that are run using /bin/sh. Two possible fixes for that: switch to /bin/bash, or don't use -o pipefail<br>
<br>
But I think this raises a bigger question - does diskimage-builder require bash? If so, I think we should just add a rule to enforce that /bin/bash is the shell used for everything. I know we have a bunch of bash-isms in the code already, so at least in the short-term I think this is probably the way to go, so we can get the benefits of things like -o pipefail and lose the ambiguity we have right now. For reference, a quick grep of the diskimage-builder source shows we have 150 scripts using bash explicitly and only 24 that are plain sh, so making the code truly shell-agnostic is likely to be a significant amount of work.<br>
<br>
In the long run it might be nice to have cross-shell compatibility, but if we're going to do that I think we need a couple of things: 1) Someone to do the work (I don't have a particular need to run dib in not-bash, so I'm not signing up for that :-) 2) Testing in other shells - obviously just changing /bin/bash to /bin/sh doesn't mean we actually support anything but bash. We really need to be gating on other shells if we're going to make a significant effort to support them. It's not good to ask reviewers to try to catch every bash-ism proposed in a change. This also relates to some of the unit testing work that is going on right now too - if we had better unit test coverage of the scripts we would be able to do this more easily.<br>
<br>
Thoughts?<br>
<br>
Thanks.<br>
<br>
-Ben<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Cheers,<div><br></div><div>Chris</div></div>
</div>