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
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

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

Parent

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

+12
−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?

History
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)
Post
+1
−0

I largely agree with existing answers, but wanted to add this:

In many cases, there is no clear answer one way or the other. Take the program wc which counts characters and lines. Should the interface be wc file.txt or cat file.txt | wc? Compelling arguments can be made for the value of either. Yet we have to pick one.

Actually we don't. wc supports both. More complex programs support the well known - parameter, so cat file.txt | some_program --file - as a way of making it a bit more coherent.

Interactive input falls under this as well. ssh-keygen will interactively ask for the key type. But with ssh-keygen -t ed25519 it will not ask.

CLI arguments, standard input (from pipe) and interactive input form the three pillars of Unix-style human-computer interaction. All programs should aspire to provide first-class support for all three eventually, even if they won't, just like "all kids" aspire to be astronauts. Imagine a stool with two legs. You can make it work, and it's certainly better than a stool with one leg, and way better than none, but once you get to three legs it gets really good.

Of course you have to start somewhere. For your first leg, just pick one. Whatever you feel is a likely use case for your script, and let users rely on Unix to "improvise" the missing legs:

  • cat if they want to use args but you support stdin
  • Shell redirection if they want stdin but you want args
  • expect if you support interactive but they want scriptable

As your program matures, you can use the experience gained from maintaining it to decide which next method of input you should add support for.

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

1 comment thread

Useless use of `cat` (1 comment)
Useless use of `cat`
__blackjack__‭ wrote 10 months ago

Useless use of cat. It shouldn't be cat file.txt | wc but < file.txt wc (or wc < file.txt). :-)

I don't think just picking any one of the three for a start is a good idea. It is harder to script something with expect than to provide command line options. And it is harder to route some output into a program that wants filenames and doesn't read from stdin. There are shells that make this quite easy, but I would not assume the users shell, or their knowledge about such things. And of course the user might want to use another language than shell scripts to call/automate.