hmm, no exit/error code, that's unfortunate, that's the easy way to test, ok.

Maybe I will have to do version detection.

dmidecode --version
2.11

does 2.10 show the same syntax? That's why I don't like trying to parse / use version numbers, for all we know it can be prebeta-2.12-alpha16 as version number, there's absolutely no rule that says a version number has to be arithmetically sound. Could be 2.11.04 etc.

No, let's skip version number checking, those can't be trusted, best to test methods etc. I'm surprised it doesn't return an error for giving it an option it does not support, that's a bug I would say, but obviously too old to file a bug report about.

Actually I realize what it is, the message means what it says: Not Specified. hmmm.

I need a test more reliable I think, that's not going to do it, any empty field could return that message I believe.

Isn't there something that 2.11 and later do that 2.10 doesn't do that we can test for error return?
Back to top

I ran several --version's this morning and found out that they are fairly standard. If you query via rpm, for example, then you would get a lot more revisions like you said "prebeta-2.12-alpha16".

# dmidecode 2.2
# dmidecode 2.3
# dmidecode 2.10
# dmidecode 2.2
# dmidecode 2.11
# dmidecode 2.2
# dmidecode 2.3


Let me do some digging.

I also sent you a PM with the dmi information in code brackets.
Back to top

As you can see, the version numbers are not actually numbers in the normal sense:

2.1 < 2.11 but 2.2 > 2.11

this is why I in general avoid version number testing. In a sense, one can do the following, although i don't like getting into specific logics for only one app, this is how another script I do handles numbers, it splits the number into its components, then compares each part to the the part of the other number, ie:

for say, 2.2 vs 2.10
2 ><= 2 => 2 >=< 10

debian in particular can and does release things with beta version numbers, and out of the blue an app can suddenly use v2.13 or whatever, the more of these numbers you see the less you will want to use them.

but this is really something I want to avoid getting into in inxi, particularly for a feature that will be so little used. It's much more reliable to simply find something that will make 2.10 and earlier return error but 2.11 and newer no error, that's 100% solid and requires no hacks, that's the same idea in web testing, test for the method, not the browser/number etc.

I have a sneaking suspicion that dmidecode actually had the -s logic built into it but not documented in 2.10, which is why the option doesn't return error.

Let me give you an example:



It looks to me like they had implemented -s in a raw form in 2.10 but it had no actual fields set yet, so dmidecode doesn't return errors.

I suggest just looking at the help menu for 2.10 and 2.11, or the man page, which should have more options listed, and find an option that 2.11 has that 2.10 does not have, then test it until you find one that properly returns error. It has to be a real option, of course, otherwise it will always be error.
Back to top

Please note: inxi 1.8.37 now has the updated dmidecode logic running, no issues I can see.

I tested your 4 machine data sets in the new logic, and they all worked as expected.



as a bonus to dmidecode users, inxi -M will show bios version and revision number now, instead of just version. Also, with -xx, it will show bios rom size, why? why not.

I'm going to assume that closes this issue, thanks for the report.
Back to top