This is not so much about one's ability to read the Fine Manual, but
about efficiency. A little example. Suppose I am troubleshooting some
kind of a emergency on a box I am not familiar with and I do
ps auxw
and I see this:
dbus-daemon --fork --print-pid 5 --print-address 7 --session
I need to know ASAP what those options do. Granted I know enough to
guess that --fork likely means fork as a daemon, but what about the
rest? I paste the command into explainshell.com and I get this:
Message bus daemon
--print-pid[=DESCRIPTOR]
Print the process ID of the message bus to standard output, or
to the given file descriptor. This
is used by programs that launch the message bus.
--fork Force the message bus to fork and become a daemon, even if the
configuration file does not specify
that it should. In most contexts the configuration
file already gets this right, though.
--nofork Force the message bus not to fork and become a daemon,
even if the configuration file
specifies that it should.
--print-address[=DESCRIPTOR]
Print the address of the message bus to standard output, or to
the given file descriptor. This is
used by programs that launch the message bus.
--session
Use the standard configuration file for the per-login-session
message bus.
Even though I may know little about the message bus daemon In a matter
of 5 seconds I see that the pid is written to file descriptor 5, and
the address is written to file descriptor 7. I can now use lsof to
figure out where that information went to. I also know that it will be
using the standard configuration file for the per-login-session
message bus (whatever that means exactly, but maybe I do not care at
this point), and I see that my guess about --fork was correct, but
there is one detail I might have missed that may be important - even
if the config file tells dbus-daemon not to fork in the background, it
will do it anyway because of --fork on the command-line.
If I want to go deeper I can look at the man page, source code, run
strace, or gdb, but that is beside the point. In a matter of 20 or so
seconds I got a good idea of what a random process I caught with ps is
at least supposed to be doing on the system according to the
documentation which without explainshell.com would have taken me
probably 5 times as long. If the troubleshooting process involves a
large number of such investigations, this could make a difference
between figuring it out in 1 hour vs 5 hours.
Do not scoff at simple things. Remember that by small and simple means
are great things brought to pass.
--
Sasha Pachev
Fast Running Blog.
http://fastrunningblog.com
Run. Blog. Improve. Repeat.
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
