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.   
      
   Yes sir agreed (at least in the Unix world), in the Win world might be   
   a good idea to fail loudly... My thinking is it otherwise punishes those   
   who need help the most.   
      
   > 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.   
      
   That alone is worth the price of admission! Here's what you've got me   
   thinking about (in a BSD/Linux world)...   
      
   user inputs bad syntax:   
      
     - show context sensitive help   
     - offer just slightly more info with 'try fubar --help'   
      
   And the --help screen (in my case) itself then shows a bit more info   
   to the fuller documentation...   
      
   options:   
   [...]   
   -m  display in-built manual   
      
   Sort of like staging in my thinking: 1 leads to 2 leads to 3,   
   buy only suggested not bludgeoned in your face, subtle.   
      
   > 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.)   
      
   Yeah, all my stuff goes stderr in these cases whether fatal or not.   
      
   I'm rethinking the whole: app -x -y -z - paradigm, really I think   
   the trailing dash just confuses folks.   
      
   > 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.   
      
   Sure enough. I've seen apps sym-linked to their 'mode names' before.   
   Its good idea like '[' for test... (that one messed with me for a   
   while since requires a closing ']' for chirality [i])   
      
   Thanks Keith. Hope someone downloads your brain (other folks here too)   
   some time. Lots of really great info.   
      
   Appreciate it & lots of stupid questions/newbie stuff from me   
   still left to go I'm sure of it.   
      
   i.    
      
   --   
   :wq   
   Mike Sanders   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)