> Prompt for user input. If a user doesn’t pass an argument or flag, prompt for it. (See also: Interactivity)
prompting is usually the worse choice in a command line utility. on error you lost what you've type and have to copy back and forth unless the terminal disappeared.
> Prefer flags to args
Options are designed to be... wait for it... optional. as the name suggests. If you actually require to pass at least one option to a command to get it working then it's bad designed. An option is there to change what a default is not suitable for you.
For example, tar uses -x, -c to determine what to do. We're all used to it now but that is not the way we should design a command. A correct way is more like tar/untar similarly to zip/unzip. That would make more sense.
To me, rpm is definitely the worse in terms of use of options. If I'd redesign it I'd imagine something like:
> Prompt for user input. If a user doesn’t pass an argument or flag, prompt for it. (See also: Interactivity)
prompting is usually the worse choice in a command line utility. on error you lost what you've type and have to copy back and forth unless the terminal disappeared.
> Prefer flags to args
Options are designed to be... wait for it... optional. as the name suggests. If you actually require to pass at least one option to a command to get it working then it's bad designed. An option is there to change what a default is not suitable for you.
For example, tar uses -x, -c to determine what to do. We're all used to it now but that is not the way we should design a command. A correct way is more like tar/untar similarly to zip/unzip. That would make more sense.
To me, rpm is definitely the worse in terms of use of options. If I'd redesign it I'd imagine something like:
- rpm i(nstall) [options...] packages...|files... - rpm e(rase) [options...] packages...
Having fuzzy match for the first argument makes it still convenient to use and much clearer for those who want to type it entirely.