The other advantage that the article misses for aliases is that completions will work through aliases. So, in the case give for `alias g=git` typing `g <tab>` will give you the bash/zsh completions for git. You _can_ do this for the script as well, but then you need to code that up separately.
Yes, and this is why I recommend against the alias-y wrappers.
Personally, I like using abbreviations ("abbr") in fish, which automatically expand as you hit space. This is especially helpful when screen sharing: No more "what does this gcob command do" questions!
Yeah, I do something kind of similar, using Dash [1] snippets which expand to full commands.
Since I'm almost always on my mac, it means they're available in every shell, including remote shells, and in other situations like on Slack or writing documentation.
I mostly use § as a prefix so I don't type them accidentally (although my git shortcuts are all `gg`-consonant which is not likely to appear in real typing).
Another advantage of using alias: `which [alias]` actually tells you what that alias is mapped to, and not just the location of a script in your bin folder.
Internally git uses the __git_complete function to set up completions for its subcommands, though this may be specific to your OS/distro and perhaps or git version.
This does seem to ship as part of git now, here[1].
This is something I've never seen. `which` (at least on the hosts I currently have access to) is its own binary `/usr/bin/which` and unrelated to the shell and its aliases or abbreviations.
`type` is a builtin on both fish and bash though, and does resolve aliases.
I remember years ago seeing a trick related to this to allow aliases after `sudo` (which I think by default won't recognize them due to running as a separate user) by doing `alias sudo="sudo ".
I came here to say the same thing.
I'm also not convinced about the instant reload aspect. You can always just define your aliases in a different file and source it when updating aliases (how often does that happen anyway?), source your .zshrc, or just open a new terminal window.
Sourcing .zshrc works reasonably well. I have the following at the end of setup.sh -- which creates symlinks and sets up other configurations.
makeLinks does most of the work, then sets Homebrew's zsh as the default shell -- this currently runs in bash, so it probably will need to be updated at some point -- and everything gets reloaded.
makeLinks && chsh -s /usr/local/bin/zsh
exec $SHELL && brew doctor
I have an alias reload="exec zsh" for fast reloading. Admittedly, this does wreck up everything set up locally but I doubt you will be modifying ~/.[zsh|bash]rc file often
> I use Bash for a lot of my scripts, but not all. For example
> I have a note-taking script called ~/bin/note which I didn’t
> want to write in Bash, so I wrote it in Python instead. With
> an alias, I’d have to write it in Zsh.
If the script is an actual script that does something more than just calling another program, then the comparison to an alias doesn't make sense. And if it's about setting up an alias to a Python program, it can definitely be done. Is there anything I'm missing here?
There isn't a well-defined / binary boundary to an "actual script"; I'm assuming this "note" thing is something like a 10-liner in Python. It's simply two curves of scripting in sh/bash/zsh becoming more difficult vs. Python starting with more effort but a more shallow curve — at some point the curves cross. But that crossover point is different for each person, and the other option doesn't immediately become impossible.
I do something similar to my .bash_aliases, but with a few short additions to make sure running it multiple times doesn't have any strange side effects. For instance:
function edit_load() {
$EDITOR $1
source $1
if [ $? -eq 0 ]
then
echo "$1 updated."
fi
}
alias aliases="edit_load ~/.bash_aliases"
# to make sure I don't add things to $PATH on each reload
append_path () {
case ":$PATH:" in
*:"$1":*)
;;
\*)
PATH="${PATH:+$PATH:}$1"
esac
}
append_path '/blah/blah/bin'
I reach for the ~/bin/thing approach when I want the utility to be useable from vim.
For example, if I define an alias thing, vim won't know about it.
But as a executable on my $PATH, I can do any of the following:
:%!thing
:'<'>!thing
:.!thing
A good example is on my work machine, I can't install jq because reasons. However I do have python, so I have a simple executable called fmtjson that looks like this:
#!/bin/sh
python -m json.tool --indent 2
When I want to format some json from vim, I just run:
:%!fmtjson
Easy to remember, easy to type. Plus I can use it in pipes on the cli.
Another great advantage of fish abbreviations is your history shows the actual command that was run (and in fact as soon as you've typed it, it expands, so you SEE what you're running).
Yes, essentially on the fly editable aliases. Fish is so good. I assume there's a zsh plugin that mimics that functionality - zsh people should try it.
I like putting my "aliases" into the functions directory of my config.
I have one that uses podman if it's available when I type `docker`. If I ever specifically need Docker I can use the fully-qualified path. I have a similar trick for `nvim`/`vim`.
This is the right way. I mentioned in another comment, but abbreviations also shine when screen sharing: Everyone can follow along quickly without having to ask the "what does this gcob command do" questions.
Yeah, it's very convenient. Here are a few of mine(tested on OS X):
alias -g L="| less"
alias -g T="| tee"
alias -g C="| pbcopy"
alias -g @all="> /dev/null 2>&1"
if command -v rg > /dev/null; then
alias -g G="| rg"
else
alias -g G="| grep"
fi
Sounds like overengineering. If you just need a shortcut for a command, that's exactly what aliases are for. If you need something more sophisticated, you probably are going to lean to scripts or functions.
Pretty much agree with most. I am wondering about paths and locations; there's now ~/.local/bin which is where e.g. a user-wide "pip install" would put things [when used without a venv]… ~/bin is not such a "standardized" location. I kinda started using both and am a bit torn now…
I think this misses the obvious. Aliases are aliases. They save typing in a shell. Actually putting them in your PATH... is kinda sketchy, as PATH is a global namespace used by everything. You almost certainly don't want exec(2) picking up the random short letter names you'd be littering in PATH.
True, but I think that the author did not mean this as a real useful example.
At least for myself, the main benefit of aliases is not to abbreviate the command name, but to change the default command-line options.
I strongly dislike the default command-line options of most UNIX utilities, e.g. cp, mv, rm and the like, so I never invoke them directly, but only through aliases that use what I consider to be the correct default options (for instance I consider that the default for any kind of copy command must be to make an exact copy of the source, instead of losing any part of the original information).
Surely this is possible way to alias commands, but keep in mind that PATH extensions are made available not only in shell, but to all programs started from it, well, because it is environ. Whereas aliases are available only for use inside shell, but they're not executable by programs started from it. They are not the same.
At least some of these problems can be addressed by using a dotfile manager such as chezmoi or stow, specifically the conditional presence of scripts. Also, it’s perfectly possible to pass the status code of a previous program to another without builtins like $?, I’m not quite sure what he meant by that.
I just create ~/rc_files.d/{functions,aliases,profiles,etc} which automatically get sourced with a `for` loop. This makes it easier to keep things organised.
yes, I've done basically this, but... gee is `foo` an alias or... did I upgrade it to a function?
and maybe it's in neither my `functions` nor `aliases` file. Maybe it's in my `scm` file, or ... Oh!
I remember, it's in my `prompt` file because I add SCM info to my prompt and this function injects the segment of the SCM url I'm after into my PS1 variable...
So many CLI tools delivered as bash/bourne shell scripts to source relying on aliases and other shell magic (aliases and functions rather than commands) fall apart when used in automated unattended environments like build processes.
This is also a good approach for Windows since aliases on Windows don't really exist. Make a directory like C:/path/to/aliases that holds all your batch files.
One problem I had today with alias is that I cannot run, e.g. `timeout 10 my_alias` where `my_alias` is the alias. Does anyone know if this is possible to achieve with an alias?
I used to have a bunch of over-complicated aliases, but due to their limitations, I now use a mix of aliases and functions, with a few scripts in ~/bin. It’s all a matter of using the right tool. I use aliases for simple things, like default options on some commands. Things that need to happen in the current shell, but are too complex for an alias, are functions. That leaves extra-complex things that I don’t want to write a shell function for as programs in ~/bin, which can be shell, or python, or whatever.
Yeah, I guess me and the author just have different opinions on it. I do the same as you: start with an alias, use a function if its more complicated, and only use scripts for things that are closer to programs in complexity/length. Using this model over the past ~10 years I have ~50/50 split of aliases/functions and only a few scripts.
Less portable and don't give the subprocess isolation that a proper script has. That's sometimes an advantage (can modify shell state — I think that's the primary one), sometimes a disadvantage (influenced by shell state [e.g. set -e], "exit" exits the entire shell, hard to do cleanup / use signal handlers, can accidentally change shell state [like cwd].)
But I'd use a shell function over an alias if a script isn't an option.
