Ask HN: How should the CLI be designed today?

Plan9?

    $ files=*; echo "$files"; echo $files
    *
    file1.txt file2.txt file3.txt
    $ # echo $files -> echo * -> file1.txt file2.txt file3.txt

    $ files=*; echo $files
    file1.txt file2.txt file3.txt
    $ # files=(file1.txt file2.txt file3.txt)
    $ # echo $files -> echo file1.txt file2.txt file3.txt

As an aside, in terms of design and little helpers (e.g. git/virtualenv) powerline shell really made my terminal much more friendly: https://github.com/banga/powerline-shell

Idea: proper graphics for data/image/video display.

I think it's an interesting idea that a terminal editor can have text only input, but the ability to draw real high-res graphical output. e.g. a canvas to draw your matplotlib diagram in the terminal output or a more graphical version of htop (with time data graphs etc).

People say Windows' Powershell using some sort of objects rather than a text stream is good.

For me I want better control over how my shell records and stores history. I want it to record more and probably not in a flat text file. I don't want it to write commands that fail to disk but I do want them in my history so I can correct my typo and run again.

I'd like lines to be rewrapped if I change terminal dimensions. I'd like more automatic pagination (rather than forgetting to use less and nuking your scrollback). I think is an issue with mintty/putty but I'd like its command history to be printed correctly after changing the terminal width.

Pet hates: terminal bells that I didn't explicitly ask for; middle click paste; the obscure terminfo file that sometimes controls the features a program uses.

Autocomplete globally for every command and its subcommands

    - git
      - blame
      - commit
      - log
      - ...

Default support for control-f searching output

Easier inline editing of command args i.e accidentally executing the script when trying to enter a newline.

Hyperlinking is good, we should do more of that.

I have my urxvt configured to open http(s) URLs in my browser, but it would be nice if I could open URLs of arbitrary protocols via handlers. Similarly, being able to distinguish valid pathnames and open them in $EDITOR/$VISUAL (or perhaps via special file-type handlers) would be a nice.

Overall, I'm not particularly dissatisfied with the state of the command line in 2016. My experience has been that I make no more (or fewer) mistakes with command-line interfaces than I do with graphical ones, and that spending a few seconds thinking about what I actually want to do prevents me from using the wrong approach (i.e., a graphical or console program) to a problem.

If we could start with having working ctrl-c ctrl-v that would be great :). (I know Windows improved on this with 10 but Linux is still lacking)

Other than that I wouldn't mind some graphical features, such as being able to display thumbnails of images for example.

   man ascii

Do this: https://www.gnu.org/prep/standards/html_node/Command_002dLin...

And this: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...

