21

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?

20

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).
| improve this answer | |
  • 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. – Kamil Maciorowski Oct 4 '17 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 '17 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 '17 at 9:52
  • in addition to . * or . ./* one can bash * (or any other shell). – Olivier Dulac Oct 5 '17 at 10:27
11

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$ 
/tmp/ohno$ ls
/tmp/ohno$ touch rm what
/tmp/ohno$ ls
rm  what
/tmp/ohno$ *
/tmp/ohno$ ls
rm
/tmp/ohno$ 

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.

| improve this answer | |
  • 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 '17 at 22:00
  • 3
    +1 for "Here is one of the most terrifying messages to ever read". – user541686 Oct 5 '17 at 0:34
  • +1 for "That is a really bad idea for security reasons (naturally, Windows had to make it an unmodifiable default)." – Duncan X Simpson Oct 5 '17 at 6:01
  • FTFY: mv /tmp/ohno /tmp/ohnoes (google.fr/search?q=ohnoes&source=lnms&tbm=isch) – Olivier Dulac Oct 5 '17 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 '17 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.