Repository navigation
Enhancement: Write bpkg in terms of POSIX sh #90
Description
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"
Reacted by NNB
Reacted by Edwin Kofler
Activity
jwerle commentedon Aug 8, 2017
@mcandre i love that idea! we'd happily accept a PR
mcandre commentedon Aug 8, 2017
:)
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 commentedon Aug 8, 2017
@mcandre very nice :]
Potherca commentedon Oct 3, 2017
If the workload to make
bpkgPOSIX 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,shellcheckcan 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 commentedon Oct 3, 2017
@Potherca sounds good to me. we'd happily accept a PR!
hyperupcall commentedon Aug 25, 2023
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 commentedon Sep 27, 2023
As per #122 I would rather spend energy on stability (i.e. tests) and usability (docs, installation, publishing) before moving on to portability.
samlikins commentedon Sep 27, 2023
@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.