sasha at asksasha.com
Wed Sep 4 12:33:29 MDT 2013
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
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 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 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.
Use the standard configuration file for the per-login-session
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.
Fast Running Blog.
Run. Blog. Improve. Repeat.
More information about the PLUG