Often I find my self making single character aliases, because after all, they exist to save input time. I'm curious if this should be avoided. I do not know of any conflicts.

  • 1
    I have d, e, f, g, j, l, p, u, v and U all defined (most of them not aliases, but personal commands in my equivalent of ~/bin). None of them are "destructive" commands. So, not to be avoided.
    – jrw32982
    Commented Feb 17, 2021 at 18:15

6 Answers 6


Things to avoid:

  • standard or common commands with single character names: w (show logged in users' activity), X (X Window System server), R (R programming language interpreter), [ (similar to test)
  • builtins of your shell or of common shells: [, ., :, -, r
  • shell keywords: {, }, !
  • ? and * wildcard characters
  • special characters in the shell syntax: `"$&();'#~|\<>, (also ^, % in some shells), SPC, TAB, NL (and other blanks with some shells)
  • better avoid non-ASCII characters (as those have different encoding depending on the locale)
  • better avoid control characters (beside TAB and NL already mentioned above) as they're not that easy to enter, and depending on context, not always visible, or with different representations. Only zsh will let you define and use an alias for the NUL character. bash lets you define an alias for ^A (the control character with byte value 1) but not use it apparently.

To find commands with single character names:

  • bash: compgen -c | grep -x . | sort -u (also includes keywords, assumes command names don't contain newline characters)

  • zsh: type -m '?' (or type -pm '?' if you don't want functions/aliases/builtins/keywords).

  • Debian or derivatives: to find any command in any package with single character name:

    $ apt-file find -x '/s?bin/.$'
    coreutils: /usr/bin/[
    e-wrapper: /usr/bin/e
    python3-q-text-as-data: /usr/bin/q
    r-base-core: /usr/bin/R
    r-base-core: /usr/lib/R/bin/R
    r-cran-littler: /usr/bin/r
    r-cran-littler: /usr/lib/R/site-library/littler/bin/r
    wims: /var/lib/wims/public_html/bin/c
    xserver-xorg-core: /usr/bin/X
  • 5
    What is -? Asking cause I have it aliased in Bash: alias -- -='cd -'
    – wjandrea
    Commented Feb 12, 2021 at 17:38
  • Use your own judgment for what is considered "common". I don't have R installed on my machine, and though X is installed on my macOS machine, I would never be inconvenienced by aliasing X to another command. (I can always use \X or command X if I find myself needing to start an X server from an interactive shell.)
    – chepner
    Commented Feb 12, 2021 at 20:55
  • 2
    @wjandrea afaicg that should only be a problem if you have other aliases whose values ends with a space (causing the 2nd, etc arg to be also evaluated as an alias). But then the problem is with using that misfeature, not an alias named - or -- per se.
    – user313992
    Commented Feb 12, 2021 at 21:06
  • @user414777 Oh, I see, cause - is often an argument standing in for standard streams
    – wjandrea
    Commented Feb 12, 2021 at 22:39
  • 2
    @wjandrea, - is a shell builtin in zsh (the shell people tend to move on to eventually), where it's used to run a command with - prepended to its argv[0] (typically to start shells in "login" mode), not the most commonly used builtin these days (now that several shells also accept a -l/--login and that there's also ARGV0=-sh sh or (exec -a -sh sh)), so I don't expect creating an alias for it would likely get in your way. Commented Feb 13, 2021 at 7:20

The simplest way is probably to check whether something with that name already exists. On my system:

$ for char in {A..z}; do type "$char" 2>/dev/null; done
R is /usr/bin/R
X is /usr/bin/X
[ is a shell builtin
l is aliased to `ls -CF'
w is /usr/bin/w

As far as I know this shows all relevant collisions:

  • Other aliases like l
  • Shell reserved words
  • Functions
  • Shell builtins
  • File commands such as w and [

Addressing: "I'm curious if this should be avoided."

As described in the other answers, there should be no technical problem as long as the command you are overriding with the alias it isn't something you are going to use.

The main frustration with using aliases like this is when you are helping a friend or ssh into a computer where you haven't copied your .bashrc yet. All of the muscle memory you've developed makes you feel like a fish out of water. I find it so disorienting that I try to keep my aliases to a minimum.

  • I downvoted this answer because it is an opinion referencing other satisfactory answers and then simply advice rather than something concrete.
    – qq4
    Commented Feb 12, 2021 at 20:04
  • 6
    @qq4 Their point regarding muscle memory on a foreign computer seems like a valid reason to avoid conflicting aliases, though. I think that makes it a valid answer and contribution. It can also be applied backwards, when you have defined aliases that use names of known commands and a friend uses your computer without knowing your aliases. In both WaterMolecule's and this scenario, there is a risk of running commands not meant to be run. Not everyone shares computers or uses unconfigured systems, but if they do, then this could be a valid concern, I think.
    – JoL
    Commented Feb 12, 2021 at 20:38
  • 1
    It's a good reason to avoid all aliases! Commented Feb 17, 2021 at 17:55

I'm curious if this should be avoided. I do not know of any conflicts.

It doesn't really matter for conflicts you don't already know about.

Aliases are an interactive shell configuration. They're not active in scripts. If you define an alias with the same name as an existing program, all it means is that when you personally type it in the shell, you'll by default call your alias instead of the other program. Other programs won't see your alias, so there is no conflict.

As an example, if you don't know the command X or never plan to call it directly from the shell, it's not really an issue if you define an alias X. When another program like startx/xinit call X they won't see your alias, so there won't be a conflict.


It depends on what you user aliases for (eg. how big of an issue it is if you execute wrong alias by mistake), and how often you make mistakes.

For example:

  • using r='rm -rf *' and t='ls -l *tar*' is probably a very bad idea, even if you seldom press wrong key.
  • using r='file *.png | grep RGB' and t='ls -l *tar*' is probably not a problem.

In later case, if you type r instead of (close on keyboard, and thus easy to wrongly type) t, you'd just get output which you didn't want, and you can easily type correct alias. In former case however, if you type r instead of t, you will do unwanted damage.

So the point is: if you do one-letter aliases, use them only for read-only things (and not for things that may change data in a way that would cause you problems if run inadvertently)

  • So, t='ls -l *tar*' is "a very bad idea" and "probably not a problem" at the same time. But yes, what it really boils down to is "how often you make mistakes". Outstanding contribution!
    – user313992
    Commented Feb 12, 2021 at 23:16
  • 1
    @user414777 it is about combination of those (eg. what happens in each case if you mistype r instead of t). I've expanded the answer so it is more obvious. Commented Feb 12, 2021 at 23:28
  • you probably meant t='rm *tar*' or t='tar xvf *tar' ore something like that for the bad ideas. Commented Feb 14, 2021 at 13:42
  • 1
    @LjmDullaart no, I meant exactly as it is written - it is on purpose that t is same read-only operation in both bullets. It is only r that differs, in one bullet it is read-only, in other bullet it is destructive. t exists only as aliased letter close to r on keyboard, it is irrelevant otherwise. See part of explanation that starts with In later case, if you type [...] for reasoning why. Commented Feb 15, 2021 at 17:27

This bash one liner will show you all the commands which are a single character (I'm not a bash professional, so probably this script is not the most elegant):

echo $PATH |
    sed 's/:/\n/g' |
    while read p; do ls "$p" 2>/dev/null; done |
    egrep "^.$" |
    sort -u

On Fedora 33 I get:

  • This found nothing on my ubuntu 20.04 but l0b0's awnser found 3
    – Alator
    Commented Feb 12, 2021 at 14:06
  • Very cool! I'm also running Fedora 33 and I get the same 3.
    – qq4
    Commented Feb 12, 2021 at 16:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .