A strategy for Bash aliases and personal scripts
There's this blog article from 2009 where it is argued that personal scripts in a Linux shell environment should all start with a comma or “,” character.
It is argued that no (sane) built-in command ever starts with a “,”, so you're safe to use this prefix kind of as a “namespace” for your own personal scripts. The reasoning is fine enough and, as they say, if it works, it works.
But there's another way to make commands available to the shell conveniently without putting them in $PATH: shell aliases. Honestly I do both: if it's simple enough, a Bash alias suffices. If it's more complex, I couple a descriptive filename with a convenient alias.
The main point, though, is that, when you're setting Bash aliases, you can make them available for interactive shell sessions only; that is, the shell sessions you're running yourself.
In this manner, you won't accidentally affect any of the built-in commands or violate any assumptions the rest of the system or programs may have.
Let me put this into more concrete terms.
In the shell I like to type, say, gs to call git status on the git repository I'm currently in.
It can spell some trouble to inadvertently shadow the ghostscript interpreter, which also happens to be called gs. While I will never use that ghostscript interpreter myself, there may be other parts of the system which depend on it or that might find a gs binary on $PATH and assume it means ghostscript is available.
Simpler solution?
Instead of putting a binary (or a “shebang” script) in $PATH, for most cases you set up your .bashrc file as follows:
# .bashrc contents follow... # set environment variables and any other effects that should be visible to # the system, scripts and programs globally over here export PATH="/foo/bar:$PATH" # ... # if not running interactively, abort now [[ "$-" != *i* ]] && return # the commands, aliases and environment variables you set from now on # will concern only your interactive Bash shell sessions. alias 'gs'='git status'
Now I can get the best of both worlds: I get to name the commands and shortcuts that I actually use just one or two letters, but the whole system remains unaffected for scripting and programmatic purposes.
NOTE: A small addendum on personal scripts. I also make use of scripts on $PATH and I attempt to give them full names, such as “sync-backup-onedrive”, “update-system”. After giving them the full name and making them available on $PATH, I can then proceed to set aliases just for my own benefit: sbo, u, or any other mnemonic that I might find memorable and convenient.
Finally, there's one point that remains unaddressed that is raised by the original blog post, which is the convenience of typing “,” then Tab for autocompletion. It is true that it can't be done the same way for aliases that don't share a prefix, but the “alias” command, when entered alone, will list out all the aliases that you have available to stdout, along with their definitions. This means you can pipe them to grep, or whatever floats your boat (fzf?).
I think the stronger argument is that framing personal scripts -- which have specific intended functional purposes -- as something different from aliases -- which only need to be little convenient, memorable mnemonic devices -- is a better approach.