Enhancement: Write bpkg in terms of POSIX sh

[mcandre]

bpkg is amazing, would be great for managing zsh and ksh scripts as well! What do you think of writing bpkg's internals in terms of POSIX sh, so that bash isn't actually required for bpkg?

For example, [[ -f "$CONFIG_FILE" ]] could be accomplished with test -f "$CONFIG_FILE"

[jwerle]

@mcandre i love that idea! we'd happily accept a PR

[mcandre]

:)

As a prototype, I pushed https://github.com/mcandre/shaggy . Functionality is rather basic, but it shows what is possible with pure POSIX sh, and what the syntax looks like. Also features an example of checkbashisms, a linter that helps to warn on the presence of bash-specific code, for projects where you want to distinguish between bash and POSIX sh code.

[jwerle]

@mcandre very nice :]

[Potherca]

If the workload to make bpkg POSIX compliant is too large, I wouldn't mind donating some time to help.

Just a thought but would it be useful to use BASH POSIX mode (with set -o posix) to migrate to POSIX in increments?

Similar to checkbashisms, shellcheck can be made to check scripts for POSIX compliance by using the flag -s sh .

---

^{Obligatory links to https://wiki.ubuntu.com/DashAsBinSh and http://mywiki.wooledge.org/Bashism after mention of POSIX portability and bashisms}

[jwerle]

@Potherca sounds good to me. we'd happily accept a PR!

[hyperupcall]

In general, porting Bash shell code to POSIX-compliant shell code negatively impacts performance. Bash has more features under variable expansion and flags to builtins that would otherwise require costly subshells or running external programs. We do have some documented performance issues at #129, so I'm not sure this is the right way to go usability and performance-wise. So in my opinion, I'm inclined to close this issue. Not sure what else has changed since 2017.

[Potherca]

As per #122 I would rather spend energy on stability (i.e. tests) and usability (docs, installation, publishing) before moving on to portability.

[samlikins]

@Potherca, I currently have a significant number of tests that I've created for a large amount of the project (using shUnit2). Sadly got a denser workload right now, so had to put it on pause.