From: Keith.S.Thompson+u@gmail.com   
      
   Michael Sanders  writes:   
   > On Fri, 7 Nov 2025 21:25:52 +0000, Richard Heathfield wrote:   
   >> I'm pretty sure I've read every article in this thread, but I   
   >> still have no idea what tinybase actually does. Is it an analyser   
   >> for alkaline chemical structures, or a nucleobase designer, or a   
   >> microRDBMS, or what?   
   >>   
   >> tinybase really ought to tell you that, in just a sentence or two.   
   >   
   > Yup you're absolutely right. Here's my latest. Getting close...   
   >   
   > Usage: tinybase [ -q queries... | -t | -r | -m ] [ files... ]   
   >   
   > Synopsis: Tag based search tool   
   >   
   > Options:   
   >   
   >   -q  query mode: find blocks with matching tags or wildcards   
   >       example: tinybase -q 'query1, query2' files   
   >   
   >   -t  tag index mode: list all unique tags across given files   
   >       example: tinybase -t files   
   >   
   >   -r  repl mode: interactive shell for tag queries   
   >       example: tinybase -r files   
   >   
   >   -m  manual mode: show built-in documentation   
      
   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.   
      
   --   
   Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com   
   void Void(void) { Void(); } /* The recursive call of the void */   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)