Re: [dmidecode] dmidecode should omit warning about SMBIOS version when -q is set

[Anton Arapov]

On Thu, Mar 20, 2014 at 10:34:09AM +0100, Jean Delvare wrote:
> Hi Anton,
> 
> Le Wednesday 19 March 2014 à 18:45 +0100, Anton Arapov a écrit :
> > On Mon, Mar 17, 2014 at 01:58:40PM +0100, Anton Arapov wrote:
> > > On Mon, Mar 17, 2014 at 10:24:45AM +0100, Jens Rosenboom wrote:
> > > > Am 16.03.14 16:36, schrieb Petter Reinholdtsen:
> > > > > [Jens Rosenboom]
> > > > >> As in particular scripts call dmidecode often with -s (implying -q)
> > > > >> and expect to get only a single word (and in particular only a
> > > > >> single line of output), I propose that in this case the warning
> > > > >> about an unsupported SMBIOS version should be ommited. Most scripts
> > > > >> won't be able to handle the warning properly anyway, also most -s
> > > > >> options should still continue to work. My patch would look like
> > > > >> this:
> > > > > What about sending the warning to stderr instead?  This way scripts
> > > > > looking on stdin will not notice, while the info is still emitted.
> > > > Would be fine for me.
> > > 
> > > It's not an error message, it's INFO message. All the error
> > > messages are already routed to stderr. This very message is
> > > intentionally left to stdout because it IS important. And it can be
> > > easily filtered out in a shell scripts.
> 
> To be fair, I would call it a warning message. Of course it can be
> filtered out, but only if people expect the message, and that's
> typically not the case until it's too late. And even if filtering is
> easy, it's even easier (and more efficient) to not require filtering
> where it doesn't make sense or can be avoided.
> 
> > > The message is important because we can't guarantee the output is
> > > correct in that case. If we suppress it we might be getting reports of
> > > the wrong information interpretation. IOW users will complaint about
> > > all kind of weirdness dmidecode might show them when use new hardware.
> 
> I beg to disagree. As a general rule SMBIOS specifications are backward
> compatible and new versions merely add fields and values. Incompatible
> changes are thankfully rare, the only one I can remember of at the
> moment is the UUID byte order rules.
> 
> Old versions of dmidecode should work just fine on new DMI tables when
> it comes to option -s at least. This is what the original poster (Jens)
> really cares about. Thus at the very least I think we should omit the
> warning message if opt.string is set.
> 
> > > I am not going to fix it. :)
> 
> Me, I would like to.
> 
> Note that the message starts with hash marks. All other messages which
> start with a hash mark are omitted in quiet mode [1]. Thus for
> consistency I believe it would make sense to also omit that one in quiet
> mode. In other words, I would apply Jens's patch.
> 
> If we really can't agree on that, then let's please at least omit it in
> string mode, to make scripter's lives easier.
> 
> As a side note: developers and admins should know that most useful DMI
> strings are available under Linux from sysfs for a long time now, with
> most strings being even available to non-root users. This might be a
> more efficient (albeit arguably less portable) way to get the
> information you need.
> 
> [1] With one exception in legacy_decode, which is clearly an overlook as
> it diverges from smbios_decode, so I'll fix it right now.
>

It seems, you've just convinced me. ACK. :)

> And I forgot to mention:
> > See the commit:
> > http://cvs.savannah.gnu.org/viewvc/dmidecode/man/dmidecode.8?root=dmidecode&r1=1.24&r2=1.25
> > 
> > I've added it a while back to address exactly this situation.  
> 
> Documenting is always good, no matter where the warning message goes or
> in which conditions it is printed. Thanks for doing that :-)
>

np.

Anton.