context: ubuntu-class Linux systems, apt package management
Other package management systems: https://www.digitalocean.com/community/tutorials/package-management-basics-apt-yum-dnf-pkg
)
Systems often differ in the location of their files. The same file may reside in /etc, /usr/local/etc, /opt/etc, or some arbitrary place given during utility's compilation.
To figure out where it is, a suitable package (usually mlocate) has to be installed and the updatedb indexing run so the database of the files can be created.
Beware, the database is a snapshot in time. After installing a new package, the indexing has to be run again as the new files aren't in the database yet.
A way slower alternative, suitable for more ad-hoc conditions, is find (Unix)
together with grep.
MacOS uses mdfind for the same purpose.
APT (software) - relevant for apt-get, similar may exist for other packaging systems
Often there is a complaint from some process that a certain file is needed and can not be found. Typical situation for compilation from sources, when some heaer file is missing - it can be installed easily with simple apt-get packagename-devel. Easily, when we know the package name.
So,
Again, the thing depends on a local database. This can be synced with the repository by
If the thing barfs too much data, grep is a friend.
The search string matches the whole file path. Matches on directories can be used with grep.
If looking for a command, use "bin/<command>". Same for libraries, "lib/<file>".
[link?:./configure] complains about
The running processes may be rather "opaque" at times. They complain something cannot be done, while keeping for themselves that some file is missing or can't be accessed. Error messages tend to be incomplete or misleading.
Fortunately the process' system calls can be monitored. Running
strace can be also attached to an already running process. Handy when trying to find what a daemon is doing when connected to.
strace on a process can yield important clues about its activity, especially its assumption about location of files.
Detailed example of finding the wget SSL certificate store is here:
Often the answer to a tricky question about a file is hidden in the file itself. File paths, subcommands, error messages, a lot of sometimes confusing sometimes helpful data can be discovered by the strings utility. It takes a binary file and outputs everything that may seem to be legible string. Most of the output are pieces of binary nonsense. The rest can contain important data.
Generally useful when grasping straws and not having an idea what's happening. Seeing the file content, the human-readable parts, may or may not give hints.
Example is the firmware file of Raspberry Pi. Let's say the problem is finding what SDTV related directives
the config.txt file can use. So,
The commands are:
Different firmware versions can float around and support different features. This trick allows expedient finding out what ones are present.
Presence of something that looks like config.txt variable is not a guraantee it is functional there. Its absence is however an indicator the feature is missing.
Approach fails on compressed files.
interrogates the Desktop Management Interface of the computer, shows data about hardware including motherboard type,
memory slots, CPU/cache, available ports, system slots (PCI, PCI-e...), sensors...
relies on SMBios, does not work on eg. embedded platforms not implementing it (Raspberry Pi, looking at YOU!)
interrogates various /proc files and memory areas, dumps memory blocks with BIOS and other data as hex, dumps SMBios structures where available, lists interrupts/ioports/DMA, sysfs drivers, CDROM drives (remember these?), disks and partitions...
Handy to save to a file for asset management.