[hollerith]

The exec system call in Unix has an argument named argv which is an array of strings. Each of these strings has traditionally been called a command-line argument. Also, when the user of a Unix shell hits the return key, a string or line of text is submitted to the shell for interpretation, and that string used to be called a command line.

For those writers who insist on using the term "command line" to mean avoiding pointing devices and doing everything through a terminal-emulation application, please tell me what term I should switch to to refer to the elements of argv or to refer to a string submitted to a Unix shell. I want a term that does not through endless repetition on HN and other forums leave the reader with the impression that the terminal-emulation app (or the Linux console) is my preferred interface to my computer.

Suppose for example that TextMate or Atom on OS X or Linux is my preferred programming environment and that from my preferred programming environment, I frequently run programs like grep, dict and ping -- with the output from those programs collected by and presented to the user by a TextMate or Atom extension. grep, dict and ping adhere to certain conventions, such as flags or switches that start with a hyphen, and the convention of writing ordinary output to a file descriptor named stdout while writing notifications of abnormal conditions to stderr. What term should I use to refer to those conventions?

[gue5t]

The difference between a Command-Line Interface (argv-based) and a Textual User Interface (e.g. ncurses or fdisk-style interactive) is very important; the latter generally just means "a very bad but low-bandwidth GUI with no mouse support", but the former implies several attributes that allow for automation and programability: the course of interaction with a program (its command-line invocation) becomes an object trivially manipulable in its own right by users and programs.

We need to improve from the command-line by enabling even more expressive operations on programs invocations: programs should cooperate to enable perfect completion in a way that doesn't require writing custom completion scripts for every (shell, tool) combination, and they could describe their input and output formats to allow the shell to do "program search" in the space of command-lines. Given fairly rough user input, the shell can help guide the user to where they were trying to go with less work. Computers should be using some CPU time to actually help us figure out what we're trying to do, instead of everyone still hunting down syntax errors and reading man pages like it's the 1980's.

[random778]

When it comes to a textual user interface, have you considered Rob Pike's Acme?

http://doc.cat-v.org/plan_9/4th_edition/papers/acme/

[zeveb]

> What term should I use to refer to those conventions?

POSIX.

But note that using pure POSIX limits you because you don't get advantage of easy-to-use composability using pipes & substitution. It's a free world, of course.

[joepvd]

Good answer to an excellent question. But I do not agree.

POSIX is the whole of a lot of utilities. Most of these utilities I never use, and there is a lot of utilities not part of POSIX that I would consider part of the "command line experience" (editor, tmux, some home grown tools, a REPL or debugger, ...), ssh, ...

Sometimes I refer to shell programs, or shell environments. This adapts to all that I actually use quite flexibly. Both to the tools, and with a special attention to the glue: the POSIX, Ba-, Da-, Z sh.

Interchageably, I also happen to use TTY (pronounced as Tee Tee Why ;) ), terminal, and Console .

I am not particularly happy with any of these, and also do not have a strong preference. I would like to be more consistent in my wording, so opiniated replies are most welcome :)