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
On Thu Jun 30, 2022 at 8:16 AM CEST, 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]
merge requests on gitlab are highly preferred- our mailing list
integration is only into aports (package repository), and quite scuffed
as it opens a new merge request and requires a new email for any
changes..
>> 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?
tests are extremely welcome. we write ours (now) in kyua+atf, and
libalpine.sh comes from alpine-conf, see
https://gitlab.alpinelinux.org/alpine/alpine-conf/
and the tests that are already there (and where you should report any
issues that you have now, it seems).
as for shellcheck i think that would be welcome, but shellcheck has a
ton of very useless lints.. an opt-in only list of rules would most
likely work, but you'd have to ask the maintainer.
>> 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?).
seems to be wrapped correctly to me, and the entire email is plaintext
and perfectly formatted.
>> 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
Daniel F. Dickinson wrote on Thu, Jun 30, 2022 at 02:16:49AM -0400:
> # 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':
`for _b; do` is identical to `for _b in "$@"; do` and assigns the values
properly.
The function works properly for me.
setup-ntp also works for me, what exactly are you experiencing or
expecting?
--
Asmadeus | Dominique Martinet
> 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?).
You may open Edit/Preferences/General/Config. editor, right-click the
preference mailnews.wraplength, modify, and change it to 72.
A value of 0 (zero) wraps to the window width.
This applies to the wrapping of plain text messages in the message composer.
1. Thank you Alice for your response, it was very helpful
2. Dominique, also thank you, and see inline.
3. macmpi: thank you as well; also thinking I should suggest (or supply)
an update to that Thunderbird guide which is linked from the sr.ht page
linked by the Alpine ML page.
On 2022-06-30 3:07 a.m., Dominique Martinet wrote:
> Daniel F. Dickinson wrote on Thu, Jun 30, 2022 at 02:16:49AM -0400:>> # 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':> `for _b; do` is identical to `for _b in "$@"; do` and assigns the values> properly.> The function works properly for me.
I wondered about that, but parsed it too quickly when debugging my
problem (below). Sorry about that.
> setup-ntp also works for me, what exactly are you experiencing or> expecting?
The issue that led the looking at 'isin':
When using an an answer file with setup-alpine, such as (note apk_repos
gets a substitution before this is used; issue also occurs with a
hand-crafted answers file):
==================
KEYMAPOPTS="us us"
HOSTNAMEOPTS="-n localhost"
INTERFACESOPTS="auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
"
DNSOPTS=""
TIMEZONEOPTS="-z America/Toronto"
PROXYOPTS="none"
APKREPOSOPTS="${apk_repos}"
SSHDOPTS="-c openssh"
NTPOPTS="-c chrony"
DISKOPTS="-m sys /dev/vda"
==================
The prompt for which NTP client to use still appears when using
`setup-alpine -f answers`
This calls setup-ntp with NTPOPTS as the parameter; perhaps the issue is
the quoting there. In any event, I've obviously got to do some more
complete troubleshooting, fix, and test thereof.
Regards,
Daniel
Also, 'Reply List' didn't work for me; is 'Reply All' preferred for
replies to the list, or modifying the reply (which defaults to the
individual replying, at least in my client) to the list?
> --> Asmadeus | Dominique Martinet
--
https://wildtechgarden.ca Technical and professional website
https://princesandmadmen.ca Personal and political blog
Daniel F. Dickinson wrote on Thu, Jun 30, 2022 at 03:31:50AM -0400:
> This calls setup-ntp with NTPOPTS as the parameter; perhaps the issue is> the quoting there. In any event, I've obviously got to do some more> complete troubleshooting, fix, and test thereof.
The problem is setup-ntp sets 'resp' from parsing -c in getopts loop,
but actually expects it to be the first positional parameter e.g.
'setup-ntp chrony' as it checks $# and assigns resp from $1 regardless
of $#.
It shouldn't be too hard to make it work with either -c or first
positional parameter, letting you send a MR on gitlab :)
(oh, and I use reply to all and think most others do as well -- but I
don't know if it really is a rule or just habits from other lists where
non-subscribers can post)
--
Dominique
> On 30 Jun 2022, at 08:39, Dominique Martinet <asmadeus@codewreck.org> wrote:> > Daniel F. Dickinson wrote on Thu, Jun 30, 2022 at 03:31:50AM -0400:>> This calls setup-ntp with NTPOPTS as the parameter; perhaps the issue is>> the quoting there. In any event, I've obviously got to do some more>> complete troubleshooting, fix, and test thereof.> > The problem is setup-ntp sets 'resp' from parsing -c in getopts loop,> but actually expects it to be the first positional parameter e.g.> 'setup-ntp chrony' as it checks $# and assigns resp from $1 regardless> of $#.> > It shouldn't be too hard to make it work with either -c or first> positional parameter, letting you send a MR on gitlab :)> > > (oh, and I use reply to all and think most others do as well -- but I> don't know if it really is a rule or just habits from other lists where> non-subscribers can post)> --> Dominique
I've previously attempted to diagnose this exact issue to no avail in our internal builds, so can second this problem during automated ANSWERS installed.
Daniel, if you have identified the root cause, PR would be most welcome!
Kaelan Thijs Fouwels
Kaelan@fouwels.com
> 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.
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.>
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
On Thu, 30 Jun 2022 02:16:49 -0400
"Daniel F. Dickinson" <dfdpublic@wildtechgarden.ca> 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]
gitlab.
> 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?
as long as it does not
> 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.
I'm working on the testsuite to add tests to make sure setup-alpine
works with an "answer file".
> 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?
I intend to make some kind of tiny-cloud nocloud provider, which will
be able to take some sort of cloud-init compatible config for
unattended installs.
> 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 not true.
for _b; do ...
is equivalent to
for _b in "$@"; do ...
So `isin "$resp" busybox openntpd chrony none abort; do` will iterate over
"busybox openntpd chrony none abort" and return 0 (success) if $resp is
in the listed options or 1 (failure) otherwise.
See
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04_03> 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
I believe there is other problem.
(I noticed you filed a bug. I will have a look at it)
-nc
On 2022-07-01 5:21 a.m., Natanael Copa wrote:
> On Thu, 30 Jun 2022 02:16:49 -0400> "Daniel F. Dickinson" <dfdpublic@wildtechgarden.ca> 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]> gitlab.> >> 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?> as long as it does not
Er, I presume you meant to complete that thought? I hope my response to
Jakub clarifies what I'm thinking, and might address the concern you
were going to express.
> >> 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.> I'm working on the testsuite to add tests to make sure setup-alpine> works with an "answer file".
Awesome! I saw you pushed them in Gitlab recently. I look forward to
trying them out.
>> 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?> I intend to make some kind of tiny-cloud nocloud provider, which will> be able to take some sort of cloud-init compatible config for> unattended installs.
Sounds good. If I can help, please let me know.
>>> 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 not true.
Yes, I read it wrong. As you point out it was a different issue, and you
have fixed both the docs and the setup-ntp issue that were the real
culprits.
> for _b; do ...>> is equivalent to>> for _b in "$@"; do ...>> So `isin "$resp" busybox openntpd chrony none abort; do` will iterate over> "busybox openntpd chrony none abort" and return 0 (success) if $resp is> in the listed options or 1 (failure) otherwise.>> See> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04_03>>> 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> I believe there is other problem.> (I noticed you filed a bug. I will have a look at it)>> -nc
Regards,
Daniel
--
https://wildtechgarden.ca Technical and professional website
https://princesandmadmen.ca Personal and political blog
On 30-06-2022 09:07, Dominique Martinet wrote:
> Daniel F. Dickinson wrote on Thu, Jun 30, 2022 at 02:16:49AM -0400:>> # 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':> > `for _b; do` is identical to `for _b in "$@"; do` and assigns the values> properly.
Wouldn't the identical variant not be preferred in code? It reads easier
and is _obvious_ what happens.
Writing code happens rarly, that we shouldn't try to optimize it to be
as short as possible; reading code however, we do often, so having it
more readable is usually for the better ...
Also, 'hidden' features/side effects tend to be never nice, because what
you know, does not mean others know as well ;) (we you, not you-you)
Olliver
> The function works properly for me.> > setup-ntp also works for me, what exactly are you experiencing or> expecting?> > --> Asmadeus | Dominique Martinet
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.>>
On 30-06-2022 16:08, Daniel F. Dickinson wrote:
> I don't particularly like to change working code, except with due> caution, as changes can introduce regressions.
I personally don't mind this at all; as I try to have a testsuit with
tests that would catch these things :) I want to trust the CI, the
tests, to make sure we are not affraid to touch code. Being affraid to
touch code isn't a good thing imo.
Olliver