note
afoken
<p>[man://dmidecode] has even more useful switches:</p>
<blockquote><dl>
<dt>-s KEYWORD</dt>
<dt>--string KEYWORD</dt>
<dd>Only display the value of the DMI string identified by KEYWORD. [...]</dd>
<dt>-t TYPE</dt>
<dt>--type TYPE</dt>
<dd>Only display the entries of type TYPE. TYPE can be either a DMI type number, or a comma-separated list of type numbers, or a keyword from the following list: bios, system, baseboard, chassis, processor, memory, cache, connector, slot. Refer to the DMI TYPES section below for details. [...]</dd>
<dt>-u</dt>
<dt>--dump</dt>
<dd>Do not decode the entries, dump their contents as hexadecimal instead. [...]</dd>
<dt>--dump-bin FILE</dt>
<dd>Do not decode the entries, instead dump the DMI data to a file in binary form. [...]</dd>
</dl></blockquote>
<p>You could use <c>-s</c> and <c>-t</c> to filter inside dmidecode, so that you have less data to process.</p>
<p>The <c>-u</c> switch generates a slightly more predictable format. You could decode the hexdumps inside perl, using knowledge from [mod://DMI::Decode] (i.e. copy and port the C code from there to perl).</p>
<p>The <c>--dump-bin</c> switch delivers the raw DMI data, which you could decode all by yourself, again by using knowledge from [mod://DMI::Decode].</p>
<p>Alexander</p>
<div class="pmsig"><div class="pmsig-747201">
--<br>
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
</div></div>
1010730
1010743