The following is a practical example to illustrate the usefulness of having the program name as
To accomplish a certain task, I often need to read the manual pages. But this is often tiresome, and a lot of time is wasted when reading the man pages over and over again any time I need to use the same command or need to do the same thing in the future.
So I started making small, textual notes about each command I use the most, and use it in an outliner (emacs'
Using an outliner helps to collapse or show large portions of text, making navigation easier, and accessing desired information quicker. When used properly, it makes reading and maintaining documentation much more efficient.
To get help on a specific command, for example
strace, instead of doing
man strace, I did
In the beginning, I wrote aliases that looked like this:
alias strace.help='emacs ~/help/strace'
alias tcpdump.help='emacs ~/help/tcpdump'
alias ps.help='emacs ~/help/ps'
but then I thought wait, this is really stupid. why should I have x aliases that all look the same? isn't this crying for refactoring? So I rewrote the aliases into a single aliase creating bash function, using
eval inside a for loop, so the aliases were created dynamically, but that still seemed wrong...
Then I remembered the
argv trick that I saw while exploring the source code of some the most common unix/linux commands: write a single program that behaves differently depending on how it's called.
So I wrote a generic
command.help script that looked like this:
# make sure to stip the .help suffix
if [[ -f ~/.bash_lib/help/$commandname ]]
echo "no custom help available for $commandname"
filename.ext.remove are short
bash utils and showing their code has no relevance here.
I put that script in my
$PATH, then I created multiple links
command.help, with different names:
so now, anytime I add a new help note for a command, say
zip, I only need to create a new link to
command.help under the name
zip.help, and it will magically open the help file for the