I usually do
dpkg -L packagename | grep -E '/s?bin/'
to get the list of everything "callable" that package offers.
The rule is simple: as per Debian policy (and the FHS) all programs callable by regular users (non-admin) must place their binaries (or links to them, usually symbolic) under /bin
or /usr/bin
1, and all programs callable by sysadmins must place their binaries (or links to them) under /sbin
or /usr/sbin
1.
Any local programs—not installed from packages, and therefore not part of "the system"—have to place their callable binaries under /usr/local/bin
or /usr/local/sbin
—these places are "yours", and you're guaranteed no package installed from official repositories will ever place/link a binary there.
If you run
echo $PATH
in your terminal as a regular user, you'll see /bin
and /usr/bin
and /usr/local/bin
listed—that's where the shell looks for the non-builtin commands you ask it to run. The superuser will have "sbin
" versions of these directories listed as well.
And finally one minor note: you can't—just by looking at the list of programs a package offers—determine which of them are command-line ("callable in a terminal") or GUI (requiring an X server to connect) because both kinds of programs are placed in the same hierarchy of directories. On the other hand, those GUI applications which wish to integrate into the desktop environment (such as GNOME, KDE, XFCE, LXDE etc) usually provide the so-called "desktop files" (ending with the .desktop
extension) which give their program a descriptive title, a description of its purpose and state the way the application has to be called. These files are scanned by the desktop enviroment and are displayed in its "application menu" (or are otherwise used in a similar way). Hence if you're looking for this kind of programs, you might grep
the output of dpkg -L
for .desktop
.
1 The distinction between the /usr
and /
hierarchies is subtle and currently debatable in the Linux-centric communities so let's not digress into discussing it.