Sometimes, you may see advice that suggests using full paths in your aliases. Stop a moment. Is that really the behavior you want, and how can you even decide?
What Is an Alias?
An alias is a shorter way of typing a command. When you run an alias, your shell replaces it with predefined text that may add arguments or run a different command altogether.
You can create an alias using the alias command like this:
Once you've created such an alias, your shell will replace word(at the start of a command) with the full contents of the double quotes. So, for example, if you run:
Then, whenever you type "ls", you'll get "ls -GF" instead.
Aliases are really useful because they can save you time and simplify longer commands. They can also help you tweak the behavior of programs by varying their defaults.
For example, I recently came across a tip in the fd manual about passing flags to the program using an alias:
By default, the program filters out files that are ignored by version control systems. The "--no-ignore-vcs" flag reverses this default behavior, so setting it up as an alias changes the default permanently.
What struck me about this was the full path in the alias. I'm used to pathless aliases, like the lsexample above. So, how does including the full path affect things?
What Does an Alias With a Path Do?
If your shell replaces "fd" with "/usr/bin/fd," there should be no real problem. Running a command via its full path is perfectly acceptable; if an executable isn't in your PATH , it's the only way to run it.
Problems can arise, however, when you bypass the PATH system, using absolute paths to commands. What happens if fd moves from /usr/bin to /usr/local/bin? Your alias will generate an error and fail to run.
That problem isn't so bad: you can identify the cause and fix it. But what if you have several versions of the same command installed in different locations within your PATH? This isn't an uncommon situation; for example:
On my system, the ri command exists in two locations: /opt/homebrew/bin and /usr/bin. Because those paths are listed in that order in my PATH, the homebrew version takes precedent. But an alias with an absolute path could cause problems:
The ri command will now always run the version in /usr/bin, even if a version is later installed in the homebrew directory, or anywhere else. In effect, using a full absolute path in your alias breaks the PATH system, which is one of Linux's great strengths.
And What About a Pathless Alias?
Instead of a full path, you can—and should—use the command name only. For example:
These aliases will respect the PATH system and run the most appropriate command, provided you have your PATH set up correctly. What's more, you'll still be able to override them easily. To bypass the alias and/or use a specific version of a command, just run it via the absolute path:
And How About the Other Half of the Alias?
If you've been experimenting with aliases and paths a bit, you might have noticed that they depend on how you run a command. Aliases are very literal and will only apply when they match exactly what you type, not just when they match the command you run.
For example, on my system, the ls command lives at /bin/ls, and I have an alias ls='ls -GF':
Running ls runs that alias, so the output is colorized and file types are indicated:
Behind the scenes, the /bin/ls executable still gets run; it just receives those options as arguments. However, running /bin/ls directly does not do the same thing:
This is simply because lsis not literally the same string as /bin/ls, even if it's the same file. What may surprise you even more is that it's absolutely fine to specify a full path on the left side of an alias too:
As far as the shell is concerned, that "/bin/ls" isn't really a path at all; it's just a string to match against. There's no connection between it and the actual file at that path; there doesn't even need to be a /bin/ls for such an alias to exist.
Of course, there's no real reason to alias /bin/ls like this at all. Aliases are supposed to be short and easy to type, and the PATH system lets you avoid typing the full path of a command in the first place. You could try to cover all your bases to ensure ls always runs with certain options, but you'll never cater for every possibility:
So, Which Should I Use?
Remember that aliases are a bit like macros: they're a simple match and replace mechanism. Although you can use them to provide default options, bear in mind that they have a particular scope: for interactive, command-line use.
If you're writing a shell script, there's a lot to take into account: aliases, shell functions, builtins, and more . Make sure you know which of these you're intending to run, and which will actually run.
The command builtin will always run a program, bypassing any functions, builtins, or aliases that may exist. Similarly, you can bypass aliases by quoting your command in any valid way:
