How do you get version info for OS X files with relevance?

How do you get the equivalent of the Version: below for a file on OS X?

Seems like the result should be: 1.9.2.56 (BuildVersion: 1.9; BuildDate: Wed Nov 04 2015 01:13:06 ), Copyright 2009-2015 Adobe Systems Incorporated. All rights reserved.

The part I really care about in this case is 1.9.2.56

I’d be interested in how to get this info from the command line in general, and how this info is stored, but hopefully with relevance as well.

References:


CC: @AlanM @rustymyers @hansen_m

1 Like

That is the version of the kernel, not the version of an arbitrary file. Not sure how this relates to my question.

So do you want the version of an application?

We have some limitations here but its just as simple as Windows via relevance

Q: version of regapp "iMovie.app"
A: 10.1.1

Specifically unix executables:

1 Like

Yeah the current limitation is it needs to be a bundle.

The first line would have dropped the version if it had it (but its all empty strings)

Please file an RFE?

2 Likes

I’ve thought about this many times. The only thing I’ve figured would work is an analysis that captures needed binaries’ version output, munges the strings as needed, then saves in a result.

1 Like

The listed examples might be using a Classic-era HFS property that predates bundles.

mdls might expose some clues.

1 Like

For non-bundle apps, like the one in the example, you’d want the command line dev tools installed (which shouldn’t require all of xcode). Then you can use otool to grab the data:

otool -P /Applications/Utilities/Adobe\ Application\ Manager/core/RemoveAAM |grep -A
1 CFBundleVersion

3 Likes

!!! This is exactly what I was looking for as far as getting this info on the command line.

Now hopefully I can figure out how to do the same with relevance, or an inspector added to do the same.

The otool -P option lists this in the help: -P print the info plist section as strings

There seems to be an embedded info plist section within the file itself where this data comes from.


###Get the plist info using otool

command: otool -P RemoteUpdateManager

Output:

RemoteUpdateManager:
(__TEXT,__info_plist) section
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleDevelopmentRegion</key>
	<string>English</string>
	<key>CFBundleIdentifier</key>
	<string>com.adobe.PDApp.Enterprise.RemoteUpdateManager</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundleName</key>
	<string>RemoteUpdateManager</string>
	<key>CFBundlePackageType</key>
	<string></string>
	<key>CFBundleShortVersionString</key>
	<string>1.9.2.56 (BuildVersion: 1.9; BuildDate: Wed Nov 04 2015 01:13:06 ), Copyright 2009-2015 Adobe Systems Incorporated. All rights reserved.</string>
	<key>CFBundleSignature</key>
	<string>????</string>
	<key>CFBundleVersion</key>
	<string>1.9.2.56 (BuildVersion: 1.9; BuildDate: Wed Nov 04 2015 01:13:06 ), Copyright 2009-2015 Adobe Systems Incorporated. All rights reserved.</string>
</dict>
</plist>

It seems like the hard part is getting the (__TEXT,__info_plist) section string, and then the plist inspectors should be able to do the rest from there, though I don’t know if they can work from strings instead of files like the XML inspectors can. Yet another need for XML inspectors on the Mac AND potentially improvements to the plist inspectors.


get the file section info for __info_plist using otool

command: otool -l RemoteUpdateManager

Output: (only the relevant part of it)

Section
  sectname __info_plist
   segname __TEXT
      addr 0x0001daaa
      size 0x000003bc
    offset 117418
     align 2^0 (1)
    reloff 0
    nreloc 0
     flags 0x00000000
 reserved1 0
 reserved2 0

get the raw HEX data from the __info_plist file section

command: otool -X -s __TEXT __info_plist RemoteUpdateManager


get the raw HEX data from the __info_plist file section and convert to string

command: otool -X -s __TEXT __info_plist RemoteUpdateManager | xxd -r


References:

RFE submitted: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=87981

Please vote on my RFE if you would find this useful!

Also, this RFE: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=87863

Since the RFE links are dead, I’ve submitted a new Idea here: https://bigfix-ideas.hcltechsw.com/ideas/BFLCM-I-257