Let’s say you’re looking for help with the ls command, so you check the type:

$ type -a ls

ls is aliased to `ls --color=auto'

ls is /bin/ls

We can ignore the alias since there’s no help for those. There is no function, keyword or shell builtin called ls, but there is a file path. In other words, we want information about the file command called ls.

File commands have been developed by thousands of mostly independent people over several decades, and have been documented in many different ways. We’ll go over some of the most common ones, but beware that none of them are guaranteed to give results – developers are free to provide documentation in any way they see fit, including not at all. In general, though, popular file commands have excellent documentation, and we can expect any file command which is available on a popular Linux distribution to have at least some documentation.

“Executable” (the technical word for “runnable”) is the preferred noun used to refer to the file rather than the command. That is, ls is a command and /bin/ls is an executable.

Some people treat “binary” (as in the /bin directory) as a synonym for “executable,” but this is an unfortunate misnomer: not all binary files are executable (such as JPEG image files, which are meant to be read but not executed) and not all executables are binary (such as Bash scripts, which are plain text).

Self–documenting commands#

Self–documenting commands can be run in such a way that they print their own documentation. The most common way to trigger this is to pass the --help flag:

$ ls --help

Usage: ls [OPTION]... [FILE]...

List information about the FILEs (the current directory by default).

Sort entries alphabetically if none of -cftuvSUX nor --sort is specified.

Mandatory arguments to long options are mandatory for short options too.

  -a, --all                  do not ignore entries starting with .

  -A, --almost-all           do not list implied . and ..

[…]