From: porkchop@invalid.foo   
      
   On Fri, 07 Nov 2025 15:24:25 -0800, Keith Thompson wrote:   
      
   > I would remove most or all of the blank lines, just to avoid using up   
   > too much of the user's screen real estate.  The longer your usage   
   > message, the more of the user's on-screen information might be lost.   
   >   
   > For a program that requires at least some command-line arguments, a very   
   > short message that points the user to a "-h" or "--help" option can be   
   > useful.  Don't show a very long usage message unless the user explicitly   
   > asks for it.  GNU coreutils rm is a decent example:   
   >   
   >     $ rm   
   >     rm: missing operand   
   >     Try 'rm --help' for more information.   
   >   
   > "rm --help" prints a 39-line message.  (I'm not going to get into   
   > whether "-h" or "--help" is better.  The latter is a GNU convention.)   
   >   
   > Unfortunately, this doesn't work for a command that can validly be run   
   > with no arguments, like cat.   
   >   
   > Print error messages to stderr, usage messages (at least if   
   > requested via some kind of help option) to stdout.  I've seem   
   > commands where "foo --help" prints more text than can fit on my   
   > screen, and "foo --help | less" shows me nothing because the output   
   > I asked for was sent to stderr.  (This is getting a bit OS-specific,   
   > but it's applicable to any Unix-like system, and your use of '-'   
   > to introduce arguments suggest that that's what you're aiming for.)   
   >   
   > Something else you might consider is how you handle the different   
   > modes.  If I understand correctly (and I'm not at all sure I do),   
   > "-q", "-t", "-r", and "-m" are distinct modes, and you have   
   > to specify exactly one.  If that's the case, you might consider   
   > making them subcommands, similar to the way "git" has "git commit",   
   > "git log", et al.   
   >   
   >     tinybase query ...   
   >     tinybase tag ...   
   >     tinybase repl ...   
   >     tinybase manual ...   
   >   
   > If you like, you can allow the subcommand name to be abbreviated.   
      
   Excellent info here Keith, many thanks. I have some thoughts on   
   these things (bias is coming from a Windows world on this end)   
   & I want to study your remarks more before I ask any questions,   
   please stay tuned...   
      
   --   
   :wq   
   Mike Sanders   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)