Message-ID: <eba5a8c6-ce58-3b7c-3ca3-181002b3f22f@schinagl.nl>
Date: Wed, 27 Jul 2022 13:37:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Reply-To: oliver+list@schinagl.nl
Subject: Re: Fixing shell script libraries like /lib/libalpine.sh
Content-Language: nl
To: ~alpine/devel@lists.alpinelinux.org
References: <4caa8c5f-7ebf-ad2f-0e92-29428785fe60@wildtechgarden.ca>
 <920d69d8-bf3e-0c98-4218-9fc8fa2fef16@jirutka.cz>
From: Olliver Schinagl <oliver@schinagl.nl>
In-Reply-To: <920d69d8-bf3e-0c98-4218-9fc8fa2fef16@jirutka.cz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hey Jakub,

On 30-06-2022 15:17, 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.While I agree with your first statement, people not understanding 
how/what they are doing, I have to strongly dissagree with the second part.

I write a lot of shell code, mostly surrounding alpine, but other stuff 
as well. I try to write my shellcheck as clean as I can. I do very very 
ocassionally do a shellcheck disable, but with an comment indicating the 
why and for good reason (e.g. sometimes you WANT certain behavior, that 
is sometimes considered bad).

Having said that, I configure shellcheck to be as strict as possible, 
write only posix compliant scripts and have not yet written 'super ugly 
stuff just to please shellcheck'. I did sit down and re-evaluated what I 
had, so yes, it costs more time.

Obviously, just as you have yours, this is my personal opinion :) But I 
think shellcheck does a very decent job at linting, and tends to be 
right for the most cases.

Olliver


> 
> 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.
>>