91–100 of 129 posts
I learnt the same trick some years ago, from an article called Shell Scripts Matter : https://dev.to/thiht/shell-scripts-matter So I took some of the advice and tips offered in there, and wrote a template file to be used as a baseline when writing scripts for any project that might need one: https://github.com/j1elo/shell-snippets/blob/master/template... Other resources that I link in the readme of that repo, because…
Thank you for this really helpful comment. It's like an encyclopedia's worth of bash information in one go--much appreciated.
People say that for complex things it's better to write Python, but that doesn't fly in embedded or Docker environments. Python is not even present in the default Ubuntu Docker images. Also if all you want to do is really write glue code between CLI programs, shell scripting is the way to go.
Happy coding!
You can also use a "here document" help() { cat Options: Input file to read. Output file to write. Use '-' for stdout. -h Show this message. EOH } If the indentation bugs you, you can use a simpler sed trick to remove leading space so that you can indent it as desired: help() { sed -e 's/ //' Options: Input file to read. Output file to write. Use '-' for stdout. -h Show this message. EOH }
I learnt the same trick some years ago, from an article called Shell Scripts Matter : https://dev.to/thiht/shell-scripts-matter So I took some of the advice and tips offered in there, and wrote a template file to be used as a baseline when writing scripts for any project that might need one: https://github.com/j1elo/shell-snippets/blob/master/template... Other resources that I link in the readme of that repo, because…
https://twitter.com/hellsmaddy/status/1273744824835796993?s=...
Tl;dr use `shopt -s inherit_errexit`
Why is “./script.sh -h” better than “less script.sh”?
Do you ever collect families of functions in your shell scripts under different sections? Here's a nice way of printing out all the functions under a given section:
funs(){ sed -n '/^## /h;x;/'"$1"'/{x;s/^\(\w\+\)().*/\1/p;x};x' "$0";}
$ foo.sh bar baz
usage=$(cat
Subcommands: $(funs Subcommands)
USAGE
)
funs(){ sed -n '/^## /h # Store header line in hold space
x # Swap out current line with header in hold space.
/'"$1"'/{ # Run block if last encountered header matches $1
x # Return to processing current line (instead of header)
s/^\(\w\+\)().*/\1/p # Print function names
x # Whether or not this block runs, we want to return to
# processing the current line. If the block does not
# run, then the hold space contains our current line
# with the active line being our header. So we must
} # return to that state as whell when the block is run.
x # Restore current line from hold space' "$0"
}You can also use a "here document" help() { cat Options: Input file to read. Output file to write. Use '-' for stdout. -h Show this message. EOH } If the indentation bugs you, you can use a simpler sed trick to remove leading space so that you can indent it as desired: help() { sed -e 's/ //' Options: Input file to read. Output file to write. Use '-' for stdout. -h Show this message. EOH }
Or just a multiline string: #!/bin/bash USAGE="my-script — does one thing well Usage: my-script Options: Input file to read. Output file to write. Use '-' for stdout. -h Show this message. " help() { echo "$USAGE" } This is my standard approach which is cleaner for putting the documentation at the very top of the file like the linked article.
Earlier quoted context omitted.
But handling args isn't that bad in bash. while [[ $# -gt 0 ]]; do case "$1" in -h|--help) do_help exit ;; -v|--version) do_version exit ;; -d|--debug) debug=true shift ;; -a|--arg) arg_value=$2 shift 2 ;; esac done
import argparse parser = argparse.ArgumentParser() parser.add_argument('-v','--version',action='version', version='demo',help='Print version information') parser.add_argument('-d','--debug', help='Enable Debug Mode') parser.add_argument('a','arg', help="Argument Documentation") args = parser.parse_args() Personally I feel like this is more readable code, gets me better validation, and help docs for "free". That's the…
If you can live with additional dependencies, then I like the node [1] commander package, which is very readable and nice to work with in my opinion.
#!/usr/bin/env node
const { program } = require('commander');
program
.command('clone [destination]')
.description('clone a repository')
.action((source, destination) => {
console.log('clone command called');
});
Why is “./script.sh -h” better than “less script.sh”?
https://github.com/zsh-users/zsh-completions/blob/master/zsh...