DevOps-Bash-tools: a thousand shell scripts that also want your dotfiles

What the script collection actually covers

The repository description claims 1200 or more DevOps Bash scripts, and the directory names at the root show how that number is reached. There is an `aws/` directory, an `azure_devops/` directory, a `bigdata/` directory, an `applescript/` directory and an `ai/` directory alongside the shared code in `Library/` and the executable scripts in `bin/`.

The topic list widens it further: API, AWS, GCP, Kubernetes, Docker, Terraform, Kafka, Hadoop, Jenkins, GitHub, GitLab, BitBucket, MySQL, PostgreSQL, SQL, CI/CD, and a set of programming language toolchain references covering Python, Perl, Ruby, NodeJS and Golang. The stated approach is that each script stands alone rather than depending on a shared framework, which is why the collection is browsable at all.

This is a genuinely different shape of project from a CLI with subcommands. There is no `devops-bash-tools` binary, no plugin registry and no configuration file format. You read a script, you take the part you needed, and you adapt it. Whether that is a virtue depends entirely on whether you wanted a tool or an example.

The repository is not archived, the last push was on 2026-09-15, and the open issue count is low for a project of this size, which is a reasonable sign that the scripts are not generating a stream of breakage reports.

The Makefile, and what install actually does to your home directory

This is the part of the repository that deserves reading carefully, because the dotfiles half is not obvious from the name.

The root `Makefile` includes `Makefile.in` and defines three repo-specific targets, described in its own usage text:

make install
make link
make unlink

The descriptions say that `make install` builds all script dependencies, installs the AWS CLI and the GitHub CLI, symlinks all config files to your home directory, and adds sourcing of the bash profile. `make link` does the symlinking and profile sourcing. `make unlink` removes all symlinks pointing at the repository's config files and removes the sourcing lines from the bash profile.

That is the whole business model in three commands. The repository ships `.bashrc`, `.bash_profile`, `.bash_logout`, `.zshrc`, `.zshenv`, `.zprofile`, `.zlogin`, `.zlogout`, `.gitconfig`, a `.bash.d/` directory and per-tool envrc files for AWS, GCP, Java, Kubernetes, Python and Terraform. Running `make link` points your shell at this repository's version of those files instead of yours.

For a fresh machine or a container image that is genuinely useful. For a machine you have already configured, it means your personal shell configuration is now symlinked into someone else's repository, and `make unlink` is the undo. The Makefile computes the file list with a `sed` call over `setup/files.txt`, and the shell profile files are `.bashrc`, `.bash_profile` and the scripts in `.bash.d/`.

Python tooling dependencies that are not really script dependencies

The `requirements.txt` at the root is worth reading as a description of how the maintainer works rather than as runtime requirements for the scripts themselves:

checkov>=2.0.618
semgrep>=0.78.0
pylint>=1.9.5
sqlfluff>=3.2.2
yamllint>=1.15.0

Almost nothing there is needed to run a Bash script. Checkov and Semgrep are infrastructure-as-code and code security scanners, SQLFluff lints SQL, yamllint lints YAML, and pylint is there for the companion Python tools project. What the list really documents is that the maintainer runs a security and lint pass over everything in the repository, which for a collection of scripts that handle credentials is a reasonable position to take.

The rest of the file is commented decisions rather than package names: a Git remote helper for AWS CodeCommit is commented out, and the macOS-only PyObjc Quartz framework is commented out with a note that it moved to a separate macOS package list.

The presence of `.pre-commit-config.yaml`, `.pylintrc`, `.sonarcloud.properties` and `.trivyignore` at the root, plus Semgrep and Checkov, means the scripts pass through static analysis before they land. For scripts you are going to copy into production infrastructure, that tooling is more relevant than most of what the README badge row advertises.

CI configuration for six or seven platforms at once

The root of the repository is covered in CI definitions, and the list explains why the project has a `STATUS.md` and a `DOCKER_STATUS.md`. There is `.appveyor.yml` for Windows, `azure-pipelines.yml` for Azure DevOps, `bitbucket-pipelines.yml` for BitBucket, `.circleci/` for CircleCI, `.buildkite/` for Buildkite, `.drone.yml` for Drone, `.gitlab-ci.yml` for GitLab, `.semaphore/` for Semaphore, `.cirrus.yml` for Cirrus, and a `Jenkinsfile` for Jenkins. The README also advertises Concourse readiness with a badge.

