Finding the Executable Path of Newly Installed Programs on Debian and Ubuntu

You just installed a cool new program on your Debian or Ubuntu system using apt, but when you try to run it from the command line, you get the frustrating "command not found" error. How do you figure out where apt put the executable so you can actually use the program?

This is a common issue that trips up Linux beginners and even some veterans. The name of the executable doesn't always match the name of the package you installed. But with one quick command, you can uncover the full path to the binaries and launch your new software.

How Package Management Works on Debian/Ubuntu

Before we look at how to find the executables, it helps to understand what's happening behind the scenes when you run apt install.

Debian-based distributions like Ubuntu rely on the dpkg and apt tools to install and manage software packages. When you install a package with apt, here's what it does:

• Downloads the .deb package file(s) from the repositories

• Uses dpkg to extract the files and place them in the proper locations on your filesystem

• Updates system databases and caches to record the installation

The key thing is that dpkg installs binaries, libraries, configs and other files in standardized locations. For example:

• Binaries: /usr/bin, /usr/sbin, /usr/games

• Libraries: /usr/lib, /usr/share/lib

• Config Files: /etc

• Docs and Manuals: /usr/share/doc

Knowing this structure helps you hunt down where that executable landed.

Using dpkg -L to List Package Contents

The dpkg tool offers a handy way to see everything an installed package dropped onto your filesystem.

The -L option will show all the file contents for a package. For example, to see what's inside the firefox-esr browser package:

dpkg -L firefox-esr

This will spit out the full pathnames for the config files, binaries, manuals, and other goodies:

/.
/usr
/usr/lib
/usr/lib/firefox-esr
/usr/lib/firefox-esr/firefox-esr
/usr/lib/firefox-esr/crashreporter
/usr/lib/firefox-esr/webapprt-stub
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/firefox-esr
...
/usr/bin/firefox-esr

See that last line with /usr/bin/firefox-esr? That shows the actual Firefox ESR executable that you can launch from the command line or application menu.

So when you install a package and want to use the programs, look for the files landing in /usr/bin or /usr/sbin. Those directories hold almost all user-facing executables.

Understanding the $PATH Variable

The reason /usr/bin and other directories work seamlessly when you run commands is due to the $PATH environment variable. This defines all the places your Linux shell should search when you enter a command name.

Check out the folders in your path:

echo $PATH

Typical output looks like:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

See those /usr/bin and /usr/sbin folders? That's why newly installed programs magically run when you invoke them. The shell automatically looks in those PATH locations.

So anytime apt puts an executable into /usr/bin, /usr/sbin or other standard PATH folders, you'll be able to launch it. But you may still need dpkg -L to find custom executables or binaries landing outside the path.

Real-World Examples of Using dpkg -L

Let's see a couple examples of using dpkg -L to unmask an installed program's path.

Finding Visual Studio Code Binary

Say you install the Visual Studio Code editor which has an unusual package name of code:

sudo apt install code

But trying to run it gets a command not found error:

$ code
zsh: command not found: code

Use dpkg -L to find the executable:

dpkg -L code
...
/usr/bin/code
...

Aha! The binary is called code after all, so now you can properly launch VS Code:

$ /usr/bin/code

Locating Extras Like Man Pages

Beyond just the main executables, dpkg -L lets you discover all the ancillary content included with a package.

For example, say you want to read the man page for the systool binary that comes with the sysfsutils package. You could install sysfsutils and then dig around the filesystem for the man pages.

But it's easier to just check the dpkg output:

dpkg -L sysfsutils | grep man

/usr/share/man/man1/systool.1.gz
/usr/share/man/man8/lsbus.8.gz

Then you know exactly where the systool docs landed, in /usr/share/man/man1/systool.1.gz.

Wrap Up

While Linux package management with apt and dpkg generally "just works", you'll occasionally need to peek under the hood to figure out where your newly installed programs landed. Using the handy dpkg -L <package> command reveals all the installed file contents so you can hunt down the binaries, libs, and other software pieces.

Knowing a few key Linux filesystem facts also helps:

• User programs in /usr/bin

• System/admin programs in /usr/sbin

• Libraries under /usr/lib and /usr/share

• Configs live under /etc

Armed with dpkg -L and an understanding of the Linux directory structure, you can quickly unmask the executable path for any installed package. No more frustrating "command not found" errors!