Should openSeaChest be a single binary?

[vonericsen]

Today we have the tools broken out as separate binaries:

• openSeaChest_Basics
• openSeaChest_SMART
• openSeaChest_Erase
• openSeaChest_Format
• openSeaChest_ZBD
• openSeaChest_Firmware
• openSeaChest_Info
• openSeaChest_Configure
• openSeaChest_GenericTests
• openSeaChest_Logs
• openSeaChest_NVMe
• etc

This can be changed to a single binary while maintaining all the current openSeaChest features.
There would be one tool: openSeaChest that takes a sub-tool name like this:

1. openSeaChest smart -d <handle> --smartAttributes hybrid
2. openSeaChest info -d <handle> -i
3. openSeaChest scan -F <scanflags>
4. openSeaChest erase -d <handle> --performQuickestErase
5. openSeaChest configure -d all --writeCache disable
6. openSeaChest format -d <handle> --nvmFormat current --nvmFmtSecErase user
7. openSeaChest nvme ...
8. openSeaChest zbd ...
9. openSeaCHest logs -d all --farm
10. etc

Basically, instead of a separate binary for each tool, the first argument to openSeaChest will select which subtool to use for an option you want to run. All the options present in the tools today would continue to be supported under the sub-tool name, similar to today's use.

This change would be significant which is why we would like some feedback before we pursue this further. There is not currently a timeline on this change or even a requirement to make this change, but it would be great to have some community feedback on this idea.

Possible pros:

• Single binary may be easier to use between commands/operations you are running
• Possibly reduce size of package with a single tool versus multiple that link in the same things
• Reduce option redundancy between the tools (all tools have scan, device info, etc)

Possible cons:

• Scripts for openSeaChest would need to be changed to support the new syntax
• You prefer the multiple binaries approach to supported options
• Separate binaries focused on doing tasks well is a better approach than an "all in one" approach.

Please feel free to add comments to elaborate on other pros/cons or opinions on this. I will try to edit the pros/cons list above as these are added. This is purely an idea and question on what is preferred by users. Even if this poll shows favor towards a single binary, there is no guarantee it will be implemented.
I'm trying to weigh user feedback as I consider how to reorganize the utility code. The idea I currently have should work for single or multiple binaries without a problem.

[ThunderEX]

Sometimes I do have some little problems like:

• openSeaChest_Erase and openSeaChest_Format provide similar features and look confusing when choosing which one to use,
• To me, --spindown is frequently used but not exist in all individual tools, so I often need to include openSeaChest_Basics together with other tools so that I could have --spinDown.

But for a single binary, why do we need the first argument for subtool? Could we directly have parameters for each feature as we just have for seperate tools? Otherwise, it may still confusing to choose between openSeaChest erase or openSeaChest format.

[rudock1]

Hi guys,
Regression testing might be different for the open source tools, but the closed source SeaChest tools need very thorough pre-release testing. If a quick fix or new command is necessary then the pre-release testing is isolated to the feature set of that particular tool, only. There may be top-tier open source users who do their own pre-release testing on just the tools they need. A unified tool needs a different testing strategy. My two cents ;-)

[gszy]

Please consider using only lowercase letters in the binary name (openseachest). While it isn’t in any way mandatory, most Unix utilities are named in lowercase, so we (Unix users) are more familiar with such names (and they’re a little easier to type).

Regarding the poll, I don’t have enough practical experience with the openSeaChest tools to be able to vote. If all the tools share a significant number of options and operate in a similar way, then I’d say “yes”.

[VenomSkyy]

Thanks for your feedback. As far as naming the tool, you are correct, we should have named it all lowercase. Unfortunately, we first did it with mixed case and I think we would disrupt a lot of users who automate the tools. We will bring it up for discussion at our team roundtable to see what can be done - a lot of us use auto-completion, and I get that under some distros this is not readily available.