Date: Fri, 15 Mar 2019 16:04:36 +0100
From: u-3qpt@aetey.se
To: "A. Wilcox" <awilfox@adelielinux.org>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Normalizing Python packages in aports
Message-ID: <20190315150436.GL23721@example.net>
References: <20190306212501.GD2800@cirno.localdomain>
 <20190314112413.29dd9816@ncopa-desktop.copa.dup.pw>
 <20190314191241.GF1544@homura.localdomain>
 <2FA74AE3-3730-4F03-8E76-32FB28D18E1D@adelielinux.org>
 <20190314203741.GA2687@homura.localdomain>
 <b3ae2e81-0c08-1a38-e6ee-8b56ddc4b9f8@adelielinux.org>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b3ae2e81-0c08-1a38-e6ee-8b56ddc4b9f8@adelielinux.org>

On Thu, Mar 14, 2019 at 05:30:00PM -0500, A. Wilcox wrote:
> Thus, the terms "undefined" and "unspecified"
 [skipped]
> It is therefore conformant for a POSIX shell script to use any of the
> unspecified keywords, as long as they can "deal with" the unspecified
> behaviour.

A shell script does not "deal" with the behaviour, unless it actually
does.

> This can be trivially accomplished using `type` and defining a small
> `local` function for shells that don't have it[2], *if* abuild were ever

Then this has to be done, before being able to say that the script "deals"
with a statement possibly unknown to the shell interpreter.

> to *use* such a shell.  Note that I doubt that would be possible anyway,
> as   abuild require multiple changes that were rejected when we proposed
> strict POSIX compatibility.  (This was so we could use zsh or dash as
> /bin/sh and let abuild use a /bin/sh hashbang instead of requiring a
> hard dependency on BusyBox.  We gave up and gave it a hashbang of
> /bin/bash in our soft-fork.)  In addition, all build scripts inside of
> packages which use /bin/sh as their hashbang would *also* have to be
> compatible with this theoretical shell.

This is a separate argument, saying that because other parties are
not disciplined enough, you choose not to bother. Of course, this
may be practically sound, but how big is your gain by choosing
to write non-portable code?

Other parties' questionable behaviour does not preclude one from writing
portable scripts. This actually does not cost too much overhead, but
makes the reuse of the code and of the trained coding skills (including
people who for any reason read your code) more reliable and portable,
I would say more efficient.

Regards,
Rune



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---