Having a man page for read (in section 1 of the manual) that says anything else than "There is no read command, but your shell might have a read builtin command, see your shell manual for details" is misleading, because read is a shell builtin and the behaviour and supported options vary from shell to shell.
Some systems (generally not Linux ones) however do have a read command (in /bin, /usr/bin or elsewhere) as POSIX requires (but the Linux Standard Base (LSB) specification lifts that requirement), and on those systems, the man page will describe the behaviour of that read command, and will be misleading because it's generally not that read that you invoke when you call read at a shell prompt or in a shell script or in system(), popen()... but the shell builtin one.
That http://ss64.com site describes the bash builtin read command (though it doesn't say which version of bash, and for instance, it's different from the read builtin in the version of bash on this machine, which itself is different from that read from the bash of another (older) machine I have access to) in a bash section. In that regard, it's not misleading, but where it's very misleading is where it puts all sorts of other non-bash related commands in that same section and sort of implies that bash (one of many shells available on Linux and other Unices, shells being one of many ways to run commands) is necessary to run those commands or that those commands have anything to do with it.
Now, when you do man read, if there's no read command in section 1 (user commands) of the manual, it will search in other sections. For instance, if you have installed the manpages-dev package (on Debian), you'll get the man page of the read system call (in section 2). If not, but you have installed the TCL documentation package, you'll get the man page for the read TCL function in section 3tcl.
You can ask explicitly for the read user command with man 1 read (man -s 1 read on some systems). If your manual had a 1bash section, it would bring it up before the one in section 1zsh, so you'd need to write it man 1zsh read to get the zsh variant. You can get all the man pages with man -a read, you can find out what packages they come from on Debian with: dpkg -S $(man -wa read). For instance, on this system, I have:
$ dpkg -S $(man -wa read)
9base: /usr/share/man/man1/plan9-read.1.gz
tcl8.5-doc: /usr/share/man/man3/read.3tcl.gz
manpages-dev: /usr/share/man/man2/read.2.gz
With zsh, pressing Alt-H at the prompt brings the manual (via the man command) for the command you're currently typing. The default zsh installation on Debian improves it to make use of the run-help function (see info -f zsh --index-search=run-help), so you get help for the builtins as well.
With the fish shell, there's a help builtin function that tries to bring the most sensible documentation for a given command or fish concept (from man or the fish documentation).
If for some reason, you're forced to using bash (grin) or can't be bothered to change from the default, bash also has a help builtin command that brings help on bash builtins (however note that help read is like help '*read*', that is it brings the manual for all the builtins whose name contains read, use help '[r]ead' for instance, if you only want the read manual).
bash's help only works for bash builtins. If you want to extend it to include search in the manual in sections 1 (user commands) and 6 (games) and 8 (administrative commands), you could redefine it as:
help() {
builtin help "$@" 2> /dev/null ||
MANSECT=1:8:6 man "$@"
}
Best Answer
You don't, really. Not without knowledge external to the man page.
In the case of
echo(andprintf, andtest, ...), it's often a shell builtin, so you'll need to know that and read the shell's documentation. (Andechois notoriously different in different implementations, useprintfinstead.)In most, if not all shells, you can find if something is a builtin with
type command, e.g.type echowill printecho is a shell builtin. (typeis specified by POSIX but e.g. fish supports it too, as non-POSIXy as it is.) In Bash, you'd then readman bash, the online documentation, or use the builtin commandhelp(which is specific to Bash, and which you need to know exists).Even if the command is not a builtin, it's possible that there are several commands with the same name,
renamebeing a famous example (see Why is the rename utility on Debian/Ubuntu different than the one on other distributions, like CentOS?). Now, your OS should have the correct man page for the actually installed utility, and e.g. in Debian, the "alternatives" system updates the corresponding man pages also when the command alternatives are changed. But if you read an online man page, you'll need to be aware of it.Many utilities have a command line option like
--versionwhich might tell you what implementation that command is. (But not nearly all utilities have it. I think it's a GNUism originally, so GNU utilities have it, as well as those that happened to copy the custom.) In the case ofrename, it happens to work in telling two different implementations apart:Besides that, your system might have an alias or a function with the same name of a utility, usually to modify the behaviour of the utility. In that case, the defaults presented in a man page might not apply. Aliases for
lsare common, as are aliases adding-itormormv. Buttype foowould also tell you iffoois an alias or function.