On 02/12/18 17:04, Horst G. Burkhardt wrote:
> On Mon, 12 Feb 2018 16:51:07 -0600
> "A. Wilcox" <awil...@adelielinux.org> wrote:
>> On 02/12/18 16:26, A. Wilcox wrote:
>>> Correct on both accounts.  My concern is more with root's default
>>> login shell being /bin/sh.  I do not know how well dash would be
>>> tolerated as the interactive shell for administrating Adélie. 
> Honestly, that's a preference issue - it's trivial to change the
> default login shell for root to something friendlier. 
> "let root have nice things" or "don't spend any more time than you need
> to in an interactive root shell". Or perhaps some mix of both. This
> isn't a huge obstacle, it's just another thing that needs to go in the
> documentation - "hey, POSIX sh is kind of limiting, you might want to
> use bash for day to day system administration." 

You make a good argument that users should not be spending time in an
interactive root shell anyway.  Perhaps dash-binsh /would/ have a place;
but see below.

>> awilcox on elaine /usr/src/packages/system/dash $ abuild
>> /usr/bin/abuild: 1778: /usr/bin/abuild: Bad substitution
> ooft. I've seen this happen with some configure scripts that falsely
> advertise that they're 'sh' when they only ever really got tested with
> bash. 
>> abuild does not work with dash as /bin/sh.  This is pretty much going
>> to be a non-starter on builders, and it's going to make development on
>> computers with dash-binsh completely unusable.
>> I'm not sure if dash-binsh should conflict with abuild so a user can't
>> do that, or if I should just remove dash-binsh completely, or if
>> abuild should depend on bash and use #!/bin/bash.  This is kind of
>> terrible, especially since abuild works fine with bash or busybox
>> as /bin/sh.  It even almost works completely with zsh as /bin/sh.
> The solution is to make abuild depend on bash and use #!/bin/bash - if
> it's using sh features that aren't quite POSIX it shouldn't be calling
> sh. 
> If abuild doesn't honestly advertise its requirements and capabilities,
> that's an issue with abuild, and it's a fixable one. We have a good
> working relationship already with the Alpine folks, and you've
> mentioned some of them also would like dash as /bin/sh - I'm sure
> they'll be amenable to that being fixed. 

Let me start off by saying abuild, as written upstream, is not falsely
advertising anything.

Upstream ships abuild with #!/bin/ash.  They require BusyBox shell.  I
managed to make it work on bash *and* get the patches upstreamed:


That said, I do not think Alpine's developers had any intention of
making a POSIX sh script when they wrote abuild.

The line that failed with "bad substitution" is:

if [ ! -f
]; then

This is a blatant bashism, but it's supported in BusyBox (and zsh), so
there is no harm in using it for them.

Additionally, since they require BusyBox, they specifically told me two
years ago that making it #!/bin/sh on Adélie was unsupported and that I
can keep the pieces when it breaks.

possible bashism in /usr/bin/abuild line 232 (type):
possible bashism in /usr/bin/abuild line 257 ($'...' should be "$(printf
possible bashism in /usr/bin/abuild line 265 (${foo:3[:1]}):
possible bashism in /usr/bin/abuild line 502 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 832 ($'...' should be "$(printf
possible bashism in /usr/bin/abuild line 834 ($'...' should be "$(printf
possible bashism in /usr/bin/abuild line 944 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 1323 (${foo:3[:1]}):
possible bashism in /usr/bin/abuild line 1440 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 1441 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 1684 (type):
possible bashism in /usr/bin/abuild line 1778 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 1793 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 1806 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 2029 (export foo=bar should be
foo=bar; export foo):
possible bashism in /usr/bin/abuild line 2111 (${parm/?/pat[/str]}):

I am almost positive that I could replace the ${var//} syntax with
subshells + sed and manage to bring this thing in to POSIX compliance,
or at least very close to it.  However, I am equally almost positive
that such a change wouldn't be accepted upstream.

And even if I did, I don't trust that future patches and updates to
abuild wouldn't break it simply because Alpine's developers and
contributors might simply forget to test POSIX compliance.  That would
unintentionally break it here over again.

Let me remind everyone that Alpine is *upstream*, not *downstream*.
They enforce the rules, and we play by them.  We aren't the ones who
tell them to use POSIX, they're the ones that tell us to use a bash-like.


A. Wilcox (awilfox)
Project Lead, Adélie Linux

Attachment: signature.asc
Description: OpenPGP digital signature

Adélie Development mailing list -- adelie-devel@lists.adelielinux.org
To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org

Reply via email to