Mark all as read

For scripting what are the pros and cons of command line arguments versus capturing input at the start?


Let's say I have a script that needs the user to set X number of variables at the start. One can either

  • Pass the arguments in on the command line.
  • Start the program and then have the user input the variables with Python's input() function or PHP's fopen("php://stdin", "r") for example.

What would the pros and cons be and when would I decide to use one method versus the other?

Why should this post be closed?

1 comment

Or, if there are a lot or they're tightly coupled or they need to be reproducible, you can put them in a config file and pass the name of that file as an arg. Monica Cellio‭ 29 days ago

3 answers


Pros of CLI arguments/flags include:

  • Easier to leverage the tool in another script or via other automation so that user interaction is not required

  • If certain arguments are optional and/or have default values, the user is not burdened with these choices when they are unimportant

  • Once someone has used the tool a few times, it is often faster for them to memorize their preferred parameters or save/alias them than to have to manually input them each time

Cons may include:

  • If the targeted users are not comfortable using a CLI, they may struggle to use the application. Receiving parameters via interactive input may be more user-friendly (especially if interactive error handling/validation is employed to give the user immediate feedback and assistance with invalid options)

  • If the parameters are complex and certain options have conditional relationships upon others, gathering this information at runtime may be more user-friendly

Other considerations:

  • Consider accepting either CLI parameters or gathering parameters at runtime if no arguments are provided

  • Consider a configuration file if options will rarely change or are private, such as passwords/keys

  • If the script operates on a file, also consider receiving input via stdin along with various parameters, which enables data to be piped to the application from multiple sources (i.e., not just from a file, or from a file after being filtered through another tool)


One point that seems to be missing: Command line parameters have a platformdependent limit on their length. You can nearly read unlimited input. This becomes very important when you need to handle many files and cannot rely on xarg or need to work in one run. Someone‭ 30 days ago

The user doesn't need to worry about escaping quotes, and using quotes for arguments containing spaces with capturing input dustytrash‭ 30 days ago

"If certain arguments are optional" - This is fairly easy to solve in both approaches. I don't think it counts as a difference between these two concepts. klutt‭ 27 days ago

@klutt true, depending on style of collecting params via stdin, usually clicking "Enter" is sufficient to accept default values. However, they could be ignored altogether in CLI params and just sensible defaults used (but I see your point that this could also be the case at runtime also if an alternative method of gathering params via stdin were used). The question is rather vague (no specific program info/objectives), so my answer is necessarily also so. laserkittens‭ 27 days ago

"If the targeted users are not comfortable using a CLI" -- another thing to keep in mind that affects both methods, there's a good bit of ambiguity in the exact format needed for the arguments when they are typed in manually instead of, e.g., provided through a UI. E.g., does the program accept "parameter" or parameter? parameter=value? --parameter value? --parameter=value? --parameter="value"? I've seen a ton of variations on that, you have to document this sort of thing carefully. jrh‭ 27 days ago


I'd like to move the frame out a little and use that as a discussion for how to make these decisions.

Input models

You've listed two input models, but I think we need to add a third before we begin. I'm going to call them

  1. Command line arguments
  2. Interactive read at run-time
  3. Non-interactive read at run-time (either from standard in or from a file)

The interactive form of reading at run-time involves your program printing prompts and expecting answers that may change what prompts are coming, and seems to be your second. The non-interactive version may involve parsing some input language but does not involving prompting.

Multiple kinds of input

It is common for a program or script to manage two kinds of input:

  1. Some data that is to be processed
  2. Instructions about how to process the data or what output to produce

which means that we may want to use more than one class on input in a single tool.

Unix model

I'm going to discuss how to make the decisions under the assumption that we're talking about a Unixish model of how tools (whether built-in, written in some compiled language, or scripted) work together. In other words we're assuming that your input may come from another program and your output may go to a third.

This implies that the data to be processed should be accessible through non-interactive reads because getting two programs to synchronize a ask-answer sequence is a pain.

You may also want to provide a way to specify the data on the command line or even an interactive front-end but those are optional flourishes: non-interactive reading is the core approach for the data you are processing.

Control of how the data should be processed and output produced should be distinct from the main data. This is a prime use-case for command-line arguments. You might also get it from a non-interactive read but if so it comes from different source than the data (perhaps data on standard in and switches in a a config file). Interactive management of the switches is fine, but should be optional because we still want to be able to use the tool in a chain of computations (which means without user intervention).



@‭laserkittens‭ and @dmckee has already provided good answers, and I will not copy what's there.

Personally, I treat cli arguments as the default choice because of the flexibility it gives to scripting. Only choose user input when it's obvious that it's necessary.

A good case where you would like to have a combination is a program where unexpected things may happen during execution that requires user input. Like this:

$ rm file.txt
Are you sure you want to delete file.txt? (y/n)

In this case it's good to have this, but in that case also give the option to pass a parameter that adds a default option. So do it. In other cases this can be quite tricky

$ myprog file.txt
file.txt could not be accessed. Please specify another one: 

This would be very tricky to convert to parameters.


Sign up to answer this question »