Let's consider some examples of how to get the package file names and paths on Arch based system. Let's start with the command that is a bread-and-butter, pacman package manager.

Determine which package(s) own a file

To find out which package owns a file, two very similar approaches can be applied. The first one assumes the presence of the up-to-date database via pacman -Fy:

pacman -F path/to/package/file  # pacman --files

path/to/package/file is owned by repository/package-name 1.2.3-1
path/to/package/file is owned by repository/another-package 2.3.4-2

The second one, as with other -Q related parameters, requires the package and the queried file to be installed on the system:

pacman -Qo /path/to/package/file # pacman --query --owns

/path/to/package/file is owned by package-name 1.2.3-1

The output difference concerning the leading slash denoting a fully functional absolute path with the -Qo option is present here as well. Subsequently, the -Qo option only accepts the full path to the queried file and only returns a single matching locally installed package, if present.

The -F option on the other hand accepts either a file name or the full path to the file. It returns all the matching packages, also denoting which package repository the file in question belongs to, like core, extra or community. Additionally it also informs the user if the particular package is installed on the system already and resorts to prettier output formatting, when only the file name is supplied.

Listing files in a package

Again, two similar approaches can be applied utilizing pacman. The first one is assuming the database is already up-to-date via pacman -Fy:

pacman -Fl package # pacman --files --list

package path/to/package/file1
package path/to/package/file2

And the second one is assuming the package is installed on the system:

pacman -Ql package # pacman --query --list

package /path/to/package/file1
package /path/to/package/file2

Both outputs are comparably similar with the subtle difference, which is a leading slash. The -Ql option outputs it, while the -Fl doesn't. Don't ask me why, I have yet to find out.

My aliases

I felt so confident in the pacman options and used them so often that they gradually find place within my aliases:

alias pF='pacman -F'
alias Fl='pacman -Fl'
alias Ql='pacman -Ql'
alias Qo='pacman -Qo'

I think you have some pacman, or even yay related aliases defined as well, but it is mostly a matter of personal preference.

Listing executables of a package

On some occasions, even more useful than listing all the files the package provides is to list its executable files only. Utilizing the above, there are again at least two options that I find myself using regularly, depending on the conditions already described. Using either files database:

pacman -Fl package | grep bin

Or querying the local packages:

pacman -Ql package | grep bin

However, these two approaches are not ideal, as it also lists directories or non-executable files containing bin substring anywhere in the path. This could be mitigated by some more bash-fu hacking, but for quick probing, simple grepping was sufficient for all my use cases so far.

There's a another way

The above examples felt robust enough I've thought that I have pretty much nailed them, until I have stumbled across a comment on the Arch Linux forum, that changed my perspective. The humble post states:

pkgfile netstat

core/net-tools

For me this was a revelation, as I was not aware of the fact such a tool is available. I instantly tried to use the pkgfile command, but it was not present on the system. Armed with the knowledge already presented in the previous sections, it was not a problem to find out how to obtain it:

pacman -F pkgfile

extra/pkgfile 21-2
    usr/bin/pkgfile
    usr/share/bash-completion/completions/pkgfile

Yeah, the package name is the name of the executable. Very common, but not always the case. I could have just tried to install it straight away:

pacman -S pkgfile

Let's explore its options.

Enter pkgfile

Learning from the manual now available via man pkgfile as the package is present offers alternatives to the mentioned pacman options:

  • pkgfile -u or pkgfile --update is equivalent to pacman -Fy
  • pkgfile -s or pkgfile --search or simply pkgfile is equivalent to pacman -F
  • pkgfile -l or pkgfile --list is the equivalent to pacman -Fl

The difference is that the standard output of pkgfile is far less verbose, mostly omitting any natural language words, which is not a problem as the relevant data are printed out, straight to the point. Some details, such as package versions can be included using --verbose option, as is usually the norm.

What's more, pkgfile provides some neat options not previously known to me to be readily available, greatly mitigating the problems described in previous chapter discussing listing binaries. To list files provided by a package located only within bin and sbin folders run:

pkgfile -lb package # pkgfile --list --binaries

The directories are omitted he by default. To list them instead run:

pkgfile -ld package # pkgfile --list --directories

I consider learning pkgfile to be a great addition to my system management toolbelt. I have also found that pkgfile is little bit faster than pacman in this respect, almost instant. Feel free to experiment yourself.

This is a 43th post of #100daystooffload.