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 -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.
-Qo option only accepts the full path to the queried
file and only returns a single matching locally installed package, if
-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 -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.
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:
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.
Learning from the manual now available via
man pkgfile as the package is
present offers alternatives to the mentioned pacman options:
pkgfile --updateis equivalent to
pkgfile --searchor simply
pkgfileis equivalent to
pkgfile --listis the equivalent to
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
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
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.