By who? Why?
This is the version that I’ve always used:
https://manpages.debian.org/buster/util-linux/getopt.1.en.ht...
11–20 of 54 posts
By who? Why?
This is the version that I’ve always used:
https://manpages.debian.org/buster/util-linux/getopt.1.en.ht...
Quite an impressive project all things considered; definitely something to keep in mind for the next project that inevitably starts out as a simple Bash script. Out of curiosity: if you (the reader) get to a point where you need more complicated and esoteric functionality that Bash can provide, do you still keep hammering at it or turn to a more capable (and readable) language? Just wondering if people are usually wo…
It's a trade-off. Especially if the script contains a lot of pipes and redirection, it's difficult to reproduce with the same elegance in something like Python. My biggest successes have been extracting these parts into very small stand-alone shell scripts which the Python application then invokes, which gives you the best of both worlds. The best example off the top of my head is `mysqldump | sed ... | gzip` with de…
I’m curious if you’ve tried the sh Python module [1]. In some ways it’s much prettier to read although the initial writing of it can be awkward to get used to at first.
Quite an impressive project all things considered; definitely something to keep in mind for the next project that inevitably starts out as a simple Bash script. Out of curiosity: if you (the reader) get to a point where you need more complicated and esoteric functionality that Bash can provide, do you still keep hammering at it or turn to a more capable (and readable) language? Just wondering if people are usually wo…
As soon as as the cli becomes non-trivial I switch to python and use docopt for that (really cool module btw.). Pipelining processes is not as idiomatic in Python as it is in Bash though, but everything is better than getopts. I'd rather decapitate myself with a teaspoon than using getopts.
Quite an impressive project all things considered; definitely something to keep in mind for the next project that inevitably starts out as a simple Bash script. Out of curiosity: if you (the reader) get to a point where you need more complicated and esoteric functionality that Bash can provide, do you still keep hammering at it or turn to a more capable (and readable) language? Just wondering if people are usually wo…
I've tried that path with little success. Usually, arg parsing makes me try some other language (perl, python) but other things got complicated there, mostly running other processes, capturing their exit status, pipe-ing their output etc. In the end, it was easier to hammer onto bash. Also, there are great linters for bash scripts, so things work out.
Note that Python's subprocess module [0] has received many updates since v3.5, and now I find it relatively painless. Most of the times, subprocess.check_output() or subprocess.run() will do the trick.
writing bash scripts in general just isn't a fun experience.
years ago, i started just writing ruby scripts for execution in the terminal instead of bash, and haven't had any problems with it so far.
I'm probably going to get downvoted for this, but: writing bash scripts in general just isn't a fun experience. years ago, i started just writing ruby scripts for execution in the terminal instead of bash, and haven't had any problems with it so far.
Though in generqal I always thought Bash scripting to be fun, due to the wide array of programs available that you can directly invoke in your scripts script. The feeling of gluing programs together with pipes into a larger abstraction is just amazing, and bash does that very elegantly.
Quite an impressive project all things considered; definitely something to keep in mind for the next project that inevitably starts out as a simple Bash script. Out of curiosity: if you (the reader) get to a point where you need more complicated and esoteric functionality that Bash can provide, do you still keep hammering at it or turn to a more capable (and readable) language? Just wondering if people are usually wo…
It depends. Sometimes you use these tools because they are already responsible for so much stuff it makes sense to just extend it no matter how crazy it is (Chrome Os build tool was built as hundreds of lines of shell script which built on top of portage which is even more hundred of lines of shell script) ... sometimes it’s because that’s the tool you know will be available (the dozens of bootstrap scripts I’ve beaten crushed and smashed into makefiles complete with OS detection and other stuff) ... and sometimes you don’t have any read you just do it because it’s what your comfortable thinking in. I’ve definitely written bash scripts that would have been better in Python but at the time my mind was building the script up as a sequence of Unix tool operations and pipelines not as a Python program.
I wrote a much less full featured and less ergonomic library that targets sh rather than bash. It was 70 lines of shell including whitespace.
Here's an example of its usage[1]. Each option calls a function, optionally with an argument. There is also sugar for options that merely toggle a value.
Non flag parameters call a function "positional parameter" to avoid a dependence on arrays.
It does not generate usage or man pages.
1: https://github.com/jasom/the-copper-searcher/blob/master/opt...
> getopt is discouraged By who? Why? This is the version that I’ve always used: https://manpages.debian.org/buster/util-linux/getopt.1.en.ht...
Edit: Send error messages to stderr
Edit2: People seem to like it. I created a GitHub gist for it here: https://gist.github.com/bxparks/e67a3d6fc6b5d62b51304b3d9de2...
#!/bin/bash
set -eu
function usage() {
echo "Usage: parseflags.sh [--help|-h] [--binary] [--option opt] [--] files..." 1>&2
exit 1
}
binary=0
option=''
while [[ $# -gt 0 ]]; do
case $1 in
--binary) binary=1 ;;
--option) shift; option="$1" ;;
--help|-h) usage ;;
--) shift; break ;;
-*) echo "Unknown flag '$1'" 1>&2; usage ;;
*) break ;;
esac
shift
done
echo "binary=$binary"
echo "option=$option"
echo "files: $@"