IronPort-SDR: 6aLM/AmEnKdrRuWCtPEfBU0Gp1Ghxr5ytOyGFPG+rcYqj1D/+b6uJ0rhpvESb5Kfx1/f7Dh/ZL
 25O+LmmI9T6g==
IronPort-PHdr: =?us-ascii?q?A9a23=3ASgzmtxBhJAk7/dd8mMnMUyQVnRdPi9zP1kY99?=
 =?us-ascii?q?Zcti7VVbuK/8pf5NVLB9LNmi1qaOOeTo7oMw6Ke+7v4VzkY6I2a+DAZfZpAW?=
 =?us-ascii?q?gVNqP1enhdoWZbaTxSkfbiwN3J8RpUDHERg42n9NEFUHMjkYFiHrnO+9SMYH?=
 =?us-ascii?q?hT0HRV0IujpF4XSgM2t2+20vZbaKx5NmCL7Yb52K0CF9FSL8JBI0c05bP9hm?=
 =?us-ascii?q?y6hnw=3D=3D?=
IronPort-Data: =?us-ascii?q?A9a23=3AuZY8cauNMttxAL6iWZMh12V0XefnVIFcMUV32?=
 =?us-ascii?q?f8akzHdYApBsoF/qtZmKT/UbP+OZmDxeo9+btu2/UwPvpDXn9ViHAZtriE3H?=
 =?us-ascii?q?iMV9ZOVVN+UB3mrMnLJJKUvbq7HA+byyzX4wUldokb0/n9BCZC86ygmvU20b?=
 =?us-ascii?q?uCkUrScZHspHVUMpBoJ0HqPpcZo2uaEvvDkW2thifuqyyHuEAfNNwxcawr42?=
 =?us-ascii?q?IrZwP9bh8kejRtD1rAIiVCni3eF/5UdJMp3yahctBIUSKEMdgKxb76rIL1UY?=
 =?us-ascii?q?go1VvrwY+5JnIoXcmVSKlLTFReDgHpRQLTknhVBvSUszLd9P/0ZAatVo2/R2?=
 =?us-ascii?q?YkskZMS7trpEFtB0q7kwYzxVzFUHS1mIKdC+bTvPnm7vdCexE3JemHgzvMoB?=
 =?us-ascii?q?0he0Ygwo70qXT8Sq6BwxDclK0rra/iN6LCySfRmrsYiNtT3P4pZsWMI5SfQC?=
 =?us-ascii?q?e4nR52ET6jU6Ntw2DYrmtsIFPLGZswUbTtpcQSGZAdAUmr7orpWcPyAmXT1c?=
 =?us-ascii?q?zpDtBSJqKks6nbN3Up6172FDTYcQfTSLe09o6pSjjiuE7zFPywn?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AmgpQpK3kKRuSXyxm6nYFVgqjBJ8kLtp133?=
 =?us-ascii?q?Aq2lEZdPU0SKGlfrOV7ZYmPHjP+U4ssRAb6Km90cy7K080mqQa3WB8B8bEYO?=
 =?us-ascii?q?CighrPEGgA1+rfKl/bdBEWn9Q1vcxdnrBFZOEYT2IK6foSizPIcOrIruP3lZ?=
 =?us-ascii?q?xAyd2/85/rJzsaEJ2JaW1Ce3ymLnE=3D?=
Received-SPF: pass (webhost.teksavvy.com: connection is authenticated)
Message-ID: <39b43d4d-5a81-632c-1bbc-4bea2f0dc3c3@wildtechgarden.ca>
Date: Thu, 30 Jun 2022 10:08:58 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: Fixing shell script libraries like /lib/libalpine.sh
Content-Language: en-CA
To: Jakub Jirutka <jakub@jirutka.cz>, ~alpine/devel@lists.alpinelinux.org
References: <4caa8c5f-7ebf-ad2f-0e92-29428785fe60@wildtechgarden.ca>
 <920d69d8-bf3e-0c98-4218-9fc8fa2fef16@jirutka.cz>
From: "Daniel F. Dickinson" <dfdpublic@wildtechgarden.ca>
In-Reply-To: <920d69d8-bf3e-0c98-4218-9fc8fa2fef16@jirutka.cz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 2022-06-30 9:17 a.m., Jakub Jirutka wrote:
>> 2. If you are not already using tools like shellcheck / shellfmt and or
>> shell unit tests in your CI, do you have objections to such being added?
> Every time someone opened a merge request in my projects to fix for “bugs” detected by shellcheck, the vast majority of them were completely unnecessary changes that at best only made the code less readable, at worst introduced bugs.
> Mostly done by people who have little knowledge of the shell and just blindly apply what shellcheck throws at them without understanding it. Shell is a very context-sensitive, ambiguous and messy “language”, which makes it extremely hard to create a reliable linter for it. That’s why shellcheck doesn’t and cannot work as good as linters for normal languages – you would need a deeper analysis than what shellcheck does.
>
> That said, shellcheck is undoubtedly useful for the author as an aid when writing the shell script, but not as an automated tool for enforcing generic set of rules.

