Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

how to make a good interface?

by diamantis (Beadle)
on Mar 14, 2008 at 17:25 UTC ( #674256=perlquestion: print w/replies, xml ) Need Help??

diamantis has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

I have a perl application that I run from command line passing a variety of arguments (they are handled by Getopt::Long). Because the number of options have increased I would like to change it a bit but I do not know what would be the best. I was thinking of running the program and having a kind of terminal where the user could type various commands (something like the R or gnuplot)

I thought that I could just print a prompt and wait for input from STDIN, but I was wondering if there is any way to incorporate more user-friendly functions (charater completion, history etc).

Thank you very much

Replies are listed 'Best First'.
Re: how to make a good interface?
by jeroenes (Priest) on Mar 14, 2008 at 17:55 UTC
    I recently dove into Term::ReadLine::Gnu and found it a versatile approach. After installing the module you can find some example programs. I managed to fire up an interface by tweaking the fileman example just within a couple of hours. The interface included tab completion, history browsing, help function and all while integrating a series of scripts.

    Next thing on my shopping list is working with POE for more flexibility.


    "We are not alone"(FZ)
Re: how to make a good interface?
by Fletch (Bishop) on Mar 14, 2008 at 17:29 UTC

    Term::Readline does this. Look a the CPAN module for inspiration.

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

Re: how to make a good interface?
by skx (Parson) on Mar 15, 2008 at 00:21 UTC

    The Term::Shell module sounds ideal for you; it does all the hard word of reading input, dispatching it to your routine(s) and has support for command completion too!

    I didn't quite use it in my asql project, instead my code uses a dispatch table and has a few differences - but had I known about Term::Shell in advance I'd probably have used it instead!

Re: how to make a good interface?
by swampyankee (Parson) on Mar 15, 2008 at 17:30 UTC

    I must applaud the attention you're paying to usability. I tend to find the question/answer type of interfaces to be annoying (especially since the parameter I most need to change is generally the last one prompted). Whatever interface that you decide upon, I would suggest that you run it by the people who are going to be using it.


    Information about American English usage here and here. Floating point issues? Please read thisbefore posting.

Re: how to make a good interface?
by toma (Vicar) on Mar 17, 2008 at 06:29 UTC
    When I do this sort of thing I turn my program into a CGI and the UI becomes a web page. Then the user can use the 'back' button to change the parameters. If there is no web server handy you can use one of the perl modules that supplies one (such as HTTP::Daemon).

    I like a good terminal interface, but most of the users that I deal with prefer the web approach. Handling program state properly can be tricky (you can use something like CGI::Application to help with this), but if all you need is some parameters for your program, it should be easy.

    It should work perfectly the first time! - toma
Re: how to make a good interface?
by weismat (Friar) on Mar 16, 2008 at 10:15 UTC
    From my pov I would consider using a configuration file instead of command line arguments. The config file would be then the only argument.
    It is especially useful if you have some typical argument combinations.
Re: how to make a good interface?
by repellent (Priest) on Mar 20, 2008 at 01:08 UTC
    Do not captivate the User Interface. Follow Unix_philosophy

    The "user-friendly" functions you mentioned are not friendly at all to power-users -- you're just reinventing the shell :) For instance, some users may not like you to decide how command completion is done for them. Instead, think of how a user's existing shell can work for your program.

    If you're writing the program for Grandma(TM), first, make sure your program works well in batch-mode. Then, write a GUI front-end that calls your original program. It's more modular this way, maximizes reuse of your core program, and eases future extensions.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://674256]
Approved by Joost
Front-paged by citromatik
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2022-05-27 16:38 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (97 votes). Check out past polls.