Bash commands to fetch "info version" included in an executable? lazarus / 1-Linux ---------------------------------------------------------------------- devEric69 · 2021-03-09 10:53 Hello, I want to include a FileVersion and a ProductVersion in a Linux executable (from the "Options for project" window in the Lazarus IDE). Under MS-Windows, I can see them when I make right-click and turbo- menu "File properties" of the binary. Under Linux (Debian or Ubuntu), only the ugo rights are displayed. Is it possible to obtain these "info version" included in the executable, under the Linux OS itself? ---------------------------------------------------------------------- lucamar · 2021-03-09 11:03 No, there's no "standard" way to read this info in Linux as in Windows. Though you can easily write a "GetExeInfo" utility in (Free) Pascal by yourself. ---------------------------------------------------------------------- MarkMLl · 2021-03-09 11:05 I don't think so, at least in a formatted form. There's stuff in https ://github.com/MarkMLl/Contec_cms50dplus/blob/main/common/inifilesabout .pas for doing it under program control. readelf -n will show you some relevant stuff e.g. the build version from the linker, otherwise there might be something in objdump. TResourceStream in the FCL should give an indication of how the resources (which includes the version info) are stored in the binary (an ELF file). But as I've said I anticipate that formatting will be a problem, and there's somewhere around zero chance of getting the developers responsible for the various desktop environments and overall distreaux to "prettify" it... Hell, if they can't agree on something useful like FatELF of a code-signing mechanism... MarkMLl ---------------------------------------------------------------------- devEric69 · 2021-03-10 08:04 Quote from: MarkMLl on March 09, 2021, 12:05:30 pmI don't think so, at least in a formatted form. There's stuff in https://github.com/MarkMLl /Contec_cms50dplus/blob/main/common/inifilesabout.pas for doing it under program control. Thanks for the info and sharing. Quote from: MarkMLl on March 09, 2021, 12:05:30 pmthere's somewhere around zero chance of getting the developers responsible for the various desktop environments and overall distreaux to "prettify" it... Hell, if they can't agree on something useful like FatELF of a code- signing mechanism... Indeed, I already tried with readelf: but it's still very "raw", an improved header dump like objdump does. So, I wanted to know if there was something else natively in the OS like other commands, or rather graphically, I had missed. I have my answer, now. Otherwise, effectively it is quite simple to display this information from inside the compiled binary, in an "About" window or a command line "-h" option, from the versionresource.pp unit, ..., using TResourceStream. Thank you for your answers. ---------------------------------------------------------------------- marcov · 2021-03-10 10:00 readelf shows toolchain info, not user version info? ---------------------------------------------------------------------- dbannon · 2021-03-10 11:03 The linux approach is more to pass the binary a -v or --version, from, obviously, the command line. Its somewhat universal that linux binaries respond with some sort of version information and exit when you do that.  Obviously, not useful from a GUI .... Davo ---------------------------------------------------------------------- MarkMLl · 2021-03-10 11:26 Quote from: dbannon on March 10, 2021, 12:03:46 pmThe linux approach is more to pass the binary a -v or --version, from, obviously, the command line. Its somewhat universal that linux binaries respond with some sort of version information and exit when you do that.  Obviously, not useful from a GUI .... I believe the -- variant was a GNUism, and it's certainly been supported since I started using GNU utilities in the early 90s. Lazarus handles --version and --help properly, fpc doesn't. The readelf utility can report the build ID optionally inserted into a binary by the linker (i.e. the value depends on the project and isn't the linker version), but that's very little use in practice since it can be trivially spoofed. That's stored as a "Note". I've not worked out what one should ask readelf to get even an unformatted dump of resources. I'm sure it makes sense to somebody... MarkMLl ---------------------------------------------------------------------- marcov · 2021-03-10 12:21 Quote from: dbannon on March 10, 2021, 12:03:46 pmThe linux approach is more to pass the binary a -v or --version, from, obviously, the command line. Its somewhat universal that linux binaries respond with some sort of version information and exit when you do that.  Obviously, not useful from a GUI .... Or in any way to use programmatically since it requires program specific parsing. So this is a different thing IMHO. (compare fpc -v  vs fpc -iV ) ---------------------------------------------------------------------- lucamar · 2021-03-10 13:03 Quote from: marcov on March 10, 2021, 01:21:17 pm(compare fpc -v  vs fpc -iv ) Fun fact: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i lucamar@Diana:~$ fpc -vFree Pascal Compiler version 3.2.0 [2020/07/07] for x86_64Copyright (c) 1993-2020 by Florian Klaempfl and othersFatal: No source file name in command lineFatal: Compilation abortedError: /usr/bin/ppcx64 returned an error exitcodelucamar@Diana:~$ fpc -ivError: Illegal parameter: -ivError: /usr/bin/ppcx64 returned an error exitcode It should be remembered that fpc options are case-sensitive; I think you meant fpc -iV: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i lucamar@Diana:~$ fpc -iV3.2.0 ---------------------------------------------------------------------- marcov · 2021-03-10 13:22 Yeah, typo, corrected. But the point is that something visible somewhere, and something machine extractable are two different things. This also goes for FPC, which has a bunch of fpc -i options to that effect. ---------------------------------------------------------------------- dbannon · 2021-03-10 22:29 Getting back to Eric's question, I assume he is writing both the pascal binary and the bash script (if any) that will be inquiring about the binary's version.  So, parsing output from -v should not be a problem. (And away from Eric's question again, I too think its a strange omission that FPC does not respond, as it should IMHO, to -v and/or --version). Davo ---------------------------------------------------------------------- lucamar · 2021-03-10 23:41 Quote from: dbannon on March 10, 2021, 11:29:48 pm(And away from Eric's question again, I too think its a strange omission that FPC does not respond, as it should IMHO, to -v and/or --version). Granted for --version but for -v it does as it should: enable (any of several) verbose options. And instead of --version it has several -i(nfo) options one can use. One might contend that --version should be (kind of) equivalent to -l, but given the plethora of options it has to (and does) support it's a little nitpicking. While we are at it, I'd rather point out the strange lack of --help as sinonym for -h ---------------------------------------------------------------------- dbannon · 2021-03-11 02:23 > but for -v it does as it should: enable (any of several) verbose options. Quite correct, careless on my part.  A capital -V is sometimes used, but nowhere near 'widely'. > several -i(nfo) options one can use. Indeed, maybe that why I don't like it. It reminds of the awful 'info' tool, used where maintainers cannot write man pages !  Even -h for help is far from universal, so, maybe just  --help and --version needs to be added.  I wonder if the FPC includes a -- parser ? Davo ---------------------------------------------------------------------- marcov · 2021-03-11 07:36 Quote from: dbannon on March 10, 2021, 11:29:48 pm(And away from Eric's question again, I too think its a strange omission that FPC does not respond, as it should IMHO, to -v and/or --version). Free Pascal is not an unix program, it is portable.  The --version thingy is a GNU convention, but not otherwise enforced. ---------------------------------------------------------------------- MarkMLl · 2021-03-11 07:37 Quote from: dbannon on March 11, 2021, 03:23:34 am> but for -v it does as it should: enable (any of several) verbose options. Quite correct, careless on my part.  A capital -V is sometimes used, but nowhere near 'widely'. Before the introduction of --version, I think that -v was used for "verbose" more often than for "version". Going back to OP's question though, it's really very little to do with FPC output: while it's desirable to be able to report the version of build tools he specifically asked about build information pertaining to HIS PROJECT. I usually manage something like $ zzz --version Version 0.0 release 0 build 402 Build ID 0x13ED8078378E51CB Checkout revision 84 2021-03-04 17:51:56Z markMLl Built 2021-03-06 10:21:40 revision 84M Free Pascal v3.0.4 for x86_64 Linux but that takes a combination of extracting resources from the executable, extracting a "note" to get the build ID generated by the linker, and generating .inc files from Subversion revision information. It's all in the link I posted earlier. MarkMLl ---------------------------------------------------------------------- PascalDragon · 2021-03-11 07:58 Quote from: dbannon on March 11, 2021, 03:23:34 amEven -h for help is far from universal, so, maybe just  --help and --version needs to be added.  No. As marcov said, FPC is cross platform and not a Unix utility, we don't let the OS dictate us how we should handle parameters. Cause then on Windows or DOS we'd need to accept e.g. /? as well as that is what most utilities there use. Quote from: dbannon on March 11, 2021, 03:23:34 amI wonder if the FPC includes a -- parser ? No, cause it doesn't have any parameters with -- to handle. ---------------------------------------------------------------------- marcov · 2021-03-11 08:25 And besides being a (unenforced) convention, the results are often not really machine readable, so pretty useless for nearly anything generic other then displaying the result in some window E.g. linux "ls" doesn't respond to either -v or -V only to --version, but it is a GNU beast. (as can be readily seen as there is more facts about the license than anything useful) ---------------------------------------------------------------------- MarkMLl · 2021-03-11 08:32 Quote from: PascalDragon on March 11, 2021, 08:58:57 amNo. As marcov said, FPC is cross platform and not a Unix utility, we don't let the OS dictate us how we should handle parameters. Cause then on Windows or DOS we'd need to accept e.g. /? as well as that is what most utilities there use. And what's wrong with that? Minimal handling of --version and --help (hence potentially of /? etc.) is a convention that's now at least 30 years old, and in both cases results in rapid termination of the program after minimal output: it's not as though it has to mess up the main command-line parser. A command with no parameters at all though is application-specific. MarkMLl ---------------------------------------------------------------------- PascalDragon · 2021-03-11 12:42 Quote from: MarkMLl on March 11, 2021, 09:32:38 amQuote from: PascalDragon on March 11, 2021, 08:58:57 amNo. As marcov said, FPC is cross platform and not a Unix utility, we don't let the OS dictate us how we should handle parameters. Cause then on Windows or DOS we'd need to accept e.g. /? as well as that is what most utilities there use. And what's wrong with that? Minimal handling of --version and --help (hence potentially of /? etc.) is a convention that's now at least 30 years old, and in both cases results in rapid termination of the program after minimal output: it's not as though it has to mess up the main command-line parser. As marcov said, not even ls adheres to that. So again, no we will not adjust that. ---------------------------------------------------------------------- MarkMLl · 2021-03-11 13:15 Quote from: PascalDragon on March 11, 2021, 01:42:12 pmAs marcov said, not even ls adheres to that. So again, no we will not adjust that. ls implements the conventional --version and --help options- or at least it does on the Debian systems I run. As I've already said, -v and -V have ALWAYS HAD at least as much claim to be interpreted as "verbose" as "version", and the habit of putting major.minor.fixes version numbers on just about everything didn't really take off until people noticed Linux's use of the convention. And I don't for one moment expect you to change anything, and didn't say I did. That doesn't stop me from pointing out that FPC departs from a well-accepted convention. MarkMLl ---------------------------------------------------------------------- PascalDragon · 2021-03-12 14:52 Quote from: MarkMLl on March 11, 2021, 02:15:15 pmAnd I don't for one moment expect you to change anything, and didn't say I did. That doesn't stop me from pointing out that FPC departs from a well- accepted convention. It's a convention, not a requirement. ---------------------------------------------------------------------- marcov · 2021-03-12 15:28 Quote from: MarkMLl on March 11, 2021, 02:15:15 pmQuote from: PascalDragon on March 11, 2021, 01:42:12 pmAs marcov said, not even ls adheres to that. So again, no we will not adjust that. ls implements the conventional --version and --help options- Afaik the long versions are not Unix but GNU specific. And as said  ls commonly used on Linux is a GNU product. ---------------------------------------------------------------------- MarkMLl · 2021-03-12 15:55 Quote from: marcov on March 12, 2021, 04:28:16 pmQuote from: MarkMLl on March 11, 2021, 02:15:15 pmQuote from: PascalDragon on March 11, 2021, 01:42:12 pmAs marcov said, not even ls adheres to that. So again, no we will not adjust that. ls implements the conventional --version and --help options- Afaik the long versions are not Unix but GNU specific. And as said  ls commonly used on Linux is a GNU product. Correct. And as I've said- repeatedly I believe- it's a 30-year-old GNU convention found not only in Linux distreaux but also anywhere else the GNU utilities are available e.g. SunOS/Solaris. I for one have certainly not suggested that FPC should abandon its existing options, and neither have I suggested that it should adopt -v for "version"... that would be an utterly barmy idea since as I have (repeatedly) pointed out -v has as much of a history of being used to indicate "verbose" as it has of indicating a request for version information. But not having minimal handling of the --version and --help commands, even if the response was the same message saying how the user should be requesting more info, is ludicrous. MarkMLl ---------------------------------------------------------------------- PascalDragon · 2021-03-15 12:37 Quote from: MarkMLl on March 12, 2021, 04:55:42 pmBut not having minimal handling of the --version and --help commands, even if the response was the same message saying how the user should be requesting more info, is ludicrous. Your opinion, but not that of us FPC devs. ---------------------------------------------------------------------- MarkMLl · 2021-03-15 12:42 Quote from: PascalDragon on March 15, 2021, 01:37:18 pmYour opinion, but not that of us FPC devs. I know. MarkMLl ---------------------------------------------------------------------- marcov · 2021-03-15 13:08 Quote from: MarkMLl on March 12, 2021, 04:55:42 pmCorrect. And as I've said- repeatedly I believe- it's a 30-year-old GNU convention found not only in Linux distreaux but also anywhere else the GNU utilities are available e.g. SunOS/Solaris. We don't have a commandline handler that does long options, and while it is theoretical possible to add it, the point is still why it is so important to warrant that, I haven't heard much more  than obtaining some hypothetical bullet point with Unix-in-principle-only software (which we are not) and an already debunked option for machine query of version info. ---------------------------------------------------------------------- MarkMLl · 2021-03-15 13:30 Quote from: marcov on March 15, 2021, 02:08:43 pmWe don't have a commandline handler that does long options, and while it is theoretical possible to add it, the point is still why it is so important to warrant that, I haven't heard much more  than obtaining some hypothetical bullet point with Unix-in-principle-only software (which we are not) and an already debunked option for machine query of version info. I don't think that my shooting my mouth off about this any further is going to be particularly constructive. I will, however round off by pointing out that FPC- which (AIUI) was for a long time oriented towards unix- happily adopts the unix convention of a single leading dash indicating an option as distinct from (for example) a Windows-style / or the rarely-seen convention of using +- for turning options on or off. My sole point is that most software- and this includes Lazarus- in the modern GNU-dominated environment responds intelligently to --version and --help. I am emphatically NOT suggesting that FPC should go out of its way to display "live" version and help information in response to those, merely that it should recognise the longstanding convention and react with a hint as to what options should be used to get introductory information. And that really is my last word on the matter. MarkMLl ---------------------------------------------------------------------- marcov · 2021-03-15 13:33 FPC's origins are dos, not Unix.  Using variable switchchar was something that wasn't generally followed any more in those times, only Microsoft still did it afaik. But it could be that it was a GNU binutils influence. ---------------------------------------------------------------------- lucamar · 2021-03-15 13:47 Quote from: marcov on March 15, 2021, 02:08:43 pm[...] the point is still why it is so important to warrant that, I haven't heard much more  than obtaining some hypothetical bullet point with Unix-in- principle-only software (which we are not) and an already debunked option for machine query of version info. It's not important but it would be convenient, even if just for that portion of users that work mostly on *nix-like systems. When one is used to write: somecommand --help to get a quick view of supported options, having the command barf back with just:Code: [Select]Error: Illegal parameter: --help Error: /usr/bin/ppcx64 returned an error exitcodeis a little disconcerting, until you remember it's just -? or -h But if it's so difficult to add it then we'll shrug it away; there are certainly much more important issues to deal with. Though the message might be a little more helpful, like say adding: "Use -? or -h to see valid options"