In TCC/LE (a CMD replacement for Windows by JPSoft) there is one little feature that I miss in Powershell because I got so used to it: if you just enter the name of a folder (as if it's a command), you change dir to that folder (so no need to type the 'cd').

In Powershell you just get an error that this thing is not executable. A waste of semantic space, IMO.

Would love something that showed you how the current command was going to be parsed as an argument vector before actually submitting the command (pressing return). Would help with spacing and quoting.

My primary complaint about Unix CLI is that the commands try to do two disparate things simultaneously: outputting text for humans and generating data for consumption by other commands. In a properly designed command line ecosystem (it's far, far too late for that now), there would be good human readable output in one mode, and tools would exchange structured, already escaped data amongst themselves in another mode. Alternatively, the shell would render the output for humans, and tools would just communicate in machine format.

Consider for example executing a compression command on all jpg files in a folder and below. Currently, the syntax goes something like this:

  find . -iname "*jpg" -exec gfxcompress {} \;

Naive Unix users would have expected this to be achievable by piping, but no! In reality there is a special syntax of the find command that does this, and it's not completely clear how you would deal with file names further down the line, or how you would achieve further chaining. This syntax is also completely unique to the find command. You can't just plug in another data source and perform the same operation. In a CLI where tools are designed to be chained, it would look something like this:

  find | match :name="*jpg" |> gfxcompress :name 

In this example I used an imaginary |> operator to indicate I want something performed on every item, and I can refer to the "name" field of each directory entry directly. If I wanted to filter by time, for example, I might use the :time field instead, without any need for explicit support. If I wanted to mutate the name somewhere in the chain, I could do it. If I wanted to chain additional commands, it would be obvious how. And it would just work.

The same goes for error handling. Imagine a compiler spitting out structured error information which you could use directly in other tools without having to parse and interpret it first.

    for i in **/*.jpg; gfxcompress $i

    shopt -s globstar     # (Which you would have in your .bashrc)
    for i in **/*.jpg; do gfxcompress $i; done

    gfxcompress **/*.jpg

    for id in $(< file-containing-ids ); do
        r=$(curl -Ss http://api.example.org/get/$id | jq .status)
        if [[ $r ...
        ...
    done

    find . -print0 | grep -z '.*.jpg$' | xargs -0 gfxcompress

    imaginary |> operator to indicate I want something performed on every item

If you have a little sense of humor, Gary Bernhardt spoke at length about what effect a better terminal environment could have on things like terminal based editors:

https://www.destroyallsoftware.com/talks/a-whole-new-world

You should have a separate output for humans, instead of having a flag for it, and programs which are the last in a chained series should default to it, but you could also redirect stuff to it in the middle of piping.

I'd love if the bash shell language was less clunky.

A standard method for programs to provide help, examples, and tab completion suggestions to the shell. Right now we have man, info, --help, -help, -?, etc, and tab completion is part of the shell rather than the apps. If all of that was standardized the tools could be much better.

I'd basically like to have powershell. Potentially with a better introspection and attributes so that you can build a more interactive CLI. For example output size estimation + tagging local read-only commands to allow showing some output preview as you combine the commands. On-a-side display of help for arguments.

My pet hate is that commands themselves cannot tell you things about them in a structured way. There's no reason why completion and --help are somehow separate from the execution itself.

Love: context aware shell like zsh/oh-my-zsh provide. If I'm in a git project, show me a good git summary for example. If I'm in python venv, tell me about it. If I'm in some python project, extract its name from setup.py.

It should have a daemon to centralize things such as command history across multiple terminals.

A modern protocol to communicate with the terminal would be nice.

Don't google errors. Don't network anything that isn't explicitly requested to be networked. Don't give any built-in affordances for HTTP or other poorly-designed, politically-imposed protocols. I don't even know what you're talking about with microservices, as that notion only makes sense in the context of implementation details of RPC services ("Cloud APIs" in 2016 parlance).

A modern shell would:

- Never use text as the interchange format, but rather keep binary representations in memory and link all commands in a given interaction into a single computation, doing inlining and optimization across the boundaries of what are currently separate processes communicating via pipes/IPC.

- Know about the structure of valid invocations of commands (essentially, their type signature and the algebraic type structure of their parameters), preventing any "invalid invocation" error messages a priori. Only valid options would be permissible for tab-completion, and un-tab-completable options would give error feedback directly without executing the program.

- Have a principled, data-race-free alternative to the filesystem for persistent storage of data, which maintains type information without preventing useful generic operations like bytewise encryption.

- Support unicode as the only character set for text.

- Encourage proportional fonts, so as to make box-drawing characters not work properly. An associated UI system would permits applications to refer neither to character cells nor pixels, but only to a graph of modifiable or immutable values and a set of presentation hints. Platform-specific modules would interpret these based on the capabilities of the local terminal. Full graphical applications over SSH are trivial under this model--no more "I use a shitty 1980's-era UI because that's the only thing I can export across the network consistently".

- Allow addressing both local and remote system resources (RAM, CPUs, I/O devices) via a uniform interface, and allow dynamically attaching and detaching these from running processes, both local and remote.

- From a more traditional shell perspective, it seems important to support "by" operations with good ergonomics. This is stuff like "sort all these files based on the output of applying this other file-accepting command to each" or "filter out all paragraphs in a text file containing the string 'foo', but only print the last seven characters of each one.".

These would be a start.

Looks like IPython Notebook is almost an ideal way to interact with a computer (as an information processing device, rather than, for example, a game machine).

    foo = !ls
    bar = !cat *.txt # returns list of lines

I'd like to see a good CLI design involving sandboxing-by-default, and handling object-capabilities (e.g. file descriptors) as first-class objects.

Right now, "convert a.jpg b.png" passes the strings "a.jpg" and "b.png" to ImageMagick's convert command, but that command is free to open whatever files it wants, since there's no distinction between strings vs resources such as filenames, network sockets, etc.

You can do this with pipes in simple cases, and bash has some support for this, but it's very primitive and the syntax is cumbersome.

Black Screen has some pretty interesting ideas:

https://github.com/shockone/black-screen

I find CLI a great interface. Its just stuck in pre web days! Here are some thoughts on its design / UX -

- contextual help. if i write a command incorrect, it should suggest correction and link to more help.

- cloud storage of all my command history

- be more understanding. talk a bit in natural language. Eg. show my ip address -> translated to the right shell command.

- learn and grow automatically as the community builds more tools. Like, hey used this command but check this one out!

It is not feasible to upgrade all existing scripts to adhere to this but a wrapper shell that can provide this functionality should be very well possible.

I've tried using Elixir's iex as a login shell. It was an interesting experience. The pipelining in Elixir actually makes it feel a lot like bash. In Elixir, remote shell [1], autocomplete are built in. Strings are binary. Structs help structure output for human vs machine use (e.g. see HTTPoison.get("http://example.org") vs. HTTPoison.get!("http://example.org"). Processes are cheap. Functions are compostable. Rock on!

http://elixir-lang.org/docs/stable/iex/IEx.html#module-remot...

Although, through a long career, I've become accustomed to a wide variety of CLIs, I tend to agree: We've moved beyond 1999 a bit. The fact that a lot of these systems have legacy and tradition isn't sufficient. Languages like COBOL also have a long history. But now we have lots of other languages to choose from.

First off, as much as possible, I'd eliminate non-words. I tutor a lot and people think perhaps I have a speech impediment the first time I say "grep". (Yes, I know, it's not technically part of the shell. But okay how about "fi" and "esac"? Really? Why not "enod" then?)

I'd take command completion further: IDEs often have drop-downs and function signature descriptions as you move along coding. In a hypertext world with tooltips, etc, I think there's be a lot of room for those types of ideas.

I do think the philosophy of "do one thing and one thing only, but do it well" is a good one. Piping stuff together is wonderful. I wonder if it would make sense and be shorter to explain in plain English, if the "water flowed the other way" instead. For example:

"sort the output of the find result" = sort | find

as opposed to:

"take the output of find and sort it" = find | sort

(That last bit was just a random thought of the moment, just trying to think a wee bit outside of the box.)