Debian has a release maturity model, where Unstable, Sid, is where all the new stuff goes in. If it sticks, then Unstable becomes Testing, in which nothing can be added during testing. This typically lasts 1.5 - 2 years. If no problem at that point, Testing becomes the new Stable release.
Security updates are made to Stable first, then to Testing.
Debian Stable is notoriously stable, and notoriously behind the times, but very reliable for servers.
Ubuntu came along and said: we take Debian Unstable, make it more stable, add all the latest gadgets, drivers, etc, and release it.
Ubuntu then works at the security updates, package updates, etc, for their Ubuntu releases.
Note that I gladly use Ubuntu on the desktop, but I stick to Debian Stable for servers.
Makes sense?
Short answer: > must be followed by a filename or &n (n is a number), and | must be followed by another command invocation.
Details: In shell syntax, a call to some command contains several components. Example:
A=foo 2>/dev/null B=bar cmd arg1 arg2 >file 3>&4 arg3
Here, parameters 2>/dev/null, >file and 3>&4 are special parameters (containing an unescaped >¹), they are used to establish io-redirections, and can appear anywhere in the command line. Filedesciptor 2 is redirected to /dev/null, filedescriptor 1 (implicit) is redirected to file and filedescriptor 3 is redirected to what filedescriptor 4 was linked to.
Then, among remaining parameters, A=foo and B=bar contain =, so they are not considered as the command name: they give specific values to environment variables of the process to be launched.
Then comes the command cmd and the real arguments: arg1, arg2, arg3.
The pipe | is not part of a command invocation, it links two such invocations together. Example:
CC=gcc make 2>&1 | LESS=--quit-at-eof less
Output on filedescriptor 1 by the first process will be received as input on filedescriptor 0 by the second process, through a “pipe” which acts like a buffer.
—
1. In fact, the special characters like > are sometimes seen followed by a space. Even though this is allowed, the two (space-separated) strings must be understood as a single ‘entity’.
Best Answer
For one,
--helpis not a command, it is an argument that is often given to a command to get help using it. Meanwhile,manis a command, short for "manual". Manual pages are installed by many programs, and are a common way to find help about commands, as well as system calls, (e.g.fork()).If a program installs a manual page, it can always be accessed via the
mancommand, whereas--helpis just a common convention, but need not be enforced—it could be just (and only)-h.manalso typically uses a pager, such asless, automatically, which can make viewing and searching through the information much easier.Finally, you mention Bash programming in your question—none of this is unique to Bash. Bash doesn't care about the commands themselves or their arguments for the most part.