Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am looking for a structured format of version info for OS-level executables, such as in /usr/bin and /usr/local/bin. The problem we are having is the inconsistent architecture between our PROD and TEST environments and we are finding that many executables in our lower environments have had patches applied whereas PROD has not, which invalidates a lot of testing -- stuff works in TEST but doesn't in PROD because of such system discrepancies.

So I would like to run a system assurance check to list all executables and get the version number but nothing else and then produce deltas. Some commands don't support the -version option but even those that do display very verbose, free-text format of a version narrative and the version number is buried somewhere within, with no way to extract it programmatically.

Alternatively, I was thinking to run a file-level cksum for every executable as an option of last resort but I was hoping that there would be a way to extract version info relevant fields programmatically.


share|improve this question
BTW, what distribution of Linux are you using? –  mdpc Dec 20 '12 at 21:32
We have environments in both SunOS 10 and RHEL 5.8 as we are in a slow process of migrating to the latter. But i gave /usr/bin as just an example. Some of the problems are there but more problems are with post-OS install applications installed in /opt and things lile /usr/<APP_DIR>/bin –  amphibient Dec 20 '12 at 21:36
like for example /usr/foo11.5/utilprogram -version in one environment will be 11.5, in another will be 11.5.1 because they applied a patch and that breaks everything. but both envs' utilprogram is in the same dir (/usr/foo11.5) so from a distance they look like they should be the same. the checksums are different. –  amphibient Dec 20 '12 at 21:39
Looks like checksuming, using something like the sha2sum program, is your best bet. That should be relatively easy to program. –  mdpc Dec 20 '12 at 21:41

4 Answers 4

up vote 3 down vote accepted

I'm inclined to say there is no easy way to do this. I say this because versioning is not at all a standarized procedure in UNIX/Linux or with any of the vendors at least at a program level.

A suggestion might be to examine the installed package information which does contain versioning information.

However, if people install products not using the standard package manager for your distribution, then you'll have faulty information as well.

To be absolutely sure, you'll probably have to go with some type of testing checksums between the systems.

share|improve this answer

As you already received an answer from @mdpc I'll just provide an opinion to your original problem. I wouldn't go down this road as this opens a can of worms and your programs in general should run on all systems (also check if your system still works if you run in a different local). You should also not really rely on the output/commands themselves but use the appropriate API to access/modify the information.

Anyway here are some ways which could help to mitigate your problem:

  1. Use configuration management and specify which programs/libraries have to be installed on the machine. You can typically also specify the version number. Another great thing about using configuration management is that you can typically get all the information about your system, i.e. which kernel is running, how many NICs are in the system etc.
  2. Depending on the programming language you are using you may want to look into virtualized environments, i.e. bundler for ruby or virtualenv for python.
  3. Use chroots to setup an environment to your specific needs or (even better)
  4. Just ship your environment as a VM-image
share|improve this answer
Yes, I would do all that if I were the CIO/CTO here who can dictate such decisions to be implemented. But I am an end-of-the-food-chain developer in a large organization which obviously doesn't have the best control of their change management -- so i have to find workarounds –  amphibient Dec 20 '12 at 21:59
so i have no control over the OS-platform which is handed to me to host my app on. they give me a root directory where i can deploy my app but i have no control over what is in /usr/bin, even /opt. if i want to change any of that, even with the best of documentation showing dire need, i am fighting an uphill battle of red tape and will be long and hard –  amphibient Dec 20 '12 at 22:02
@foampile then ask for a VM and provide everything which is needed, most organisations already have a virtualization solution and are able to run such images. –  Ulrich Dangel Dec 20 '12 at 22:24

Packages are the answer (you should know that if you come from SunOS).

On CentOS you should use RPMs - nothing else.

Force your developers to deliver everything as rpm - then you will have that structured information in your RPM-database (which can even be queried with standard SNMP-tools).

share|improve this answer
thanks but, like i said above: "I am an end-of-the-food-chain developer in a large organization" who is in no position to "force" other developers into any practice. but your idea sounds appealing –  amphibient Dec 20 '12 at 22:05
IOW, i work within rigid constraints –  amphibient Dec 20 '12 at 22:06
@foampile If you can not force others to do stuff well, speak to your superior and make that idea his (or convince your co-workers). –  Nils Dec 21 '12 at 21:12

As far as Solaris 10 is concerned, files belonging to the OS and files provided by third parties in the form of SVR4 packages are already versioned/checksumed and identified. e.g. :

 # pkgchk -l -p /usr/bin/ls
Pathname: /usr/bin/ls
Type: regular file
Expected mode: 0555
Expected owner: root
Expected group: bin
Expected file size (bytes): 18700
Expected sum(1) of contents: 1763
Expected last modification: Mar 25 00:04:57 2010
Referenced by the following packages:
Current status: installed

Most of this information is in the /var/sadm/install/contents file. Files that weren't installed using the standard tools, i.e. file provided as a tarball or a zipped archive are unknown of the package database so must be processed a different way. Checksums comparison looks like a good approach to detect discrepancies as there is no standard anyway.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.