Command-line interface is one of the oldest, yet commonly used human-computer interface, where users type textual commands with arguments to get desired results. Developers often provide command-line options for software applications along with graphical user interface. Several programming languages provide standard libraries to help programmers parse and handle command-line arguments. However, both CLI and libraries have evolved all these years, standardizing the way how commands are built and adding along with new functionalities like the use of colors, auto-completion, auto-correction etc. Yet there is a lot of scope for improvement, notably for creating a multilingual interface, obtaining the progress of a command, furthering the use of colors etc.

Introduction

Considering the recent advances in human-computer interfaces with graphical user interfaces, availability of new devices like mouse, joystick, support for voice commands, recent arrival of new technologies to understand motion gestures, it is easier to say that the command line interface (CLI)1 has lost its relevance and charm. CLI can be considered as one of the oldest human-computer interface, where you type in some textual commands and the computer responds with a result. But it is still commonly used by developers and adminstrators even though many commands have their equivalent graphical interface counterpart. CLI is not here to go7. Modern Programming languages continue to provide libraries to standardize command creation and help developers parse command line arguments.

A look at Unix/Linux command line tools, we notice that most of these commands are abbreviations of their longer forms associated to a key functionality. The word chosen for the functionality usually comes from English. Take for example, Unix/Linux command ls is an abbreviation of list and its main function is to list files in a given directory. Commands may take arguments and they may have an associated shorter and longer version.

ls -s

or

ls --size

lists the contents of a directory with additional information: file size. Shorter version of an argument (in general) starts with one hyphen (-) and the associated longer version with two hyphens (--). Once again, in most cases, the arguments usually comes from English for the corresponding functionality.

Command-line or terminal commands, hereafter referred to as simply commands require to be memorized and if you are a regular CLI user, it may not be difficult. The learning curve for a novice is however hard, especially the users from non-English background. However, there are manuals and can even be accessed from the command line like $ man or $ info . Nevertheless, CLI requires memorization of commands and their arguments. Even then, this initial curve does not stop new users and many recent programming and development tools have command line options.

Is CLI still relevant in this age of voice commands and motion gestures? It depends to whom you are asking the question? However the question still remains: can command line be made friendlier to a new user, irrespective of their daily (human) language of use? Can it be made more humane4 and natural language friendly? Do we really need to remember all those commands and their arguments? For many years, we see the trend towards making CLI human-friendly; auto-completion and auto-corrections have made their entry to several shells. Search engines have raised the bar for textual-based applications. $ man -k 'search term' may suggest several commands related to the search term. It still requires a lot of human effort to find the right set of commands and related arguments for a given task. Therefore, CLI still needs a lot of enhancements. In the debate between GUI icons and commands4, it is said that an image can speak thousand words, but it cannot easily replace the word (or command).

Understanding Command Line Arguments

Those familiar with C programming language may have heard about getopt(), a library function for parsing command line arguments with several variants like getopt_long(). Programming languages like Python3 have functions with the similar name. A command may take several options like -s or --size seen above. Every option has a longer or shorter version and the shorter version is usually the first character of the longer version. Shorter version of an option start with -, where as its longer version starts with --. An option may or may not take additional argument and may suppose some default value, provided by the developer if none is passed.

However, newer methods like Python's argparse()2 have further enhanced handling of command line arguments like an option may take one or more arguments, ability to specify the expected data type of arguments (e.g. float, integer etc.), easier handling of help messages (e.g., ls --help for different options. Another interesting feature is the support for subcommands like git10 has several subcommands push, pull, commit etc, each having its own set of options sharing the same names (both longer and shorter versions). argparse() has also added the possibility to group arguments (by default, optional and positional arguments are separated) and to permit only one of the options from a group. Groups permit to view the available options separated by their key functionality instead of viewing all available options in an alphabetical order.

Such functions tend to uniformize the way command line arguments can be handled. The use of such library functions is useful to both users and application developers. Nevertheless, command lines can still be further enhanced.

Enhancing Command Line

An important question is how to further reduce the learning curve of new users to command line, i.e., a way to go beyond the need to memorize commands and their various options. But textual interface is not just confined to command line. Several desktop applications and web services have textual interfaces. Search engines do not expect a lot of expertise from the end users; users type their search query to find desired information. Last several years have seen the growing trend towards graphical user interface and some works have shown how command-line driven systems can be transformed to web applications5, binary components6, GUI 7. Likewise, the inverse is possible and advances in GUI tools can serve as an inspiration to enhancing command line. Whether we need further standardization or the use of more natural language is left as an open question.

