Command-line-utilities-leuven is a collection of useful Shell scripts and command-line tools that can simplify and automate tasks on the command line. From file manipulation to system administration, these scripts cover a wide range of tasks and can save you time and effort in your daily workflow. Whether you’re a seasoned command-line user or just getting started, this repository has something for everyone.
“Running XXX. This may take some time… done.”
To be able to use the following commands, ensure that the following package is installed on your system.
- docopts (
docopt
for shell – make beautiful CLI with ease)(I choose for the “with grep” syntax to have the help and version messages parsed from script comments, while avoiding having to source
docopts.sh
.) - wsl repository (for
bin/docopts
, needed in a WSL environment)
Create a quick back-up copy of a file.
Find directories or files matching a string and print their full file name.
Find directories matching a string and print their full file name.
Find files matching a string and print their full file name.
Find files with duplicate or conflicting names.
Search for duplicated files.
Find all files modified in the last 7 days (including today).
Find all files modified today in a specified directory or the current directory (if none is specified), with the option to filter by file extension.
Remove lines that match any lines between two files.
Strip color sequences from the input text.
Swap the contents of two files.
Run a command 100 times and print its average and median execution time.
Bash scripting can be a powerful tool for automating tasks, but it’s important to follow best practices to ensure that your scripts are efficient, reliable, and maintainable. Here are some best practices to keep in mind:
- Use
/usr/bin/env bash
in the shebang line (more portable way to reference the Bash interpreter). - Use comments to explain what the code does.
- Use variables to store values used multiple times.
- Rename variables to follow lowercase naming convention.
- Enclose variables in double quotes to prevent word splitting and globbing.
- Use functions to avoid code repetition.
- Use
set -u
to treat unset variables as errors. - Use
set -e
to exit immediately if a command fails. - Use
set -o pipefail
to exit if any command in a pipeline fails. - Use exit codes to indicate success or failure.
- Use
printf
instead ofecho
for better control over the output format. - Add a period to the end of the error messages, so that it follows grammatical conventions.
- Use
grep
with the-w
flag to match whole words. - Use
cut
instead ofawk
to extract strings. - Use
uniq -d
to find duplicated strings. - Use
sort -u
to sort the output and remove duplicates from a list (instead ofsort | uniq
). - Use
$()
instead of backticks for command substitution. - Use double brackets (
[[ ... ]]
) in Bash and Zsh scripting for more advanced conditional expressions, improved handling of variables (allows unquoted variables and word splitting), enhanced logical operators (&&
,||
), and built-in pattern matching, providing a more powerful and flexible approach to conditionals compared to single brackets ([ ... ]
). - Use uppercase letters for variables that are intended to be constants and not changed during the script execution.
- Use lowercase letters for regular variables that can be modified during the script execution.
By following these best practices, you can write Bash scripts that are easier to understand, maintain, and debug.
If your script specifically requires a directory path and you want to avoid
ambiguity, DIRECTORY
is a clearer choice.
If your script needs to accept both file and directory paths and you want to
keep the argument name more general, PATH
might be more suitable.
To exclude Git directories and files,
find "$DIRECTORY" -type f -not -path "*/.git/*" -printf "%f\n" find "$DIRECTORY" -type d -name .git -prune -o -type f -printf "%f\n"
the second option with the -prune
action is generally better and more efficient.
The -prune
action stops find from descending into .git
directories, making it
more efficient as it avoids unnecessary checks within these directories.
Writing a Bash script in functions can make the code easier to reuse, more readable, and easier to test and debug, which can save time and reduce the likelihood of errors.
See https://unix.stackexchange.com/questions/313256/why-write-an-entire-bash-script-in-functions
- Beautiful Bash: Let’s make reading and writing bash scripts fun again! https://fr.slideshare.net/a_z_e_t/inpresentation
- Let’s make better scripts https://downloads.cisofy.com/files/public/presentation-lets-make-better-scripts.pdf
- http://wiki.bash-hackers.org/scripting/style
- https://github.com/azet/community_bash_style_guide
- https://google-styleguide.googlecode.com/svn/trunk/shell.xml
variable_name
(preferred,variableName
accepted)
function_name
\CONSTANT_NAME
- https://github.com/mvdan/sh
- https://google.github.io/styleguide/shell.xml
- https://www.shellcheck.net/ (online checker!)
http://www.skybert.net/emacs/bash-linting-in-emacs/
Found a bug or have an idea for a new feature? Share your thoughts on the GitHub issue tracker.
I welcome contributions in any form! Feel free to submit patches to enhance the project.
If you find the “command-line-utilities-leuven” project (or any of my other projects) enhancing your Shell experience and simplifying your workflow, seize the opportunity to express your appreciation! Help fuel future development by making a donation through PayPal. Your support is invaluable – thank you!
Remember, regardless of donations, “command-line-utilities-leuven” will always remain freely accessible, both as in Belgian beer and as in speech.
Copyright (C) 2012-2024 Fabrice Niessen
Author: Fabrice Niessen
Keywords: command-line utilities scripts
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.