Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs

Dashboard
Notifications
Mark all as read
Q&A

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

+8
−0

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 does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

General comments (1 comment)

3 answers

+8
−0

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)

Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

General comments (5 comments)
+2
−0

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).

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

+1
−0

@‭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.

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »