Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Designing command-line interfaces

antoarts.com

Post reply on HN
Print view View original

31–40 of 81 posts

Re: Designing command-line interfaces

#31

Post by shadearg »

gnufied wrote: post #25

> Silence trumps noise How about, ec2-server-start -n 4 -t medium -i img-xxxg Which expands to start 4 medium instances using image img-xxxg. Will you prefer a long wait and then silently back on prompt or an indication of something happening? I agree with what he is saying, but I think there is a hint of unfair generalization here. > Naming your utility Again small unix commands are like precious three letter domain…

> Will you prefer a long wait and then silently back on prompt or an indication of something happening?

This is what the -v, --verbose option is for. Without this flag, you should assume everything is operating as expected until you receive an error message or an exit status >0.

Re: Designing command-line interfaces

#32

Post by icebraining »

"GUIs also have the advantage when it comes to presenting and editing information that is by nature graphical. This includes photo manipulation and watching movies (I have always wanted a program that shows a movie in my terminal by converting it to ASCII art in real-time, that would be sweet)."

This is an interesting discussion - what is the CLI, exactly? My personal PDF viewer is Zathura[1], which is controlled like VIM. On the other hand, programs like Kismet run on a terminal, but have mouse controlled menus.

Personally, I feel that Zathura is a CLI application, even though it depends on X, because the interaction is done in a keyboard driven way with no graphical widgets.

[1]: http://pwmt.org/projects/zathura/

Re: Designing command-line interfaces

#33

Post by Xurinos »

The name should be short. A long name will be tedious to type, so don’t call you version control program my-awesome-version-control-program. Call it something short, such as avc (Awesome Version Control).

    $ my-aw  # yay!
Personally, I am not a big fan of everyone using two or three-letter linux names for everything. We have a lot of options now for autocompletion and seeing what is available, so long names are no longer a talking point.

Re: Designing command-line interfaces

#34

Post by a3_nm »

FaceKicker wrote: post #4

Non-interactive programs get the most attention in this article, while text-based user interfaces are barely covered at all. That's disappointing, I was hoping I'd learn how vi, etc. worked from this, since I know nothing about writing command line interfaces other than input and output to the last column of the last line of the terminal. Does anyone know of a good article/introduction to this?

Besides the technical details, there are good practices which should be followed, but I don't know of any document which lists them. This is a pity, because though text-based interfaces are often designed in a much more efficient way than GUI interfaces, they are seldom consistent between themselves, and often get something wrong. A few common ones:

- Don't make the user reach for distant keys like escape or pagedown/pageup (also support ^N/^P or ^B/^F) or the arrow keys (also support hjkl), unless you really need to.

- For one-line text entry, support readline bindings (^W, ^U, ^Y, ^B, ^F, etc.)

- If you show a list, provide a way to search for an item rather than moving through the list item by item or page by page.

- Unless there is a good reason not to, spawn $PAGER to show text and $EDITOR to edit text.

- If there is a finite set of actions to choose from, provide one-key hotkeys for each one. Don't require unnecessary use of the control key. Optionally show the list of possible or common actions, but have an option to hide it and save screen space for users who don't need it anymore (like mutt does). Likewise, if there are several items that can get focus, provide hotkeys, don't require the user to Tab their way through all of them.

Obviously, there are more.

Re: Designing command-line interfaces

#35

Post by a3_nm »

icebraining wrote: post #32

"GUIs also have the advantage when it comes to presenting and editing information that is by nature graphical. This includes photo manipulation and watching movies (I have always wanted a program that shows a movie in my terminal by converting it to ASCII art in real-time, that would be sweet)." This is an interesting discussion - what is the CLI, exactly? My personal PDF viewer is Zathura[1], which is controlled lik…

True. I often use text-based applications because I can usually expect them to have a sensible and efficient interface which does not require the mouse. There are graphical applications which follow the same spirit, but they are pretty well hidden.

Re: Designing command-line interfaces

#36

Post by scott_s »

huhtenberg wrote: post #17
scott_s wrote: post #11

Earlier quoted context omitted.

And if you use C++ and are willing to use Boost, program_options: http://www.boost.org/doc/libs/1_47_0/doc/html/program_option... I recognize that many people are not willing to use C++, and among those that are, many are still unwilling to use Boost, but I find the program_options library to be great. An example use that I think is reasonable and a big win over doing it myself: https://github.com/scotts/cellgen/blob…

> many are still* unwilling to use Boost* I can appreciate the subtlety of wording, but in reality it is more of > many will never be touching Boost even with a long pole and for a large sum of money :)

Yeah, I was thinking of the people who are violently opposed to it. And, man, I have to admit I really don't get that attitude. There are some well-designed libraries in there, and you can pick-and-choose which libraries you want to use.

I respect people's decision, I guess I just don't understand it.

Re: Designing command-line interfaces

#37

Post by reinhardt »

mcantor wrote: post #3

Here's another one: Provide explicit flags for default behavior . For example, if your lines-of-code counting utility excludes preprocessor directives by default, and includes them when you pass "-i", provide an "-x" switch that signals to use the default behavior. This way, when someone wants to write a bash script that uses your utility, they can do this: case $include_directives in y) LOC_FLAGS='-i';; n) LOC_FLAGS…

What about the disadvantages?

- It doubles the number of flags of the program.

- It allows invalid or ambiguous combinations: is `myloc -i -x` valid? If yes which flag takes precedence?

It seems these must outweigh the benefits or it wouldn't be so uncommon.

Re: Designing command-line interfaces

#38

Post by scott_s »

Xurinos wrote: post #33

The name should be short. A long name will be tedious to type, so don’t call you version control program my-awesome-version-control-program. Call it something short, such as avc (Awesome Version Control). $ my-aw # yay! Personally, I am not a big fan of everyone using two or three-letter linux names for everything. We have a lot of options now for autocompletion and seeing what is available, so long names are no long…

  $ may-aw
  my-awe-inspiring-tool my-awwwww-how-cute-program  my-awesome-version-control-prog
  my-aww-yeah-tool      my-awchoo-i-sneezed-program my-aw-long-your-names-are-grandma
Also, please don't make me hit the - character when I call your program.

Re: Designing command-line interfaces

#40

Post by rch »

salem wrote: post #27

One cool feature of the juniper junos CLI is that all the CLI commands have an option for XML output, making parsing of the CLI output in scripts a little more sane.

I've started adding an option to output a complete Galaxy tool config file for some CLI apps.

-- http://wiki.g2.bx.psu.edu/Admin/Tools/Tool%20Config%20Syntax

Post reply on HN