Thank you for your thoughts. I definitely agree that one should not use
as 'pedantic' settings in CI as for local development.

I would like to clarify how I would approach this:

1. Use the shell linter on the applicable code and disable any all
warnings except those that actually matter (i.e. real bugs)

2. In an initial commit, fix bugs (if any) in appropriate merge requests
(preferably atomic, one MR per real bug)

3. Do a 'no-op' addition of the linter to the CI (that is, assuming no
bugs, there shouldn't be new warnings or failures in the CI)

I don't particularly like to change working code, except with due
caution, as changes can introduce regressions.

With the setup-ntp issue, it occurred to me (and I asked for developer
preference in the issue report) whether it would be preferred to update
the erroneous documentation (sample answers file) generated by
setup-alpine, and in the docs repo, rather than change the code (since
it is not 'wrong' it just doesn't match the docs). While an enhancement
could be made that would let the documented and current behaviour both
work, it occurs to me that some (including myself) have created
automation based on the current behaviour when using '-c <whatever>' and
that 'automation' could break if the code suddenly behaved differently.

In short I definitely don't want to be introducing mass changes, nor
even unnecessary changes, even if they were arguably preferable.

I do, however, believe that having automated reductions in shooting
oneself in the foot / weeding out bad code with less effort is desirable.

Regards,

Daniel

> Jakub J.
>
> On 6/30/22 8:16 AM, Daniel F. Dickinson wrote:
>> Hello,
>>
>> I've noticed some issues with the Alpine shell script libraries (one
>> example below)[1]
>>
>> I'm new to Alpine but not to Linux, *BSD, or (way back) Ultrix, and have
>> not (yet) dug into the Alpine code base and infrastructure. (Although I
>> have my 'notes-to-self' documentation[2] that I intend (RSN...) to
>> integrate into the Wiki and have published on my website).
>>
>> My questions with respect to the issues mentioned are:
>>
>> 1. Do you prefer the GitLab merge request interface or the mailing list
>> for patches?[3]
>>
>> 2. If you are not already using tools like shellcheck / shellfmt and or
>> shell unit tests in your CI, do you have objections to such being added?
>>
>> I'm hoping to spend some time fixing this type of issue as they result
>> in annoying hiccups when trying to automate setup-alpine, and I'd like
>> that to work well.
>>
>> A final note: I've got some cloud-init image creation using Packer that
>> I soon intend to push to public repository, along with Terraform usage
>> of the same; is there interest in those here? I almost forgot; what is
>> the status the work on the 'tiny' cloud-init substitute or other
>> alternatives in Alpine?
>>
>> Regards,
>>
>> Daniel
>>
>>
>> [1]:
>>
>> # test the first argument against the remaining ones, return success on
>> a match
>> isin() {
>>     local _a=$1 _b
>>     shift
>>     for _b; do
>>         [ "$_a" = "$_b" ] && return 0
>>     done
>>     return 1
>> }
>>
>> _b is never assigned a value. This is why automating ntp setup fails
>> (specifically the following code in /sbin/setup-ntp) will never skip the
>> 'ask':
>>
>> while [ $# -eq 0 ] && ! isin "$resp" busybox openntpd chrony none abort; do
>>     ask "Which NTP client to run? ('busybox', 'openntpd', 'chrony' or
>> 'none')" chrony
>> done
>>
>> [2]: https://wildtechgarden.ca/deploy-admin/server-alpine-linux-docs4web/
>>
>> [3]: I've been off in frontend-land for a while and am somewhat out of
>> sync with current systems development preferences.
>>
>> Speaking of which, I don't see at
>> https://useplaintext.email/#thunderbird how to limit the line length to
>> 72 characters as requested (or is this unnecessary due to things
>> Thunderbird does in background when sending plaintext?).
>>
>> I unfortunately need features of Thunderbird that aren't available in
>> what I preferred in the days before MS 365 and Gmail were what most of
>> the folks I needed to communicate with dependent on, which was Claws Mail.
>>

-- 
https://wildtechgarden.ca Technical and professional website
https://princesandmadmen.ca Personal and political blog