in reply to A thought about usability in Perl and Linux in general.

Thanks for pointing out the fact that pipes might be involved, I hadn't thought of that. So I guess I didn't give the greatest example, but I still think there are many programs that would benefit from this approach. It just annoys me when I have to prepare to run a program by going over the help message and slowly building the command to run.
  • Comment on Re: A thought about usability in Perl and Linux in general.

Replies are listed 'Best First'.
Re^2: A thought about usability in Perl and Linux in general.
by graff (Chancellor) on May 19, 2005 at 02:11 UTC
    It just annoys me when I have to prepare to run a program by going over the help message and slowly building the command to run.
    This is just a matter of habituation (and maybe what sort of command-line shell you use). In your typical modern unix shell (bash, ksh, zsh and so on), hundreds of previously executed commands are kept in a command-history list; this list is kept in a file when you exit / log off / shut down, so that you can recall commands from yesterday or last Friday or after three reboots; there are simple, fast keystrokes for searching backwards in the history for each command containing a given string, and for editing command lines for re-execution; there are shortcut "placeholders" for using an argument from a previous command in your next command, and lots more features.

    Then there's the common X-Windows environment, with 3-button mouse for quick and easy copy/paste within and across windows, and the "xterm" window for running a shell, with its ability to scroll back over hundreds of lines of prior shell i/o. Put all these together, and building command lines of arbitrary length/complexity is pretty quick work -- helluva lot faster than answering a series of questions that each ask for just ... one ... single ... parameter ... (and can only be answered manually).

    In contrast, the typical "MS-DOS Prompt" shell is pretty painful to use on a repetitive or continuous basis, and there are several versions that are annoyingly different in the amount of command history/editing support they provide. The standard window used to run the shell is no help, with limited width/height/scroll-back and klunky mouse support (if any). Overall, using this sort of shell requires a lot more re-typing, and trying to use copy/paste operations involves lots of extra steps and higher risk of mistakes and wrist injury.

    And if you're running a program that actually asks questions (one ... parameter ... at ... a ... time ...), God help you if you get to the fourth question and notice a mistake you made in answering the second one. (Start over, from the top -- retype everything -- repeat till your typing is perfect!)

    Much better, I think, if the program will just say something to the effect of "Your last attempt at a command line was insufficient or incorrect; a proper command line should look like this: .... Please try again." Whenever possible, "option" args (e.g. "-v", "-log", etc) should be optional (meaning the program will do something sensible without them); it's okay to demand that there must be an arg for this or that purpose (input file, output file, or whatever), and if such args are missing, die and tell the user what's needed.

    When a command dies for lack of proper usage, the good command-line user just hits the "up-arrow" key to recall the previous command, add or fix the arg(s) as needed, and hit "enter" to try again. Repeat until it comes out right -- but from one repetition to the next, you should never have to type the whole damn thing over again.