This varies by utility and more significantly by parent project.
There are lots of ways to access help on a properly provisioned Linux system (recognizing Linux as the true heir of Unix), though there are numerous less-than-optimal systems.
First off: Linux is a system and inherits a philosophy. Kernighan and Pike's The UNIX Programming Environment[1], particularly the first couple of chapters, remains relevant despite its 1984 publication date.
Secondly: All commands should have a manpage. The Debian GNU/Linux distribution considers the absence of manpages a non-critical bug (the package can be included on the stable release, but a bug report is appropriate), and has provided a large number of manpages. Virtually all Debian-derived distributions (including the popular Ubuntu and Mint distors) benefit from this. Other projects, notably GNU, deprecate manpages for info, another format, which I find far less useful for numerous reasons. Manpages are typically brief (the median length is around 3 pages of printed text), and include a syntax synopsis. A key section is the "Examples" portion, which shows actual examples of the command in use. While not universally, or even often, filled out, this can be tremendously useful.
Third: There are numerous other documentation sources and systems. In addition to man and info pages, FAQs, READMEs, and numerous other sources of information. Again, Debian requires that every installed software package have an entry under /usr/share/doc/<packagename>/ with certain required entries (copyright and changelogs), and often additional documentation including manuals and examples.
Fourth: Again, Debian includes a tool to make all of this information readily available via a locally-exported Web facility, dwww. This provides a Web interface at http://localhost/dwww/ with a searchable hierarchy of all installed system documentation: man and info pages, /usr/share/doc/, and additional READMEs, FAQs, manuals, RFCs, and other documentation, all installable via Debian packages. It's pretty fucking awesome, actually. The extent of the documentation (especially for large packages such as tetex) is often a, or the, major consumer of system space.
All of which sounds a bit overwhelming, but there's a pretty small set of knowledge you really need to get started at the commandline. The additional information is there if you need to dig into it.
Fifth: The fundamentals change slowly, if at all. Again, K&P is 30 years old, and yet the philosophy sections are still largely relevant. Even of the material that's changed, much of it is still a reasonably good guide. I've been using Unix-like environments for nearly 30 years, and one of the most useful aspects about it is that knowledge is almost always additive. Rather than having to learn and then unlearn things, I can stick additional bits of knowledge and understanding on my established base. This isn't always the case (sound, video, and firewall configuration, notably, have changed several times, the system startup mechanism is changing now with replacements to sysv-init battling it out), but compared with the other platforms I've learned and since forgotten, it's vastly more true: Commodore BASIC, CP/M and DOS, VM/CMS, TSO/ISPF, and PCL, DEC DCL, Windows 3.x, NT, and onwards, Mac System 1-9, Mac OS X. If you stick at this game long enough, you'll find that forgetting things is as important as learning new things, and a system which doesn't force you to forget frequently is a huge bonus.
Linux has good bones.
That's also why many commands are as complex as they are: they've got upwards of 40 years of context applied to them. Why is dd so weird? It's a mainframe command, ported with syntax (spend time with JCL and you'll recognize it). ar begat tar. Various compression utilities subsume changes in formats (though gzip tends to include many of them). vim is based on vi is based on ex is based on ed. Each has extended the capabilities of its precusors (and for me to use a canonical vi such as nvi is absolutely painful).
Understand that an you're a long way to understanding the power of Linux.
There are lots of ways to access help on a properly provisioned Linux system (recognizing Linux as the true heir of Unix), though there are numerous less-than-optimal systems.
First off: Linux is a system and inherits a philosophy. Kernighan and Pike's The UNIX Programming Environment[1], particularly the first couple of chapters, remains relevant despite its 1984 publication date.
Secondly: All commands should have a manpage. The Debian GNU/Linux distribution considers the absence of manpages a non-critical bug (the package can be included on the stable release, but a bug report is appropriate), and has provided a large number of manpages. Virtually all Debian-derived distributions (including the popular Ubuntu and Mint distors) benefit from this. Other projects, notably GNU, deprecate manpages for info, another format, which I find far less useful for numerous reasons. Manpages are typically brief (the median length is around 3 pages of printed text), and include a syntax synopsis. A key section is the "Examples" portion, which shows actual examples of the command in use. While not universally, or even often, filled out, this can be tremendously useful.
Third: There are numerous other documentation sources and systems. In addition to man and info pages, FAQs, READMEs, and numerous other sources of information. Again, Debian requires that every installed software package have an entry under /usr/share/doc/<packagename>/ with certain required entries (copyright and changelogs), and often additional documentation including manuals and examples.
Fourth: Again, Debian includes a tool to make all of this information readily available via a locally-exported Web facility, dwww. This provides a Web interface at http://localhost/dwww/ with a searchable hierarchy of all installed system documentation: man and info pages, /usr/share/doc/, and additional READMEs, FAQs, manuals, RFCs, and other documentation, all installable via Debian packages. It's pretty fucking awesome, actually. The extent of the documentation (especially for large packages such as tetex) is often a, or the, major consumer of system space.
All of which sounds a bit overwhelming, but there's a pretty small set of knowledge you really need to get started at the commandline. The additional information is there if you need to dig into it.
Fifth: The fundamentals change slowly, if at all. Again, K&P is 30 years old, and yet the philosophy sections are still largely relevant. Even of the material that's changed, much of it is still a reasonably good guide. I've been using Unix-like environments for nearly 30 years, and one of the most useful aspects about it is that knowledge is almost always additive. Rather than having to learn and then unlearn things, I can stick additional bits of knowledge and understanding on my established base. This isn't always the case (sound, video, and firewall configuration, notably, have changed several times, the system startup mechanism is changing now with replacements to sysv-init battling it out), but compared with the other platforms I've learned and since forgotten, it's vastly more true: Commodore BASIC, CP/M and DOS, VM/CMS, TSO/ISPF, and PCL, DEC DCL, Windows 3.x, NT, and onwards, Mac System 1-9, Mac OS X. If you stick at this game long enough, you'll find that forgetting things is as important as learning new things, and a system which doesn't force you to forget frequently is a huge bonus.
Linux has good bones.
That's also why many commands are as complex as they are: they've got upwards of 40 years of context applied to them. Why is dd so weird? It's a mainframe command, ported with syntax (spend time with JCL and you'll recognize it). ar begat tar. Various compression utilities subsume changes in formats (though gzip tends to include many of them). vim is based on vi is based on ex is based on ed. Each has extended the capabilities of its precusors (and for me to use a canonical vi such as nvi is absolutely painful).
Understand that an you're a long way to understanding the power of Linux.
________________________________
Notes:
1. http://cm.bell-labs.com/cm/cs/upe/index.html