~reykjalin/public-inbox

4 3

Re: tday-sh bash vs POSIX sh

Details
Message ID
<20210320203415.rzhzi6ik47vfpci4@arch>
DKIM signature
pass
Download raw message
Hey!
 
> I’d be happy to receive patches, or links to guides/examples on writing plain sh, and work on making the script fully POSIX compliant :)

There are two tools I use quite a lot to keep myself within the 
boundaries of POSIX sh:

1. checkbashisms: I think it's originally a script that was developed
by and for Debian mantainers but it's become quite widespread. I use it
on Arch! It *only* checks if your sh script has *bashisms*.
2. shellcheck: It's both an online service[1] and a tool you may 
install... it's a bit heavy because it relies on Haskell, but it's 
awesome as it also suggests improvements to your code that are 
unrelated to POSIX compliance!

If you know bash... you're 70% there, TBH. The most common pitfalls are
conditionals. Grymoire's tutorial[2] is a classic. Then you also have
Drew's own introduction to it on his blog.[3] But, the specs[4] are 
very accessible, in my opinion... I usually rely on those actually.

> I actually did see cras before writing tday, but it was too involved for what I wanted :) . I just wanted a simple way to set up today’s tasks, and be able to refer back to what I haven’t completed if necessary.

Yeah, cras is a bit... bloated XD
 
> tday was intended to be a portable proof-of-concept for how something like it might work with the file format. If I have the time I plan to write something more elaborate without changing the simple format. It also seems like a decent exercise when learning a new programming language.

Isn't that the whole point of coding, to explore ideas? This is really
neat!
 
Cheers!
Ari

[1]: https://shellcheck.net
[2]: https://www.grymoire.com/Unix/Sh.html
[3]: https://drewdevault.com/2018/02/05/Introduction-to-POSIX-shell.html
[4]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

-- 
Ariadna Vigo
(she/her)
Web: <https://ariadnavigo.xyz>
PGP: 0xA3B1324836A669BD

Re: tday-sh bash vs POSIX sh

Details
Message ID
<CA6IH3YEH7C0.1O0QFTQMN6HXN@Kristofers-Work-MacBook-Pro.local>
In-Reply-To
<20210320203415.rzhzi6ik47vfpci4@arch> (view parent)
DKIM signature
missing
Download raw message
Hi again Ari! Thanks for all the tips!

I just sent in 5 patches with proposed fixes for any POSIX issues, and copied you on said patches.
I'd appreciate it if you could take a look :)

No rush though, feel free to take a look whenever you have the time!

I did include an introductory message in the patchset via the `--compose` flag that didn't seem to appear, so I'll include it here just in case:

> I've sent 5 patches that fix all POSIX compliance issues I could find
> in tday-sh via `checkbashisms` and `shellcheck`.
> 
> The patches also contain fixes for other issues reported by
> `shellcheck`, and as such they should make the script more robust
> overall.
> 
> On a sidenote; I'm not sure if splitting small commits like these into
> multiple patches is the best way (in terms of etiquette) to send in
> patches like these, but decided to go with that approach since the
> patches are relatively independent of one another.
> Maybe they should be sent individually, and not as part of the same
> patchset?

Thanks for your help so far!


> Yeah, cras is a bit... bloated XD

Nah, just a different, more complex, use case I think :P


Best regards,
--
Kristófer R.

Re: tday-sh bash vs POSIX sh

Details
Message ID
<20210326013618.ypatocdlrbcmmtv7@arch>
In-Reply-To
<20210320203415.rzhzi6ik47vfpci4@arch> (view parent)
DKIM signature
pass
Download raw message
Hi again Ari! Thanks for all the tips!

I just sent in 5 patches with proposed fixes for any POSIX issues, and copied you on said patches.
I'd appreciate it if you could take a look :)

No rush though, feel free to take a look whenever you have the time!

I did include an introductory message in the patchset via the `--compose` flag that didn't seem to appear, so I'll include it here just in case:

> I've sent 5 patches that fix all POSIX compliance issues I could find
> in tday-sh via `checkbashisms` and `shellcheck`.
> 
> The patches also contain fixes for other issues reported by
> `shellcheck`, and as such they should make the script more robust
> overall.
> 
> On a sidenote; I'm not sure if splitting small commits like these into
> multiple patches is the best way (in terms of etiquette) to send in
> patches like these, but decided to go with that approach since the
> patches are relatively independent of one another.
> Maybe they should be sent individually, and not as part of the same
> patchset?

Thanks for your help so far!


> Yeah, cras is a bit... bloated XD

Nah, just a different, more complex, use case I think :P


Best regards,
--
Kristófer R.

Re: tday-sh bash vs POSIX sh

Details
Message ID
<20210326021453.dz4bvfuirqmaggk3@arch>
In-Reply-To
<CA6IH3YEH7C0.1O0QFTQMN6HXN@Kristofers-Work-MacBook-Pro.local> (view parent)
DKIM signature
pass
Download raw message
Hi!
[OK, I think this time I sent this right... neomutt is hell 
sometimes... Sorry for the mess]

> I just sent in 5 patches with proposed fixes for any POSIX issues, and copied you on said patches.
> I'd appreciate it if you could take a look :)
> 
> No rush though, feel free to take a look whenever you have the time!

