Nice work @manuel!
Here’s a few suggestions.
1. Help output pattern
You have quite a few calls to
usage() only for the purpose of echoing a string. It’s not a big deal. But may make some users uncomfortable with the rest of your code. You should find ways to optimize that.
One pattern for help display in scripts is a function making use of a heredoc string:
Usage: $0 [<repo> <arch>] [options]
<repo> antergos (default: antergos)
<arch> x86_64 (default: $(uname -m)
-x=X,Y,Z Exclude repos from countries; note that
word 'Automated' can also be used.
-xs=X,Y,Z exclude server urls that contain any of strings X, Y, or Z
-p=X,Y Repo protocols in preference order (currently only https
and http are supported)
-q quiet, don't show progress info
$(basename $0) -x=China,Russia,USA,Automated -xs sourceforge -p=https
You can now call this function from somewhere else in your code.
2. Consistent options
The presence of
-xs can confuse some users. A usual convention is for shell programs to make use of
getopts, which you don’t in your code but that’s fine. However, the principal motivation is for program options and arguments to follow the POSIX Utility Syntax Guidelines that in layman terms state, among other things, that a single letter options is prefixed with a single dash (
-) and more than that requires a double dash (
Double-dash options are usually aliases of single-dash options (for example
--sync on pacman) or unique options without a single dash (for instance,
So in your case, I would suggest you actually replaced
-s. However for a better feeling of consistency, you could also replace the
-x option with
-c. So, c for country and s for server.
3. Local variables
You don’t need to qualify your variables with
local unless they could override the caller variables. From a preliminary look at your script, I don’t see anywhere where this could happen.