Though some shells15 provide suggestions when users make mistakes in typing commands and also let them search some recently typed commands, this user experience is indeed incomparable to personalized user-experiences on web services which follows data-driven or usage-driven approach. It is sad to note that shells make limited use of user command history to recommend commands to users or provide a personalized command-line experience.

Some commands like MySQL13, MariaDB12 have their own internal REPL (Read–eval–print loop)14 that permit them to provide another language (e.g. SQL) for user interaction. Usually such languages are declarative and tend to be natural-language (usually English) friendly. This approach permits the developers of command-line tools to go beyond using standard command-line parsers and flexibly create user-friendly command line options. Some of these REPL tools are multi-user and multi-profile. Therefore it is also possible to make use of REPL user command history to personalize user experience for the purpose of autocompletion, argument recommendations (suggestions) etc. similar to the features seen in search engines. Nevertheless, popularity of such declarative languages has given birth to new set of administration tools like osquery11 that reuse the syntax of SQL to query about system resources. Thus osquery lets the user perform system usage analytics considering processes, users, memory as relational tables instead of memorizing commands like ps, top etc.

Integrating search and filter options, commands with no fixed word order, use of synonyms, support for natural language phrases (today, two weeks from today etc.)7 is crucial for next-generation command-line experience. Some years ago, Ubiquity8, an experimental project by Mozilla demonstrated a textual interface to preview and execute various user actions. It demonstrated how users can type action verbs like translate, email along with arguments. Users need not memorize the action verbs, since synonyms can also be used. The action verbs were configured to associated services and the users have the option to preview before actually executing the action. Another interesting feature was the support for multilinguality9. This support for internationalization by supporting action verbs in other human languages helps non-English-speaking users to access various web services in very much the same way that an English speaking user does. The action verb need not be in the beginning, e.g. email "emailid" "message". It could also be at the end of a sentence, depending on the language. Besides, mnemonics or abbrevations can also be used for these verbs. Language-based interface4 is as promising or is even better compared to an icon-based interface, providing many more flexible options to the end users.

fish (friendly interactive shell)16 is an oft-talked about shell for its user-experience. One notable feature is its (default) use of colors, that helps user to easily distinguish between files, directories and even error messages. Applications have changed a lot. Gone are the days when applications were run on a single machine. Current generation of tools manage multiple distributed machines for storage or parallel computing17 and are often multi-threaded. Those familiar with printing log messages from a multithreaded process are aware of the difficulty to distinguish between messages from different threads or processes (unless some distinguishing phrases are added in the beginning); a key reason being the legacy two-colored approach to handling output/error messages from the processes. Colors need to be fully integrated to CLI.

Another interesting feature will be the ability to track the progress of commands. Commands like progress, pv etc. are limited to certain commands or when data pipelines (i.e., use of |) are used. User interaction with commands (especially long-running commands) permits user to further complex tools involving one or more commands depending on the current status of commands. Furthermore, pipes can be enhanced to support multiple data pipelines (currently supported by commands like parallel17). Indeed, the use of pipes can be further used to recommend and create command mashups.

Conclusion

With the growing number of human-computer interfaces, it is easy to question the relevance of command line interface. Yet it is still commonly used by the developers as well as by administrators and several new tools have a command line interface along with the graphical user interface. Several researchers have proposed ways to enhance the command line and this article took a look at some of these propositions. Command line interface needs to be much more user friendly, providing a personalized user experience based on past history of commands, adding additional support for natural language and making use of colors.

Note: This article was first written as a proposition to an upcoming Linux distribution conference.

References

  1. Command Line Interface
  2. argparse — Parser for command-line options, arguments and sub-commands
  3. getopt — C-style parser for command line options
  4. FEATURE: The linguistic command line, Aza Raskin, Interactions - Toward a model of innovation, Volume 15 Issue 1, January + February 2008, Pages 19-22
  5. Transforming command-line driven systems to Web applications, Constantinos Phanouriou, Marc Abrams, Computer Networks and ISDN Systems, Volume 29, Issues 8–13, September 1997, Pages 1497-1505, Papers from the Sixth International World Wide Web Conference
  6. Converting command-line applications into binary components, Peter M. Maurer, Software: Practice and Experience, Volume 35, Issue 8, 10 July 2005, Pages 787–797
  7. The next UI breakthrough: command lines, Don Norman, Interactions-Business leadership and the UX manager,Volume 14 Issue 3, May + June 2007, Pages 44-45
  8. Ubiquity
  9. Ubiquity: Designing a Multilingual Natural Language Interface, Michael Yoshitaka Erlewine, SIGIR Workshop on Information Access in a Multilingual World, July 23, 2009
  10. git
  11. osquery
  12. MariaDB
  13. MySQL
  14. Read–eval–print loop
  15. Shell (computing)
  16. friendly interactive shell
  17. GNU Parallel