I did have the time! :) I applied them locally and everything looks
awesome!

In fact, look at this ;)

	aribsd$ uname -a
	OpenBSD aribsd.localhost 6.8 GENERIC#5 amd64
	aribsd$ git clone https://git.sr.ht/~reykjalin/tday-sh   
	Cloning into 'tday-sh'...
	remote: Enumerating objects: 3, done.
	remote: Counting objects: 100% (3/3), done.
	remote: Compressing objects: 100% (3/3), done.
	remote: Total 15 (delta 0), reused 0 (delta 0), pack-reused 12
	Unpacking objects: 100% (15/15), 6.36 KiB | 100.00 KiB/s, done.
	aribsd$ mv mbox tday-sh/
	aribsd$ cd tday-sh/
	aribsd$ git am -3 mbox
	Applying: use posix compliant conditional operators
	Applying: Set IFS in a POSIX compliant way
	Applying: Remove non-POSIX compliant pipefail
	Applying: properly quote variable expansions
	Applying: Replace ls pipeline with a find command
	aribsd$ EDITOR='vise' ./tday edit
	aribsd$ ./tday 
	o Testing tday on OpenBSD
	x It works!
	aribsd$ ./tday incomplete
	o Testing tday on OpenBSD
	aribsd$ ./tday list
	2021-03-26.tday

Awesome, isn't it? Now you can safely claim tday is cross-platform!
Feel proud, you deserve it!
 
> I did include an introductory message in the patchset via the `--compose` flag that didn't seem to appear, so I'll include it here just in case:

It worked perfectly!

> > I've sent 5 patches that fix all POSIX compliance issues I could find
> > in tday-sh via `checkbashisms` and `shellcheck`.
> > 
> > The patches also contain fixes for other issues reported by
> > `shellcheck`, and as such they should make the script more robust
> > overall.
> > 
> > On a sidenote; I'm not sure if splitting small commits like these into
> > multiple patches is the best way (in terms of etiquette) to send in
> > patches like these, but decided to go with that approach since the
> > patches are relatively independent of one another.
> > Maybe they should be sent individually, and not as part of the same
> > patchset?

OK, this time you wanted someone else to review some code for you... so
it doesn't really matter? For my taste, if it's just for reviewing
purposes, the way you did is great because you can reproduce each step
at a time.

However, when you send patches someone else with the intention for them
to merge them to their branch, it's way more practical to rebase 
everything into one single patch... But, if the patch is too heavy 
(changes too many unrelated things), you should really consider each 
modification as completely separate things. 

Just for illustrative purposes, if these had been patches for a project 
of mine, I would have asked you to rebase these commits into two 
separate units, each into their own mailing list threads: one that 
dealt with POSIX compliance and another one that dealt with 'best 
practices' (like quotes and using `find'). But again, that's *me*.

When in doubt, the best is to ask the people on the other end, IMO...

> Thanks for your help so far!

Hey, it's a pleasure! :D

Ciao!
Ari

-- 
Ariadna Vigo
(she/her)
Web: <https://ariadnavigo.xyz>
PGP: 0xA3B1324836A669BD

Re: tday-sh bash vs POSIX sh

Details
Message ID
<CA7BF6DT3KWW.IKWL0GRR0152@Kristofers-Work-MacBook-Pro.local>
In-Reply-To
<20210326021453.dz4bvfuirqmaggk3@arch> (view parent)
DKIM signature
missing
Download raw message
Hi Ari!

Thanks for testing this!

> [OK, I think this time I sent this right... neomutt is hell
> sometimes... Sorry for the mess]

Haha, no worries! I've had my own share of email client problems :P

> I applied [the patches] locally and everything looks
> awesome!
>
> In fact, look at this ;)
>
> [tday testing output on OpenBSD]
>
> Awesome, isn't it? Now you can safely claim tday is cross-platform!
> Feel proud, you deserve it!

Thank you! It is *indeed* awesome to see it working on BSD! Noice \o/

Thanks for taking the patches for a spin! I really appreciate you taking
a look :)

> [The introductory message sent via --compose] worked perfectly!

Oh? That's good to know! I'm surprised it didn't make it to the mailing
list. I also don't see it in my list of sent messages. Weird.

Maybe I just don't fully comprehend how that flag actually works :)

> For my taste, if it's just for reviewing purposes, [sending multiple
> patches] is great because you can reproduce each step at a time.

Yeah, that's what I was thinking with sending the individual commits.

> Just for illustrative purposes, if these had been patches for a project
> of mine, I would have asked you to rebase these commits into two
> separate units, each into their own mailing list threads: one that
> dealt with POSIX compliance and another one that dealt with 'best
> practices' (like quotes and using `find'). But again, that's *me*.

Yeah, I agree that makes more sense. I'll keep that in mind for next
time :)

Thanks for the advice!

> When in doubt, the best is to ask the people on the other end, IMO...

That's why I'm asking! I guess I could've asked *before* sending the
patches, but figured this was small enough and it would just delay the
whole process :)


Thanks again for everything!
Stay safe!

--
Kristófer R.
Reply to thread Export thread (mbox)