Shell is hard to package because the language is a big ball of string(s) with a lot of subtle run-time dependencies on the filesystem and execution environment. It’s easy to zip up some scripts and ship them off, but it’s hard to answer table-stakes questions like whether the packagers have correctly identified all of the external dependencies and provided the right versions/variants.
This doesn’t check option compatibility, but for that, you can use feature checks.
For example, grep -P is a GNU extension, and can’t be assumed to be available just because grep is (and pgrep isn’t an alias for it either). Solution: A feature test like grep -P - < /dev/null.
Thanks for linking shellharden. I’ve had it starred for a while, but more recently I’m putting shell-scripting stuff on its own list and haven’t found the energy to go back through all of my old stars.
The 2nd part addresses a static approach (I guess I’ll post it when this falls off…), though it has the same option compatibility problem for now.
Well said. What I do: Assert that command dependencies are installed
This doesn’t check option compatibility, but for that, you can use feature checks. For example,
grep -Pis a GNU extension, and can’t be assumed to be available just becausegrepis (andpgrepisn’t an alias for it either). Solution: A feature test likegrep -P - < /dev/null.Thanks for linking shellharden. I’ve had it starred for a while, but more recently I’m putting shell-scripting stuff on its own list and haven’t found the energy to go back through all of my old stars.
The 2nd part addresses a static approach (I guess I’ll post it when this falls off…), though it has the same option compatibility problem for now.