Mind that the developer must learn to
use the reference and tutorials side by side. Eventually human help
can be useful as well. It's a scarce resource. Tutorials are great
ways to give a first impression of developments, and as business
necessitates, references can fill gaps of knowledge.
In Linux, there is a way to keep you
covered about interesting, ambiguous commands: the commands man,
info, and whatis. Whatis is my personal favorite because it gives a
one-line description of the purpose of the command. Man is useful as
a reference of commands. So, say I want to know what bzr is.
Simple, I write up
whatis bzr
And there you go: Bazaar
next-generation version control.
I/O - Input, Output
The Linux terminal knows how to invoke
I/O. What you type onto the terminal is an input, and the results
that are spit out are outputs. Outputs actually come in two forms,
standard output and standard error. The interesting thing is that
the outputs are linked to the screen, so that you could see it them
with your own eyes. For instance, if you invoked the ls command,
which lists directory files, in usr/bin, the near equivalent of the
Program Files folder in Windows, then you would receive an output of
the entire program list.
ls -l /usr/bin
Now here's the catch. Say you want the
output to be stored in a file, not directed to the screen.
Manipulating the I/O to redirect the output comes in handy. All you
need to do is use the > command.
ls -l /usr/bin > bin-output.txt
This would put the output you normally
see on the screen arrives to your .txt file. But it also overwrites
the contents of the intended file. If you want to append (add on)
the output, we could use >>.
ls -l /usr/bin >> bin-output.txt
There are all sorts of possibilities
that spring to my mind with Linux's redirection ability. Perhaps I
want to share an error message if any with a fellow developer who can
review it and discuss it with me in detail. Or show the measures I
took and have the community help me out with a problem.