Why I use executable scripts instead of shell aliases
Table of contents
I stopped using shell aliases and moved everything into executable scripts.
Main Benefits
- No need to source your
.bashrc
after adding new scripts - No need to edit
.bashrc
, just drop executable files in your~/bins
folder (already in my$PATH
) - Use immediately without reloading your shell
- Faster iteration (edit script, re-run command, repeat).
- Available in more places:
Executable scripts in your PATH
can be used inside other scripts, sub-shells, find -exec
, xargs -I{}
, and other environments where the aliases defined in your .bashrch
are not read by default 1
Easy organization
I can quickly decide which scripts go to which machines:
- Some scripts only run on my laptop
- Others run on all ubuntu machines
- Some are project-specific, or just do my day-to-day job
I used to manage this with ansible playbooks and it was super unmaintainable and hard to reason about. Since I moved to executable scripts I haven’t had this issue.
Simple Deployment
I organize my scripts by purpose. I have a .txt
list of scripts for each purpose, then rsync
them appropriately. For example:
- One list for scripts needed on all machines
- Another list for Ubuntu servers only
- A separate list for daily work tasks
Example:
common-bins.txt
,common-1
,common-2
laptop-bins.txt
,my-script-1
,my-script-2
To copy them:
rsync --checksum --update -Pavzh --files-from=common-bins.txt ./bins/ $HOME/bin/
rsync --checksum --update -Pavzh --files-from=laptop-bins.txt ./bins/ $HOME/bin/
The best part? I never have to source .bashrc
again. All my tools are ready to use as soon as I create and copy them.
Others
I start all my scripts with a comma. I’ve found this to be a wonderful improvement.
Thanks to this HN comment for the reminder. ↩︎