I can't think of any other examples, and I certainly can't speak for
other users--it's just been my preference ever since my first intro to
Unix. And it's not just termlib programs, I have a built-in dislike
for any programs that exhibit the initial no-arg behavior of just
sitting there silently awaiting further input with no clue, e.g., awk
and Perl (fortunately I know and love Perl and know how to get help
for both it and awk).
Interesting discussion. I think it's worthwhile to distinguish between the graphical applications (like mged, firefox, openoffice, etc) and traditional command-line commands (rt, ls, cat) that are meant to be interacted with via a shell. Their usability patterns are quite different and I think the expectations are dramatically different. However, really the concern raised is one of usability, right?
I agree that having a problem sitting their waiting on input sucks from a usability perspective. The user has no feedback to go on for gauging whether the command is just busy doing something or is waiting on something from the user. Moreover, that default use doesn't provide usage. Feedback is key.
For GUI apps, I think this concern is easily resolved by having the command either 1) detach immediately (think of the GUI as a big usage statement) or 2) print a message (Launching GUI, press <ctrl>-c to abort). Merits to both as both provide instant feedback.
For command-line apps, there's an entire category of tools that are streaming processors (cat is a perfect example) whose usability would be only reduced by forcing an option. However, we have very few of these in BRL-CAD. Our proc-db tools are good examples of tools that should probably not just dump out a .g file by default or, at least, they should tell the user they did that. Most tools are like 'tar' and already require some option(s) to perform stream processing and will even spit an error if isatty() is true on stdin/stdout.
At this point, I don't think we have a good grasp of our command-line patterns currently employed to know which commands would need to be changed if a convention were adopted. Carl's been working on a spreadsheet I'd started years ago to characterize this information for command-line commands, but I think the complexity he's uncovered just further demonstrates a need to hit up the lower-hanging issues like consistent help, man pages, and usage statements.
Ironically, I think MGED's commands do beg for exactly the convention you're suggesting. Commands like edcolor that kick off an editor are easily exceptions to the norm and don't offer the user a chance to discover their interface intentionally. The regress/mged.sh script demonstrates how those few commands cause problems for automatic testing. The regress test ensures that all mged commands listed in help actually run (and ideally produce a usage statement if you just run that command with no arguments). Perhaps a good place to start is there.
So, knowing I can get man help even without no-arg help is good enough
for my whines!
That's also why I'd like to make it so that literally ALL commands will respond to '-?' and '-h', so we can at least have a convention that results in informative help that is consistent across every single command (in addition to a man page, which we hopefully provide).
Cheers!
Sean
------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
