I was messing around in terminal on Red Hat Linux, and when I typed the asterisk (*) followed by return, and it executed one of the programs in my directory. Why?

My best guess is that Unix treated it as a wildcard so it executed the first alphabetic program. Since my_program.exe and one_of_my_programs.program can be executed by simply typing the name of the file, the wildcard operator represents all the possible files. Since a program is first alphabetically, Unix executes it. Is this a correct judgement?


2 Answers 2


Your interpretation is correct. The rest of the files will be presented as its parameter list.

Note that it will do this only if the program has the executable bit set, and the current directory is in the PATH list.

A couple of notes which may help understanding:-

  • If you type ./* then the PATH entry is not a requirement.
  • If you type . * or . ./* and the first matching file is a script, then it need not be executable, nor need the current directory be in PATH (may not be true for shells other than bash).
  • 10
    "it will do this only…" – It can be more interesting. If there's a shell function, builtin, or an executable earlier in PATH with the same name as the first file then this other command will be executed. mkdir foo; cd foo; touch rm xyz; ls; *; ls. Oct 4, 2017 at 14:33
  • @KamilMaciorowski - Fair point: my statement "it will do this only…" specified necessary conditions, but not sufficient ones. The command will also behave differently if * is an alias.
    – AFH
    Oct 4, 2017 at 15:00
  • 1
    Conclusion : don't do this ! Even if you think you can rely on glob expansion alphabetic order, note that this order depends on the locale.
    – Aaron
    Oct 5, 2017 at 9:52
  • in addition to . * or . ./* one can bash * (or any other shell). Oct 5, 2017 at 10:27

This suggests that . is part of your PATH variable. That is a really bad idea for security reasons (naturally, Windows had to make it an unmodifiable default).

However, this "suggestion" is only mildly valid: if you have a file named rm in your current directory, * will be fine executing the default rm:

/tmp$ mkdir ohno
/tmp$ cd ohno
/tmp/ohno$ ls
/tmp/ohno$ touch rm what
/tmp/ohno$ ls
rm  what
/tmp/ohno$ *
/tmp/ohno$ ls

As you can see, it wasn't rm in the current directory (an empty and non-executable file) that got executed but rather the system's default /bin/rm.

Always double check your commands when wildcards are involved. Here is one of the most terrifying messages to ever read:

rm: cannot remove '.o': No such file or directory

This is the result of calling

rm * .o

, more or less the worst placement of a spurious space one can come up with.

  • 1
    It doesn't hurt to create a function rm() which either adds -i to the parameters or checks the parameters and asks for confirmation if there are more than a certain number.
    – AFH
    Oct 4, 2017 at 22:00
  • 3
    +1 for "Here is one of the most terrifying messages to ever read".
    – user541686
    Oct 5, 2017 at 0:34
  • +1 for "That is a really bad idea for security reasons (naturally, Windows had to make it an unmodifiable default)." Oct 5, 2017 at 6:01
  • FTFY: mv /tmp/ohno /tmp/ohnoes (google.fr/search?q=ohnoes&source=lnms&tbm=isch) Oct 5, 2017 at 10:30
  • There's a good reason why Windows made it an unmodifiable default. It has to maintain a chain of backwards compatibility from the days before DOS implemented directories. Bear in mind those days nobody using a PC had a hard disk, and floppy disks were small enough that directories weren't initially considered necessary.
    – Muzer
    Oct 5, 2017 at 14:17

You must log in to answer this question.

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