Shellcheck finds bugs in your shell scripts

• ShellCheck

  488 34,995 8.7 Haskell

  ShellCheck, a static analysis tool for shell scripts

zsh was originally supported, but unceremoniously removed: https://github.com/koalaman/shellcheck/issues/298

I've had great experiences with this tool, but, for some reason, this issue always makes me question taking too great a dependency on it.

• bach

  1 544 6.7 Shell

  Bach Testing Framework (by bach-sh)

  

I also recommend https://github.com/bach-sh/bach when you have to use Bash for things long enough it probably shouldn't be!

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• strictbash

  2 5 0.0 Nix

  Enable Bash "strict mode" & run shellcheck via a shebang

Shellcheck is a godsend

https://github.com/jamespwilliams/strictbash, I wrote this little wrapper a while back that you can use as a shebang for scripts. It runs shellcheck for you before the script executes, so it’s not possible to run the script at all if there are failures. It also sets all the bash “strict mode” [0] flags.

[0] http://redsymbol.net/articles/unofficial-bash-strict-mode/

• Shwift

  1 69 5.0 Swift

  Shell scripting in Swift

Scripts can easily be configured with libraries and run pre-compiled by using clutch[2].

For cross-platform use, be sure only use libraries on all platforms (i.e., not Foundation). It's a pain, but at least the error shows up typically at compile-time instead of run-time.

[1] - [shwift](https://github.com/GeorgeLyon/Shwift)

[2] - [clutch - any Swift scripts in a common nest](https://github.com/swift-nest/clutch)

• clutch

  1 2 9.0 Swift

  Run Swift scripts that depend on packages (by swift-nest)

  

Scripts can easily be configured with libraries and run pre-compiled by using clutch[2].

For cross-platform use, be sure only use libraries on all platforms (i.e., not Foundation). It's a pain, but at least the error shows up typically at compile-time instead of run-time.

[1] - [shwift](https://github.com/GeorgeLyon/Shwift)

[2] - [clutch - any Swift scripts in a common nest](https://github.com/swift-nest/clutch)

• shh

  6 260 5.1 Haskell

  Simple shell like scripting from Haskell

• shellcheck-gitlab-ci-scripts-hook

  1 - -

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• dagger

  92 10,228 9.9 Go

  Application Delivery as Code that Runs Anywhere (by dagger)

  

> but I'm not convinced it's ready to replace Gitlab CI.

The purpose of Dagger it's not to replace your entire CI (Gitlab in your case). As you can see from our website (https://dagger.io/engine), it works and integrates with all the current CI providers. Where Dagger really shines is to help you and your teams move all the artisanal scripts encoded in YAML into actual code and run them in containers through a fluent SDK which can be written in your language of choice. This unlocks a lot of benefits which are detailed in our docs (https://docs.dagger.io/).

> Dagger has one very big downside IMO: It does not have native integration with Gitlab, so you end up having to use Docker-in-Docker and just running dagger as a job in your pipeline.

This is not correct. Dagger doesn't depend on Docker. We're just conveniently using Docker (and other container runtimes) as it's generally available pretty much everywhere by default as a way to bootstrap the Dagger Engine. You can read more about the Dagger architecture here: https://github.com/dagger/dagger/blob/main/core/docs/d7yxc-o...

As you can see from our docs (https://docs.dagger.io/759201/gitlab-google-cloud/#step-5-cr...), we're leveraging the *default* Gitlab CI `docker` service to bootstrap the engine. There's no `docker-in-docker` happening there.

> It clumps all your previously separated steps into a single step in the Gitlab pipeline.

This is also not the case, we should definitely improve our docs to reflect that. You can organize your dagger pipelines in multiple functions and call them in separate Gitlab jobs as you're currently doing. For example, you can do the following:

```.gitlab-ci.yml

• shellharden

  16 4,543 5.0 Rust

  The corrective bash syntax highlighter

Everytime I see Shellcheck coming up, I have to mention shellharden[0] written by a colleague of mine. It is basically shellcheck but it applies the suggested changes automatically.

0: https://github.com/anordal/shellharden

Suggest a related project