Ten Commands Every Linux Developer Should Know

A few simple utilities can make it easier to figure out and maintain other people's code.

This article presents a list of commands you should be able
to find on any Linux installation. These are tools
to help you improve your code and be more productive.
The list comes from my own experience as a programmer
and includes tools I've come to rely on repeatedly.
Some tools help create code, some help debug code
and some help reverse engineer code that's been dumped
in your lap.

1. ctags

Those of you addicted to integrated development environments (IDEs) probably never
heard of this tool, or if you did you probably think
it's obsolete. But a tags-aware editor is a
productive programming tool.

Tagging your code allows editors like vi and Emacs
to treat your code like hypertext (Figure 1).
Each object in your code becomes hyperlinked to
its definition. For example, if you are browsing
code in vi and want to know where the variable foo
was defined, type :ta foo. If your cursor
is pointing to the variable, simply use Ctrl-right
bracket.

Figure 1. gvim at Work with Tags

The good news for the vi-impaired is ctags
is not only for C and vi anymore. The GNU version
of ctags produces tags that can be used with Emacs
and many other editors that recognize tag files.
In addition, ctags recognizes many languages other
than C and C++, including
Perl and Python, and even hardware design
languages, such as Verilog. It even can produce a human-readable
cross-reference that can be useful for
understanding code and performing metrics.
Even if you're not interested in using ctags in your
editor, you might want to check out the human-readable
cross-reference by typing ctags -x *.c*.

What I like about this tool is that you get useful
information whether you input one file or one hundred
files, unlike many IDEs that aren't useful unless
they can see your entire application. It's not a
program checker, so garbage in, garbage out (GIGO)
rules apply.

2. strace

strace lets you decipher what's going on
when you have no debugger nor the source code.
One of my pet peeves is a program that
doesn't start and doesn't tell you why. Perhaps
a required file is missing or has the wrong
permissions. strace can tell you what the program is
doing right up to the point where it exits. It can
tell you what system calls the program is using and
whether they pass or fail. It even can follow forks.

strace often gives me answers much
more quickly than a debugger, especially if the code
is unfamiliar. On occasion, I have to debug code on
a live system with no debugger. A quick run with
strace sometimes can avoid patching the system or
littering my code with printfs. Here is a trivial
example of me as an unprivileged user trying to delete
a protected file:

strace also lets you attach to processes for
just-in-time debugging. Suppose
a process seems to be spending a lot of
time doing nothing. A quick way to find out what
is going on is to type strace -c -p mypid.
After a second or two, press Ctrl-C and you might see a dump something like
this:

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.