{"id":22337280,"url":"https://github.com/mbland/go-script-bash","last_synced_at":"2025-07-12T11:05:38.322Z","repository":{"id":70264114,"uuid":"66173419","full_name":"mbland/go-script-bash","owner":"mbland","description":"Framework for writing modular, discoverable, testable Bash scripts","archived":false,"fork":false,"pushed_at":"2022-11-07T17:46:49.000Z","size":1080,"stargazers_count":97,"open_issues_count":53,"forks_count":16,"subscribers_count":11,"default_branch":"main","last_synced_at":"2024-11-30T10:46:42.013Z","etag":null,"topics":["bash","coverage","modular","portable","scripting","test-coverage","testing","unit-testing"],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"isc","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mbland.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE.md","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2016-08-21T00:05:07.000Z","updated_at":"2024-11-17T02:05:54.000Z","dependencies_parsed_at":"2023-02-25T21:30:19.994Z","dependency_job_id":null,"html_url":"https://github.com/mbland/go-script-bash","commit_stats":null,"previous_names":[],"tags_count":11,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mbland%2Fgo-script-bash","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mbland%2Fgo-script-bash/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mbland%2Fgo-script-bash/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mbland%2Fgo-script-bash/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mbland","download_url":"https://codeload.github.com/mbland/go-script-bash/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":228054464,"owners_count":17862129,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["bash","coverage","modular","portable","scripting","test-coverage","testing","unit-testing"],"created_at":"2024-12-04T06:09:25.470Z","updated_at":"2024-12-04T06:09:27.139Z","avatar_url":"https://github.com/mbland.png","language":"Shell","readme":"## The `./go` script: a unified development environment interface\n\nSource: https://github.com/mbland/go-script-bash\n\n[![Latest release](https://img.shields.io/github/release/mbland/go-script-bash.svg)](https://github.com/mbland/go-script-bash/releases/latest)\n[![License](https://img.shields.io/github/license/mbland/go-script-bash.svg)](https://github.com/mbland/go-script-bash/blob/master/LICENSE.md)\n[![Continuous integration status for Linux and macOS](https://img.shields.io/travis/mbland/go-script-bash/master.svg)](https://travis-ci.org/mbland/go-script-bash)\n[![Continuous integration status for Windows](https://img.shields.io/appveyor/ci/mbland/go-script-bash/master.svg)](https://ci.appveyor.com/project/mbland/go-script-bash)\n[![Coverage Status](https://img.shields.io/coveralls/mbland/go-script-bash/master.svg)](https://coveralls.io/github/mbland/go-script-bash?branch=master)\n\nA `./go` script aims to abstract away many of the steps needed to develop (and\nsometimes deploy) a software project. It is a replacement for READMEs and other\ndocuments that may become out-of-date, and when maintained properly, should\nprovide a cohesive and discoverable interface for common project tasks.\n\nFor a five-minute overview of the framework, see [Mike Bland's go-script-bash\nlightning talk at Surge 2016][go-surge].\n\n[go-surge]: https://youtu.be/WX1vrLV9mFE?t=39m48s\n\n### Table of contents\n\n- [Introduction](#introduction)\n- [Environment setup](#environment-setup)\n- [How to use this framework](#how-to-use-this-framework)\n- [Feedback and contributions](#feedback-and-contributions)\n- [Installing Bash](#installing-bash)\n- [Open Source](#open-source-license)\n- [Prior work](#prior-work)\n\n### Introduction\n#### What's a `./go` script?\n\nThe `./go` script idea came from Pete Hodgson's blog posts [In Praise of the\n./go Script: Part I][hodg-1] and [Part II][hodg-2]. To paraphrase Pete's\noriginal idea, rather than dump project setup, development, testing, and\ninstallation/deployment commands into a `README` that tends to get stale, or\nrely on oral tradition to transmit project maintenance knowledge, automate these\ntasks by encapsulating them all inside a single script in the root directory of\nyour project source tree, conventionally named \"`go`\". Then the interface to\nthese tasks becomes something like `./go setup`, `./go test`, and `./go deploy`.\nNot only would this script save time for people already familiar with the\nproject, but it smooths the learning curve, prevents common mistakes, and lowers\nfriction for new contributors. This is as desirable a state for Open Source\nprojects as it is for internal ones.\n\n[hodg-1]: https://www.thoughtworks.com/insights/blog/praise-go-script-part-i\n[hodg-2]: https://www.thoughtworks.com/insights/blog/praise-go-script-part-ii\n\n#### Is this related to the Go programming language?\n\nNo. The `./go` script convention in general and this framework in particular are\ncompletely unrelated to the [Go programming language][golang]. In fact, the\nactual `./go` script can be named anything. However, the [`go` command from the\nGo language distribution][golang-cmd] encapsulates many common project functions\nin a similar fashion.\n\n[golang]:     https://golang.org\n[golang-cmd]: https://golang.org/cmd/go/\n\n#### Why write a framework?\n\nOf course, the danger is that this `./go` script may become as unwieldy as the\n`README` it's intended to replace, depending on the project's complexity. Even\nif it's heavily used and kept up-to-date, maintenance may become an intensive,\nfrightening chore, especially if not covered by automated tests. Knowing what\nthe script does, why it does it, and how to run it may become more and more\nchallenging—resulting in the same friction, confusion, and fear the script was\ntrying to avoid.\n\nThe `./go` script framework makes it easy to provide a uniform and easy-to-use\nproject maintenance interface that fits your project perfectly regardless of the\nmix of tools and languages, then it gets out of the way as fast as possible. The\nhope is that by [making the right thing the easy thing][right-thing-easy],\nscripts using the framework will evolve and stay healthy along with the rest of\nyour project sources, which makes everyone working with the code less frustrated\nand more productive all-around.\n\n[right-thing-easy]: https://mike-bland.com/2016/06/16/making-the-right-thing-the-easy-thing.html\n\nThis framework accomplishes this by:\n\n* encouraging modular, composable `./go` commands implemented as individual\n  scripts—in the language of your choice!\n* providing a set of builtin utility commands and shell command aliases—see\n  `./go help builtins` and `./go help aliases`\n* supporting automatic tab-completion of commands and arguments through a\n  lightweight API—see `./go help env` and `./go help complete`\n* implementing a quick, flexible, robust, and convenient documentation\n  system—document your script in the header, and help shows up automatically as\n`./go help my-command`! See `./go help help`.\n\nPlus, its own tests serve as a model for testing command scripts of all shapes\nand sizes.\n\nThe inspiration for this model (and initial implementation hints) came from [Sam\nStephenson's `rbenv` Ruby version manager][rbenv].\n\n[rbenv]: https://github.com/rbenv/rbenv\n\n#### Why Bash?\n\n[It's the ultimate backstage pass!][backstage] It's the default shell for most\nmainstream UNIX-based operating systems, easily installed on other UNIX-based\noperating systems, and is readily available even on Windows.\n\n[backstage]: http://www.imdb.com/title/tt0118971/quotes?item=qt1467557\n\n#### Will this work on Windows?\n\nYes. It is an explicit goal to make it as easy to use the framework on Windows\nas possible. Since [Git for Windows][git-win] in particular ships with Bash as\npart of its environment, and Bash is available within Windows 10 as part of the\n[Windows Subsystem for Linux][wsl] (Ubuntu on Windows), it's more likely than\nnot that Bash is already available on a Windows developer's system. It's also\navailable from the [MSYS2][] and [Cygwin][] environments.\n\n[git-win]: https://git-scm.com/downloads\n[wsl]:     https://msdn.microsoft.com/en-us/commandline/wsl/about\n[msys2]:   https://msys2.github.io/\n[cygwin]:  https://www.cygwin.com/\n\n#### Why not use tool X instead?\n\nOf course there are many common tools that may be used for managing project\ntasks. For example: [Make][], [Rake][], [npm][], [Gulp][], [Grunt][], [Bazel][],\nand the Go programming language's `go` tool.  There are certainly more powerful\nscripting languages: [Perl][], [Python][], [Ruby][], and even [Node.js][nodejs]\nis a possibility. There are even more powerful shells, such as the\n[Z-Shell][zsh] and the [fish shell][fish].\n\n[make]:   https://www.gnu.org/software/make/manual/\n[rake]:   http://rake.rubyforge.org/\n[npm]:    https://docs.npmjs.com/\n[gulp]:   http://gulpjs.com/\n[grunt]:  http://gruntjs.com\n[bazel]:  https://www.bazel.io/\n[perl]:   https://www.perl.org/\n[python]: https://www.python.org/\n[ruby]:   https://www.ruby-lang.org/en/\n[nodejs]: https://nodejs.org/\n[zsh]:    https://www.zsh.org/\n[fish]:   https://fishshell.com/\n\nThe `./go` script framework isn't intended to replace all those other tools and\nlanguages, but to make it easier to use each of them for what they're good for.\nIt makes it easier to write good, testable, maintainable, and extensible shell\nscripts so you don't have to push any of those other tools beyond their natural\nlimits.\n\nBash scripting is _really good_ for automating a lot of traditional command line\ntasks, and it can be pretty awkward to achieve the same effect using other\ntools—especially if your project uses a mix of languages, where using a tool\ncommon to one language environment to automate tasks in another can get weird.\n(Which is part of the reason why there are so many build tools tailored to\ndifferent languages in the first place, to say nothing of the different\nlanguages themselves.)\n\nIf you want to incorporate different scripting languages or shells into your\nproject maintenance, this framework makes it easy to do so. However, by starting\nwith Bash, you can implement a `./go init` command to check that these other\nlanguages or shells are installed and either install them automatically or\nprompt the user on how to do so. Since Bash is (almost certainly) already\npresent, users can run your `./go` script right away and get the setup or hints\nthat they need, rather than wading through system requirements and documentation\nbefore being able to do anything.\n\nEven if `./go init` tells the user \"go to this website and install this other\nthing\", that's still an immediate, tactile experience that triggers a reward\nresponse and invites further exploration. (Think of [Zork][] and the first\n[\"open mailbox\"][zork-open] command.)\n\n[zork]:      https://en.wikipedia.org/wiki/Zork\n[zork-open]: http://steel.lcc.gatech.edu/~marleigh/zork/transcript.html\n\n#### Where can I run it?\n\nThe real question is: Where _can't_ you run it?\n\nThe core framework is written 100% in [Bash][bash-wikipedia] and it's been\ntested under Bash 3.2, 4.2, 4.3, and 4.4 across OS X, Ubuntu Linux, Arch Linux,\nAlpine Linux, FreeBSD 9.3, FreeBSD 10.3, and Windows 10 (using all the\nenvironments described in the \"Will this work on Windows?\" section above).\n\n[bash-wikipedia]: https://en.wikipedia.org/wiki/Bash_%28Unix_shell%29\n\n#### Can I use it to write standalone programs that aren't project scripts?\n\nActually, yes. See the [Standalone mode](#standalone-mode) section below.\n\nAlso see the following question...\n\n#### Can I have more than one ./go script in the same project source tree?\n\nYes. You can share one copy of the go-bash-framework sources, and even have\ncommon code in the `lib/` directory, but set each script to use its own command\nscripts dir.\n\nThis may be especially useful if you're writing a [standalone](#standalone-mode)\nprogram, in which one script provides the actual program interface, and the\nother provides the development-only interface.\n\n#### How is it tested?\n\nThe project's own `./go test` command does it all. Combined with automatic\ntab-completion enabled by `./go env` and pattern-matching via `./go glob`, the\n`./go test` command provides a convenient means of selecting subsets of test\ncases while focusing on a particular piece of behavior. (See `./go help test`.)\n\nThe tests are written using [mbland/bats, an optimized version of Sam\nStephenson's Bash Automated Testing System (BATS)][mbland/bats]. Code coverage\ncomes from [Simon Kagstrom's `kcov` code coverage tool][kcov], which not only\nprovides code coverage for Bash scripts (!!!) but can push the results to\n[Coveralls][cover-gos]!\n\n[mbland/bats]: https://github.com/mbland/bats\n[kcov]:        https://github.com/SimonKagstrom/kcov\n[cover-gos]:   https://coveralls.io/github/mbland/go-script-bash\n\n### Environment setup\n\nTo run a `./go` script that uses this module, or to add it to your own project,\nyou must have [Bash][bash-wikipedia] version 3.2 or greater installed on your\nsystem. Run `bash --version` to make sure Bash is in your `PATH` and is a\ncompatible version. You should see output like this:\n\n```\nGNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)\nCopyright (C) 2007 Free Software Foundation, Inc.\n```\n\nIf you do not see this, follow the instructions in the [Installing\nBash](#installing-bash) section later in this document.\n\n__Note: While Bash is required to run this framework, your individual command\nscripts can be in any other interpreted language installed on the host system.__\n\n### How to use this framework\n\nFirst you'll need a copy of this framework available in your project sources.\nThe most expedient way to bootstrap your program is to use the [`go-template`\nfile][go-template] as a starting point (replacing [curl][] with [wget][],\n[fetch][], or whichever tool you prefer):\n\n[go-template]: https://github.com/mbland/go-script-bash/blob/master/go-template\n[curl]:        https://curl.haxx.se/\n[wget]:        https://www.gnu.org/software/wget/\n[fetch]:       https://www.freebsd.org/cgi/man.cgi?fetch(1)\n\n```bash\n$ curl https://raw.githubusercontent.com/mbland/go-script-bash/master/go-template \u003e./go\n$ chmod ugo+rx ./go\n```\n\nYou may rename this file whatever you wish (i.e. it doesn't have to be named\n`./go`), update its documentation and variables to fit your project, and check\nit into your project repository. See the `go-template` comments for details.\n\nIf you'd prefer to download a copy of the framework and check it into your\nsources, versioned archives are available from the [go-script-bash Releases\npage][go-rel]. The archives for the current release are:\n\n[go-rel]: https://github.com/mbland/go-script-bash/releases\n\n- https://github.com/mbland/go-script-bash/archive/v1.7.0.tar.gz\n- https://github.com/mbland/go-script-bash/archive/v1.7.0.zip\n\nYou can also add this repository to your project as a [Git submodule][git-sub]:\n\n[git-sub]: (https://git-scm.com/book/en/v2/Git-Tools-Submodules)\n\n```bash\n$ git submodule add https://github.com/mbland/go-script-bash \u003ctarget-dir\u003e\n$ git commit -m 'Add go-script-bash framework'\n$ git submodule update --init\n```\n\nwhere `\u003ctarget-dir\u003e` is any point inside your project directory structure that\nyou prefer.\n\nIf you're not using `go-template`, create a bash script in the root directory of\nyour project to act as the main `./go` script. This script need not be named\n`go`, but it must contain the following lines, with `@go \"$@\"` as the last line\nof the script:\n\n```bash\n. \"${0%/*}/go-core.bash\" \"scripts\"\n@go \"$@\"\n```\n\nwhere:\n- `${0%/*}` produces the path to the project's root directory based on the path\n  to the `./go` script\n- `${0%/*}/go-core.bash` produces the path to the framework's `go-core.bash`\n  file within your project's copy of the framework (adjusted to reflect where\n  your copy of `go-script-bash` actually resides)\n- `scripts` is the path to the directory holding your project's command scripts\n  relative to the project root (it can be any name you like)\n\n#### Directory structure\n\nThe `./go` script changes to the project root directory before executing any\ncommands. That means every command script you write will also run within the\nproject root directory, so every relative file and directory path will be\ninterpreted as relative to the project root.\n\nYour project structure may look something like this:\n\n```\nproject-root/\n  go - main ./go script\n  lib/ - publicly-exported modules (if the project is a go-bash-script plugin)\n  scripts/ (or bin/) - project (or plugin) ./go command scripts\n    lib/ - project-specific Bash library modules (see \"Modules\" section)\n    plugins/ - (optional) third-party command scripts (see `./go help plugins`)\n      .../\n        bin/ - plugin ./go command scripts\n        lib/ - publicly-exported Bash library modules (see \"Modules\" section)\n    go-script-bash/\n      go-core.bash - top-level functions\n      lib/ - publicly-exported Bash library modules (see \"Modules\" section)\n      libexec/ - builtin ./go command scripts\n```\n\nThis structure implies that the first line of your `./go` script will be:\n```bash\n. \"${0%/*}/scripts/go-script-bash/go-core.bash\" \"scripts\"\n```\n\n#### Variables and plugin scoping\n\nThe following variables are set by the framework based on the above example\n(note there are many other variables set in `go-core.bash` and elsewhere; see\n`./go help vars`):\n\n* `_GO_ROOTDIR`: `/absolute/path/to/project-root`\n* `_GO_CORE_DIR`: `/absolute/path/to/project-root/scripts/go-script-bash`\n* `_GO_SCRIPTS_DIR`: `$_GO_ROOTDIR/scripts`\n* `_GO_PLUGINS_DIR`: `/absolute/path/to/project-root/plugins`\n\nFor plugins, `_GO_ROOTDIR` and `_GO_SCRIPTS_DIR` will be scoped to the root\ndirectory of the plugin installation; the other variables will remain the same.\nSee `./go help plugins` for more details.\n\n#### Command scripts\n\nEach command script for your project residing in the `scripts` directory must\nadhere to the following conditions:\n\n- No filename extensions.\n- It must be executable, with a `#!` (a.k.a. \"she-bang\") line. The interpreter\n  name will be parsed from this line, whether it is an absolute path\n  (`#!/bin/bash`) or is of the form: `#!/usr/bin/env bash`.\n- If `scripts/parent` is a command script, subcommand scripts must reside within\n  a directory named: `scripts/parent.d`.\n\n__Scripts can use any interpreted language available on the host system; they\nneed not be written in Bash.__ Bash scripts will be sourced (i.e. imported into\nthe same process running the `./go` script itself). Other languages will use the\n`PATH` environment variable to discover the interpreter for the script.\n\nSee `./go help commands` for details on the algorithm used to discover command\nscripts for execution.\n\n#### Command summaries and help text\n\nThe builtin `./go help` command will parse command script summaries and help\ntext from the header comment block of each script. Run `./go help help` to learn\nmore about the formatting rules.\n\n#### Tab completion\n\nBy evaluating the value of `./go env -` within your shell, all builtin commands\nand aliases provide automatic tab completion of file, directory, and other\narguments. If an implementation isn't available for your shell (within\n`lib/internal/env/`), it's very easy to add one. Feel free to open an issue or,\nbetter yet, [send a pull request](#feedback-and-contributions)!\n\nTo learn the API for adding tab completion to your own command scripts, run\n`./go help complete`. You can also learn by reading the scripts for the builtin\ncommands.\n\n#### Standalone mode\n\nIf you wish to use the framework to write a standalone program, rather than a\nproject-specific development script, set `_GO_STANDALONE` in your top-level\nscript to prevent alias commands, builtin commands, and plugin commands from\nshowing up in `help` output or from being offered as tab completions. (`help`\nwill still appear as a top-level tab completion.) All of these commands will\nstill be available, but users won't be presented with them directly.\n\n`_GO_STANDALONE` also prevents the script from setting `PWD` to `_GO_ROOTDIR`,\nenabling the script to process relative file path arguments anywhere in the file\nsystem. Note that then you'll have to add `_GO_ROOTDIR` manually to any\n`_GO_ROOTDIR`-relative paths in your own scripts.\n\n#### Including common code\n\nThere are a number of possible methods available for sharing code between\ncommand scripts. Some possibilities are:\n\n- The generally preferred method is to use `. $_GO_USE_MODULES` to source\n  optional library modules; see the [Modules](#modules) section.\n- Include common code and constants in the top-level `./go` script, after\n  sourcing `go-core.bash` and before calling `@go`.\n- Source a file in the same directory that isn't executable.\n- Source a file in a child directory that may not have a name of the form:\n  `parent.d`.\n- Source files from a dedicated directory relative to `$_GO_ROOTDIR`, e.g.:\n  ```bash\n  . \"path/to/lib/common.sh\"\n  ```\n- Subcommand scripts can source the parent command via:\n  ```bash\n  . \"${BASH_SOURCE[0]%.d/*}\"\n  ```\n\n#### Command script API\n\nAny script in any language can invoke other command scripts by running\n`./go \u003ccommand\u003e [args..]`. In Bash, however, you can also invoke the `@go`\nfunction directly as `@go \u003ccommand\u003e [args...]`.\n\nThe `@go`, `@go.printf`, and `@go.print_stack_trace` functions are available to\ncommand scripts written in Bash, as Bash command scripts are sourced rather than\nrun using another language interpreter.\n\nA number of global variables defined and documented in `go-core.bash`, all\nstarting with the prefix `_GO_`, are exported as environment variables and\navailable to scripts in all languages (along with the global `COLUMNS`\nenvironment variable). Run `./go vars` to see them all along with their values,\nand run `./go help vars` for more details.\n\n#### Plugins\n\nYou can add third-party plugin command scripts to the `plugins` subdirectory of\nyour scripts directory. Run `./go help plugins` for more information.\n\n#### Modules\n\nYou can import optional Bash library code from the core framework, third-party\nplugins, or your own project's scripts directory by sourcing the\n`_GO_USE_MODULES` script. For example, to import the core logging utilities:\n\n```bash\n. \"$_GO_USE_MODULES\" 'log'\n```\n\nRun `./go help modules` and `./go modules --help` for more information.\n\n#### Logging\n\nThe core library `log` module provides functions for standard logging\nfacilities. For example:\n\n```bash\n@go.log INFO Hello, World!\n@go.log ERROR Goodbye, World!\n```\n\nFor more information, run `./go modules --help log`.\n\n#### Bats test assertions and helpers\n\nThe assertions and helpers from the test suite have been extracted into the\n`lib/bats` libraries. While these are not modules you can import with\n`_GO_USE_MODULES`, they are completely independent of the rest of the core\nframework and you may source them in your own Bats tests. (Whether or not these\nwill ever become a separate library remains an open question.)\n\nVariables, helper functions, and assertions for testing features based on the\ncore framework are available in the `lib/testing` directory. The `lib/bats-main`\nlibrary makes it easy to write a `./go test` command script with the same\ninterface and features as the core framework's `./go test` command.\n\nRead the comments from each file for more information.\n\n#### `kcov-ubuntu` module for test coverage on Linux\n\nThe `kcov-ubuntu` module provides the `run_kcov` function that will download and\ncompile [kcov][], then run `kcov` with the original `./go` command line\narguments to collect test coverage. Only available on Ubuntu Linux for now,\nhence the name. Run `./go modules --help kcov-ubuntu` for more information and\nsee `scripts/test` for an example of how it may be used.\n\n### Feedback and contributions\n\nFeel free to [comment on or file a new GitHub issue][issues] or otherwise ping\n[@mbland][] with any questions or comments you may have, especially if the\ncurrent documentation hasn't addressed your needs.\n\n[issues]: https://github.com/mbland/go-script-bash/issues\n[@mbland]: https://github.com/mbland\n\nIf you'd care to contribute to this project, be it code fixes, documentation\nupdates, or new features, please read the [CONTRIBUTING](CONTRIBUTING.md) file.\n\n### Installing Bash\n\nIf you're using a flavor of UNIX (e.g. Linux, OS X), you likely already have a\nsuitable version of Bash already installed and available. If not, use your\nsystem's package manager to install it.\n\nOn Windows, the [Git for Windows][git-win], [MSYS2][] and [Cygwin][]\ndistributions all ship with a version of Bash. On Windows 10, you can also use\nthe [Windows Subsystem for Linux][wsl].\n\n#### Updating your `PATH` environment variable\n\nOnce you've installed `bash`, your `PATH` environment variable must include\nits installation directory. On UNIX, you can add it in the appropriate\ninitialization file for your shell; look up your shell documentation for details.\n\nOn Windows, in most cases, you'll use the terminal program that ships with Git\nfor Windows, MSYS2, or Cygwin, or you'll invoke the Windows System for Linux\nenvironment by entering `bash` in a built-in Command Prompt window. These\nterminals automatically set `PATH` so that Bash is available.\n\nHowever, if you want to use the Git, MSYS2, or Cygwin `bash` from the built-in\nCommand Prompt window, open the **Start** menu and navigate to **Windows\nSystem \u003e Control Panel \u003e System and Security \u003e System \u003e Advanced system\nsettings**. Click the **Environment Variables...** button, select `PATH`, and\nadd the directory containing your `bash` installation. The likely paths for each\nenvironment are:\n\n- Git: `C:\\Program Files\\Git\\usr\\bin\\`\n- MSYS2: `C:\\msys64\\usr\\bin\\`\n- Cygwin: `C:\\cygwin64\\bin\\`\n\nTo use one of these paths temporarily within a Command Prompt window, you can\nrun the following:\n\n```\nC:\\path\\to\\my\\go-script-bash\u003e set PATH=C:\\Program Files\\Git\\usr\\bin\\;%PATH%\n\n# To verify:\nC:\\path\\to\\my\\go-script-bash\u003e echo %PATH%\nC:\\path\\to\\my\\go-script-bash\u003e where bash\n\n# To run the tests:\nC:\\path\\to\\my\\go-script-bash\u003e bash ./go test\n```\n\nIt should not be necessary to set Bash as your default shell. On Windows,\nhowever, you may wish to execute the `bash` command to run it as your shell\nbefore executing the `./go` script or any other Bash scripts, to avoid having to\nrun it as `bash ./go` every time.\n\n#### Recommended utilities\n\nMost of the framework as-is does not require any other external tools. However,\nin order for the automatic command help and output formatting to work, you'll\nneed the following utilities installed:\n\n- `tput` (ncurses) on Linux, OS X, UNIX\n- `mode.com` should be present on Windows\n\nTo use the `get file` builtin, either `curl`, `wget`, or `fetch` must be\ninstalled on your system. `get git-repo` requires `git`, naturally.\n\n### Open Source License\n\nThis software is made available as [Open Source software][oss-def] under the\n[ISC License][].  For the text of the license, see the [LICENSE](LICENSE.md)\nfile.\n\n[oss-def]:     https://opensource.org/osd-annotated\n[isc license]: https://www.isc.org/downloads/software-support-policy/isc-license/\n\n### Prior work\n\nThis is a Bash-based alternative to the [18F/go_script][go-old] Ruby\nimplementation.\n\n[go-old]: https://github.com/18F/go_script\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmbland%2Fgo-script-bash","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmbland%2Fgo-script-bash","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmbland%2Fgo-script-bash/lists"}