The Dawn of a New Command Line Interface (2017) | Hacker News Reader

The Dawn of a New Command Line Interface (2017)

arcan-fe.com

I have been looking for something like jupyter notebooks or matplotlib interactive mode that works in the terminal. Meaning I type in a command and if output is an image or video or interactive graph it shows up in the terminal itself. How much time would it take to create something like that with arcan? Or something like that already available?

> Or something like that already available?

There's Userland[0] which seems to be kinda similar. The demo video[1] is kinda impressive.

[0]: https://github.com/hishamhm/userland [1]: https://www.youtube.com/watch?v=gla830WPBVU

If you use Emacs as your terminal, there are solutions such as EIN: https://github.com/millejoh/emacs-ipython-notebook/wiki/Scre...

>Meaning I type in a command and if output is an image or video or interactive graph it shows up in the terminal itself.

I'd go one step further:

Give me a full 3D context (like games use) that can handle text, image, video, 3D model rendering, and VR workspaces, with the command line as the basic mode.

Wolfram Mathematica is what Jupyter Notebooks probably came from. Their notebooks allow you to do all sorts of command line stuff as well as neural nets, image processing, graphs, 3D image visualization, optimization, symbolic math, natural language parsing ..etc. It also has a command line shell.

Unfortunately, it is commercial, closed source, and not exactly cheap. The language is nice for a lot of things (kind of lisp like) though and although I love open source languages and tools, Mathematica is really impressive.

I would expect it to be possible already, given that imgcat is a thing

https://en.wikipedia.org/wiki/Sixel

I think in order to understand this properly you have to build and try out Arcan for yourself. It took me a little while to understand the LuaJIT application structure but without that in mind this seems like- "a terminal with graphics attached" which it most certainly is not. This is more of a solution to the vast amount of protocols used to shovel data to the user in the UI message pump in a fairly static way. Shmif allows sharing this data between apps without all the translation, stubs, and overhead that normally comes with the territory: https://github.com/letoram/arcan/wiki/Shmif

Those who don't understand Unix are condemned to reinvent it, poorly.

I'd agree in general, but why think that the Arcan dev doesn't understand Unix? There's nothing in the Unix philosophy that says we have to wed ourselves to the specific weirdnesses of old DEC terminals forever.

> Confusion between user-input and data – programs can’t reliably distinguish between interactive (keyboard) input, pasted/”IPC” input and other forms of data entry.

No! This is a feature. The actual core data-processing part of a program should not care where its data comes from. There needs to be separation between engine and interface, and different interfaces are needed for different types of input scenarios.

The idea of "let's show pictures directly in the terminal" is as old as terminals themselves.

It never works, because abstracting away from visual distraction is the very point of terminals in the first place.

I disagree. The reason it doesn't work is because:

- there are so many different standards that terminal emulators adhere to that it makes it practically impossible to write anything that works reliably

- and you need backwards compatibility which means you can't easily break away and create a new CLI framework designed to progress CLIs into the next century.

The fact that ncurses and other terminal UIs have been so prevalent demonstrates that "visual distraction" is sometimes beneficial in a terminal. So much so that some people's tmux sessions could be mistaken for tiling window managers. But unfortunately the terminal is still ostensibly the same 1960s protocol.

>abstracting away from visual distraction is the very point of terminals in the first place.

Um, no. Text terminals are a natural outgrowth of how telecommunications has worked from the start.

It's easy to trace their evolution starting from the first telegraph and radio messages that used morse code to send messages... the information is written onto a paper page line by line to replicate the original message written by hand.

It's a natural outgrowth from that to have the machine translate back to a line of text. When it's time to print the next line, it makes sense to unroll the next part of the scroll (scroll down) rather than start your decoding by unrolling all of the available scroll paper.. that makes a mess, and tends to lead to loss of data.

Early computer TTY (teletype) terminals used roll and fanfold paper to print incoming characters. You could use them for editing despite not having an addressable cursor. Some editors of the time would support using a printing terminal for editing by working on a line by line basis. Unix supports editing on the command line with sed and ed.

It's a natural transition from the line by line printing on paper to a CRT display... you just print each line starting at the top of the screen, display as much stuff as you can, and when the screen is full you get rid of the oldest information (the top line) and print the new line in the space at the bottom. Just like using the paper scroll, except instead of having a bunch of already printed paper hanging around, there's nothing... much neater.

From that, the idea of editing using an addressable cursor comes quickly, leading to the text terminal apps we all use today (which used to be hardware based.. a keyboard/screen arrangement that couldn't run programs and in some cases wasn't digital).

The command line wasn't invented to provide a distraction free environment, it was literally the only thing available, and it's still an optimal way to get certain workflows done over and above GUI based systems.

It also remains a natural way to do programming because almost all programming happens via computer languages rather than visual systems.

> The command line wasn't invented to provide a distraction free environment, it was literally the only thing available

You miss the point. It's not important why it was invented, what's important is why it continues to be popular in 2019.

It doesn't work because it breaks the concept of an addressable grid of cursor positions for individual fixed fonts. How do you mix bitmaps in cleanly?

Plan 9 did away with that dichotomy by making it graphical first called /dev/draw. A console device, /dev/cons, handles textual i/o and renders it to the /dev/draw device. You can bypass that and open /dev/draw and render your own text using the same library /dev/cons uses. If one needs a unix compatible virtual terminal with addressable cursor and proper copy/paste then the vt program is used. vt then opens /dev/cons and interprets shell escape sequences written by the program and pokes at the /dev/cons buffer. So the rc shell in plan 9 doesn't do escapes or colors or anything. It just reads and interprets commands from stdin and writes its output to stdout in the most simplistic manner possible. pretty much a serial console that keeps scrolling. There is no cursor.

Just realized I made a mistake, vt doesn't write text to cons, it renders the text itself though grabs keyboard input from cons. It's a graphical program in that sense as it has to also handle color text in xterm mode in addition to providing an addressable cursor.

Reply on news.ycombinator.com