Julio Merino

Software artist. Writer aficionado. Open source enthusiast. Runner. Father of two.
Currently: Senior Software Engineer at Google, New York City.

  • CLI design: Consider interactive prompts twice

    While it is a rare thing to find, CLI-based applications can be interactive just like any other kind of application can. If you choose to interactively query the user for details in your program or script, you should be aware of the two scenarios that can result from this choice (which, interestingly, are the same scenarios that we already saw regarding output verbosity). The first scenario is about “fast” applications: if the program is expected to complete in a short amount of time—where short is defined as an amount of time in which the user will not context-switch—it is alright to pop up interactive prompts at any point during the execution of the application.

    September 16, 2013 · Continue reading (about 4 minutes) · Comments

  • CLI design: Screen wrapping

    In a world of terminal emulators within graphical environments, there is no longer a “standard” window size. 80x24 is still the default, sure, but it’s trivial for users to resize the terminal. Why does this matter? Consider the most obvious case: the help message of your program. It is incredibly common to see carefully-formatted embedded strings into the program’s code designed to fit within a 80x24 window (which is especially true for the width of the text).

    September 12, 2013 · Continue reading (about 4 minutes) · Comments

  • Adding The Julipedia to Technorati

    Dear readers: I have registered this blog in Technorati and I am now in the process of claiming ownership. For this reason, I need to create this post with the corresponding claim token in it: YVUMJ5QS4QPC It is likely that I'll just remove this post soon afterwards. Sorry for the hassle.

    September 9, 2013 · Continue reading (about 1 minute) · Comments

  • CLI design: Handling output messages

    Your CLI-based program has to communicate with the user. The most obvious case is to display error or warning messages, but in some cases it is also to report progress status. There are a few details to be considered in this area. Quietness vs. verbosity by default You’ve probably heard the “No news is good news” principle. This is a major guideline behind the design of most standard Unix tools: when no problems arise, the tool just does what it was asked for and does not print anything on the screen.

    September 9, 2013 · Continue reading (about 4 minutes) · Comments

  • CLI design: Single-command interfaces

    In the previous post, I provided common guidelines on how to implement a subcommand-based interface. It is now the time to look into the interface of those applications that implement a single command or function, which are actually quite abundant. Without going too far, you will encounter cp, ls and sudo, all of which are just a tiny sample of tools that fit this model. General syntax The general syntax of a single-command interface is simple:

    September 5, 2013 · Continue reading (about 4 minutes) · Comments

  • CLI design: Subcommand-based interfaces

    Subcommand-based interfaces are common: the majority of the CLI tools that provide more than one operation within them expose their features in this manner. Examples of such interfaces include svn, git, ifconfig, yum, apt-get and many, many more. Designing the interface of these applications is quite straightforward once you have the concepts clear, but there are quite a few common pitfalls that you need to be aware of to prevent falling into them.

    September 2, 2013 · Continue reading (about 5 minutes) · Comments

  • CLI design: Do not reinvent option parsing

    In the previous post, we saw what good and bad use cases for flags in the interface of a command-line application are. We talked about the theory, so it is now the time to talk about the implementation details. The point I want to make in this post is simple: do not reinvent option parsing. Use the libraries provided by the platform you are targeting to implement the interface of your application: even if there is some little detail of the library that you don’t agree with, consistency with the platform is lightyears better than a custom implementation that fails to handle some corner cases and/or behaves in an unexpected manner.

    August 29, 2013 · Continue reading (about 3 minutes) · Comments

Subscribe

RSS feed

Subscription by FeedBurner

Featured posts

Archive