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

Hi Revered Monks,

I have a questions regarding the argument passing to a perl program. Is there any better way than the below to pass values to a prgram

  • Using Getopt::Long or short
  • Using interactive mode to get values

  • The problem i have here is, i have to get atleast 10 parameter from the user when they run by program, so i have to write a best way, so that they never get frustrated, if they even mistype one value.

    Your suggestions are appreciated much here....

    -Prasanna.K
    • Comment on Question regarding the arguments passing to a program

    Replies are listed 'Best First'.
    Re: Question regarding the arguments passing to a program
    by Old_Gray_Bear (Bishop) on Mar 29, 2007 at 15:58 UTC
      Seriously think about a configuration file. The User can edit to their heart's content, until it's 'right', before they have to enter "atleast ten values" (!!) and make no typos. Since there are so many values, the User will probably have already written them down somewhere; give them a place to write that you can read. Then add an option that shows the input parms that were read and let the User change individual values.

      A better approach will be to rethink your interface. *Why* are you requiring so many values? What can be simplified? If you make it hard for your User, They won't use your code.

      ----
      I Go Back to Sleep, Now.

      OGB

    Re: Question regarding the arguments passing to a program
    by robot_tourist (Hermit) on Mar 29, 2007 at 15:54 UTC

      Try giving all options, including using a settings file and possibly even a GUI, like TK. A GUI might be best if the user has to run the process several times, but only a couple of things change, so that you can use spin controls and list boxes, etc.

      How can you feel when you're made of steel? I am made of steel. I am the Robot Tourist.
      Robot Tourist, by Ten Benson

    Re: Question regarding the arguments passing to a program
    by MonkE (Hermit) on Mar 29, 2007 at 16:14 UTC

      You shouldn't be asking us what your users want. Ask them. However since it is sometimes the case that users don't really know what they want, you may need to show them a few examples of what is possible.

      Ten parameters is a bit much for a command-line. Try to shift some of the settings to a configuration file. You could also have the user put these 10 values in a file in a specific format. Then all they would need to do is specify the filename on the command line. You might even be able to implement drag and drop: they drop the file onto your script. Either way you just read the file with <>

    Re: Question regarding the arguments passing to a program
    by sailortailorson (Scribe) on Mar 29, 2007 at 21:46 UTC
      I think the short answer is that if you use interactive mode, the user will be occupied during the setup time. It's kind of like the mirror that some fast food restaurants put up near the counter to keep customers busy. If you loop through some data validation before continuing to the next bit of input, then user will have the sense that someone or something is holding his/her hand through the whole process. Your script will seem less frustrating to your customer.

      Going further though, I really like Getopt::Long, and a clean non-blocking interface. With some params, you can have a non-blocking script that can be run, say from a batch or shell file. And if you use the script too, as an expert user then want to just throw down some parameter/value pairs, and get the script working post haste, you can do it.

      You can actually implement both styles. You could make a bare invocation of the script go into interactive mode, and the inclusion of any parameters starting with - or -- be handled by GetOpt::Long/Short, or even fall back to interactive mode with any required params that are missing or incorrect.

      Using environment variables for some of the parameters is not a bad idea either. Typically, these should be things that could change, but usually don't.

      I say start with interactive, then perhaps add GetOpt::Long to provide an alternate interface that suits your own style.