Supporting that is the usual lint configuration: `.editorconfig`, `.hound.yml` for Hound, `.mdl.rb` and `.mdlrc` for markdown linting, `.pylintrc` for the Python companion code, and a `.pre-commit-config.yaml`.

This is not vanity. A repository whose scripts have to work on a developer's laptop, in a Docker container, and inside someone else's pipeline ends up testing on all of those, and the CI definitions are the evidence that the scripts are actually exercised on more than one platform. There is also a `Gemfile` at the root for the Ruby-based markdown lint tooling.

One oddity in the release history is worth noting: the only published release is tagged `ccmenu` from 2019-10-16, described as a CCMenu plist file. That is not a release of the script library. This project releases through Git history, and there is no versioned artifact to pin, which is the main practical difference between this collection and an ordinary package.

What the README is and is not useful for

The README for this project opens with badges and stays in that register for a long stretch: stars, forks, line count, license, code quality services including Codacy, CodeFactor and a set of SonarCloud ratings for maintainability, reliability, security and vulnerabilities, then platform badges for Linux and Mac, a Docker Hub badge, and a run of distribution badges for Homebrew, Alpine, CentOS, Debian, Fedora, Red Hat, Rocky and Ubuntu.

The Docker badge points at a published image, `harisekhon/bash-tools` on Docker Hub, which is the distribution route that matters if you want the environment rather than the scripts. The StarTrack badge links to a cross-repository chart, and the README points at a separate Jenkinsfile and at the author's CI builds overview page.

What is missing is the thing you would look for first: no table of scripts, no usage examples, no description of the common calling convention that a thousand standalone scripts must share, and no statement of which shell versions are supported. The README contains commented-out badge experiments and a note about BitBucket exposing HTML comments, which tells you it is a working file rather than a curated front page.

The homepage field on this repository points at the author's LinkedIn profile rather than at documentation, so there is no project site to fall back on. If you want to know whether a specific provider is covered, the honest method is to search the repository directory listing, not to read the README.

When a script collection beats a real tool

The honest comparison here is against the thing the scripts are named after: the official CLI of whichever platform you are automating. If you need to work with AWS at all, the AWS CLI is already installed on most machines that have AWS credentials, it is documented, it has subcommand help, and its output is stable enough to parse. A Bash script that wraps an API call the CLI already covers is more code to maintain and one more thing to audit when credentials change.

Where the collection genuinely wins is in the gaps. API versions that a CLI lags behind, provider-specific service calls with no first-class subcommand, quick one-off diagnostics, and the accumulated knowledge of what actually works when you run the same sequence of commands repeatedly. Those are cases where a script you can read in thirty seconds beats documentation you have to search for.

The other axis is portability, and here the scripts are honest about their limits. They assume Bash rather than POSIX sh, they assume GNU-style tools in many cases, and they assume a Unix-like environment even though the repository has AppVeyor configuration for Windows. Shellcheck-and-CI is as far as portability goes. Anything you take from here and put into a script that runs on macOS and in a minimal Alpine container should be tested in both.

For the dotfiles half, the comparison is your own existing dotfiles. If you already have a tuned shell setup, symlinking this repository's `.bashrc` over it is a downgrade. If you are standing up a new machine or a container image, it is a legitimate shortcut that also happens to be a good reference for what a well-organised `.bash.d/` structure looks like.

Editorial conclusion

Read this repository as a reference library rather than a tool you adopt. The individual scripts earn their keep when you are writing your own automation and want to see how someone else handled a specific API call, and the dotfiles half is a genuine time saver for a machine you are configuring from scratch. Installing the whole thing into a working environment is a different proposition, because `make link` symlinks the repository's config files into your home directory and edits your bash profile to source them. Start with `Library/` and `bin/` as a library, and treat `make install` as something to read before running rather than something to run first.

Frequently asked questions

Official sources

1. HariSekhon/DevOps-Bash-tools on GitHub
2. License: MIT
3. Project website
4. README
5. Releases