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.
Post History
I'm coming down strongly in favor of command-line arguments or options over interactive I/O for a number of reasons: Providing arguments on the command line is vastly superior for programmatic...
Answer
#6: Post edited
by
tripleee
·
2023-06-23T17:07:02Z (over 1 year ago)
- I'm coming down strongly in favor of command-line arguments or options over interactive I/O for a number of reasons:
- * Providing arguments on the command line is vastly superior for programmatic invocation (for scripts calling scripts, including but not limited to the tool's own test suite, other scripts calling your script, etc).
- * This makes it easy for the command-line user, too, as they can easily recall and repeat or edit previous invocations using their shell's history mechanism, as well as features like command-line completion to avoid having to type in long and potentially complex file names by hand (or long option names, if you have them; though then your tool probably needs to also supply a small completion configuration for each shell you want to support).
* This is then also easy to wrap into another API, such as a web front end or a system system service.
- I'm coming down strongly in favor of command-line arguments or options over interactive I/O for a number of reasons:
- * Providing arguments on the command line is vastly superior for programmatic invocation (for scripts calling scripts, including but not limited to the tool's own test suite, other scripts calling your script, etc).
- * This makes it easy for the command-line user, too, as they can easily recall and repeat or edit previous invocations using their shell's history mechanism, as well as features like command-line completion to avoid having to type in long and potentially complex file names by hand (or long option names, if you have them; though then your tool probably needs to also supply a small completion configuration for each shell you want to support).
- * This is then also easy to wrap into another API, such as a web front end or a system service.
#5: Post edited
by
tripleee
·
2023-06-23T17:06:37Z (over 1 year ago)
Wording tweak
I'm coming down strongly in favor of command-line arguments or options in favor of interactive I/O for a number of reasons:- * Providing arguments on the command line is vastly superior for programmatic invocation (for scripts calling scripts, including but not limited to the tool's own test suite, other scripts calling your script, etc).
- * This makes it easy for the command-line user, too, as they can easily recall and repeat or edit previous invocations using their shell's history mechanism, as well as features like command-line completion to avoid having to type in long and potentially complex file names by hand (or long option names, if you have them; though then your tool probably needs to also supply a small completion configuration for each shell you want to support).
- * This is then also easy to wrap into another API, such as a web front end or a system system service.
- I'm coming down strongly in favor of command-line arguments or options over interactive I/O for a number of reasons:
- * Providing arguments on the command line is vastly superior for programmatic invocation (for scripts calling scripts, including but not limited to the tool's own test suite, other scripts calling your script, etc).
- * This makes it easy for the command-line user, too, as they can easily recall and repeat or edit previous invocations using their shell's history mechanism, as well as features like command-line completion to avoid having to type in long and potentially complex file names by hand (or long option names, if you have them; though then your tool probably needs to also supply a small completion configuration for each shell you want to support).
- * This is then also easy to wrap into another API, such as a web front end or a system system service.
#4: Post edited
by
tripleee
·
2023-06-23T12:15:51Z (over 1 year ago)
Bullet formatting
- I'm coming down strongly in favor of command-line arguments or options in favor of interactive I/O for a number of reasons:
- * Providing arguments on the command line is vastly superior for programmatic invocation (for scripts calling scripts, including but not limited to the tool's own test suite, other scripts calling your script, etc).
- * This makes it easy for the command-line user, too, as they can easily recall and repeat or edit previous invocations using their shell's history mechanism, as well as features like command-line completion to avoid having to type in long and potentially complex file names by hand (or long option names, if you have them; though then your tool probably needs to also supply a small completion configuration for each shell you want to support).
- * This is then also easy to wrap into another API, such as a web front end or a system system service.
- I'm coming down strongly in favor of command-line arguments or options in favor of interactive I/O for a number of reasons:
- * Providing arguments on the command line is vastly superior for programmatic invocation (for scripts calling scripts, including but not limited to the tool's own test suite, other scripts calling your script, etc).
- * This makes it easy for the command-line user, too, as they can easily recall and repeat or edit previous invocations using their shell's history mechanism, as well as features like command-line completion to avoid having to type in long and potentially complex file names by hand (or long option names, if you have them; though then your tool probably needs to also supply a small completion configuration for each shell you want to support).
- * This is then also easy to wrap into another API, such as a web front end or a system system service.
#3: Post edited
by
tripleee
·
2023-06-23T12:14:53Z (over 1 year ago)
Bullet formatting
- I'm coming down strongly in favor of command-line arguments or options in favor of interactive I/O for a number of reasons:
- Providing arguments on the command line is vastly superior for programmatic invocation (for scripts calling scripts, including but not limited to the tool's own test suite, other scripts calling your script, etc).- This makes it easy for the command-line user, too, as they can easily recall and repeat or edit previous invocations using their shell's history mechanism, as well as features like command-line completion to avoid having to type in long and potentially complex file names by hand (or long option names, if you have them; though then your tool probably needs to also supply a small completion configuration for each shell you want to support).- This is then also easy to wrap into another API, such as a web front end or a system system service.
- I'm coming down strongly in favor of command-line arguments or options in favor of interactive I/O for a number of reasons:
- * Providing arguments on the command line is vastly superior for programmatic invocation (for scripts calling scripts, including but not limited to the tool's own test suite, other scripts calling your script, etc).
- * This makes it easy for the command-line user, too, as they can easily recall and repeat or edit previous invocations using their shell's history mechanism, as well as features like command-line completion to avoid having to type in long and potentially complex file names by hand (or long option names, if you have them; though then your tool probably needs to also supply a small completion configuration for each shell you want to support).
- * This is then also easy to wrap into another API, such as a web front end or a system system service.
#2: Post edited
by
tripleee
·
2023-06-23T12:14:02Z (over 1 year ago)
Bullet formatting
- I'm coming down strongly in favor of command-line arguments or options in favor of interactive I/O for a number of reasons:
* Providing arguments on the command line is vastly superior for programmatic invocation (for scripts calling scripts, including but not limited to the tool's own test suite, other scripts calling your script, etc).* This makes it easy for the command-line user, too, as they can easily recall and repeat or edit previous invocations using their shell's history mechanism, as well as features like command-line completion to avoid having to type in long and potentially complex file names by hand (or long option names, if you have them; though then your tool probably needs to also supply a small completion configuration for each shell you want to support).* This is then also easy to wrap into another API, such as a web front end or a system system service.
- I'm coming down strongly in favor of command-line arguments or options in favor of interactive I/O for a number of reasons:
- - Providing arguments on the command line is vastly superior for programmatic invocation (for scripts calling scripts, including but not limited to the tool's own test suite, other scripts calling your script, etc).
- - This makes it easy for the command-line user, too, as they can easily recall and repeat or edit previous invocations using their shell's history mechanism, as well as features like command-line completion to avoid having to type in long and potentially complex file names by hand (or long option names, if you have them; though then your tool probably needs to also supply a small completion configuration for each shell you want to support).
- - This is then also easy to wrap into another API, such as a web front end or a system system service.
#1: Initial revision
by
tripleee
·
2023-06-23T12:11:57Z (over 1 year ago)
I'm coming down strongly in favor of command-line arguments or options in favor of interactive I/O for a number of reasons: * Providing arguments on the command line is vastly superior for programmatic invocation (for scripts calling scripts, including but not limited to the tool's own test suite, other scripts calling your script, etc). * This makes it easy for the command-line user, too, as they can easily recall and repeat or edit previous invocations using their shell's history mechanism, as well as features like command-line completion to avoid having to type in long and potentially complex file names by hand (or long option names, if you have them; though then your tool probably needs to also supply a small completion configuration for each shell you want to support). * This is then also easy to wrap into another API, such as a web front end or a system system service.