openSeaChest_SMART --smartCheck prints nothing with verbose 0 about openseachest

[ThunderEX]

Hi @vonericsen

Yes, what I need is exact "banner-less" level. Without banner, it would be much more easier for bash script to parse output. (especially --scan and --smartAttributes, they are quite nice organized table)

Either -v ? or refactoring -v 2 makes the sense. And it could also be some suffix to original verbose level like -v 1? meaning suppress banner from level 1, or even a completely seperate parameter.

Anyway, it would be of great help if there is some method to make it "banner-less" no matter which way to pass in parameter.
Thanks!

[pranali-tirkhunde]

Hi @ThunderEX,

The requested feature has been implemented and checked in into develop branch. Can you please check this?

Feel free to reopen the issue if anything more needs to be added here.

[vonericsen]

Hi @ThunderEX,

-v 0 and -q are equivalent and were originally meant to show absolutely nothing on the screen, even test results like this so that only the exit code would be used. This was from a customer request we had on SeaChest tools a long time ago.
I'm not sure how often this quiet mode is used still, but can check into how often it is used at this point. If I remember correctly, it was for certain OEM sites that needed tools but did not want much on the screen in their automated testing because they were handling their own pass/fail messaging and did not want to confuse the SeaChest output with their own.

We've also had a request internally to create a "banner-less" verbosity level, which would work more like you are asking and would output more like this:

D:\dev\SeaChest>builddir\openSeaChest_SMART.exe -d PD1 --smartCheck -v ?
\\.\PhysicalDrive1 - ST2000DM008-2FR102 - WFL1XYAL - 0001 - ATA
SMART Check
SMART Check Passed!

If this is something you think would be useful, we can work on creating it.

If you have other ideas on verbose output, I would be happy to consider it as well.
When we created it originally, we were looking for a way to create a software bus-trace so that we could understand what commands were issued and what the device's response was since that is usually the most helpful thing for our team when working with firmware teams to debug issues. It also made it easier for us to get reports from different Seagate teams about issues with certain commands and we still often use the -v3 and -v4 levels when debugging very specific drive problems today. We use bus-analyzers a lot less today because of the output we have is good enough to capture most, if not all, of what we need. They usually only come out when things get really weird and unexplainable through the software trace.
-v2 isn't really used much by anyone I know, so it would be a good candidate to rework into something else that might be a step up from the default level of output without being a full command-level trace.