Templates to write better Bash scripts
Go to file
Kevin van Zonneveld 18525f72da Make the license less restrictive. See #14 (#28)
* Make the license less restrictive. See #14

So that people can use _just_ main.sh without bothering with also
distributing the license

* Add license update to changelog

* Add a comment about expansion, see #26

* Use an unmodified MIT License, with the more permissive clause inside the code

As modifying the MIT License will needlessly (but rightfully) cause
suspicion

* Credit @bravo-kernel for his feedback

* Fix another typo

* Reword copyright
2016-06-20 09:57:31 +02:00
src Make the license less restrictive. See #14 (#28) 2016-06-20 09:57:31 +02:00
test Fix test again, now that we got confirmed failures out of Travis OSX #10 2016-02-23 10:21:43 +01:00
.gitignore Add tests for templater and follow Library export best practices 2016-02-17 13:19:03 +01:00
.travis.yml Better versioning 2016-02-17 09:35:59 +01:00
CHANGELOG.md Make the license less restrictive. See #14 (#28) 2016-06-20 09:57:31 +02:00
FAQ.md Whitespace 2016-03-03 12:41:55 +01:00
LICENSE Make the license less restrictive. See #14 (#28) 2016-06-20 09:57:31 +02:00
main.sh Make the license less restrictive. See #14 (#28) 2016-06-20 09:57:31 +02:00
Makefile Set up basic acceptance testing #4 2016-02-16 15:01:26 +01:00
package.json Commit version info next time 2016-02-17 13:43:00 +01:00
README.md Make the license less restrictive. See #14 (#28) 2016-06-20 09:57:31 +02:00

Build Status

Overview

When hacking up Bash scripts, I often find there are some higher level things like logging, configuration, command-line argument parsing that:

  • I need every time
  • Take quite some effort to get right
  • Keep you from your actual work

Here's an attempt to bundle those things in a generalized way so that they are reusable as-is in most of my (and hopefully your, if not ping me) programs.

Goals

Delete-key-friendly. I propose using main.sh as a base and removing the parts you don't need, rather than introducing a ton of packages, includes, compilers, etc.

Aiming for portability, I'm targeting Bash 3 (OSX still ships with 3 for instance). If you're going to ask people to install Bash 4 first, you might as well pick a more advanced language as a dependency.

We're automatically testing bash3boilerplate and it's proven to work on:

  • Linux GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
  • OSX GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)

Features

  • Structure
  • Safe defaults (break on error, pipefail, etc)
  • Configuration by environment variables
  • Configuration by command-line arguments (definitions parsed from help info, so no duplication needed)
  • Magic variables like __file and __dir
  • Logging that supports colors and is compatible with Syslog Severity levels

Installation

There are 3 ways you can install (parts of) b3bp:

  1. Just get the main template: wget https://raw.githubusercontent.com/kvz/bash3boilerplate/master/main.sh
  2. Clone the entire project: git clone git@github.com:kvz/bash3boilerplate.git
  3. As of v1.0.3, b3bp can be installed as a package.json dependency via: npm install --save bash3boilerplate

Although 3 introduces a node.js dependency, this does allow for easy version pinning and distribution in environments that already have this prerequisite. But nothing prevents you from just using curl and keep your project or build system low on external dependencies.

Changelog

Please see the CHANGELOG.md file.

Best practices

As of v1.0.3, b3bp adds some nice re-usable libraries in ./src. Later on we'll be using snippets inside this directory to build custom packages. In order to make the snippets in ./src more useful, we recommend these guidelines.

Library exports

It's nice to have a bash package that can be used in the terminal and also be invoked as a command line function. To achieve this the exporting of your functionality should follow this pattern:

if [ "${BASH_SOURCE[0]}" != ${0} ]; then
  export -f my_script
else
  my_script "${@}"
  exit $?
fi

This allows a user to source your script or invoke as a script.

# Running as a script
$ ./my_script.sh some args --blah
# Sourcing the script
$ source my_script.sh
$ my_script some more args --blah

(taken from the bpkg project)

Miscellaneous

  • In functions, use local before every variable declaration
  • This project settles on two spaces for tabs

Frequently Asked Questions

Please see the FAQ.md file.

Authors

Sponsoring

Flattr donate button

License

Copyright (c) 2013 Kevin van Zonneveld and contributors Licensed under MIT You are not obligated to bundle the LICENSE file with your b3bp projects as long as you leave these references intact.