Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rich Command Shells

waywardmonkeys.org

Post reply on HN
Print view View original

31–40 of 101 posts

Re: Rich Command Shells

#31

Post by userbinator »

zorbo wrote: post #16

Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It's compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it. The command line works with text. The command l…

It's also far easier to help someone over the phone/other "blind" medium of communication with a CLI than a GUI, as you can tell them to press keys on the keyboard and read back the output that shows up, instead of asking them to find and click on things - followed by their thousand-word response (a picture is worth...) describing in exquisite detail everything on the screen except for the exact information you wanted...

That's not to say CLIs are perfect for everything, because there are definitely use cases where a GUI makes sense.

Re: Rich Command Shells

#32

Post by lorenzfx »

aduitsis wrote: post #20
zorbo wrote: post #16

Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It's compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it. The command line works with text. The command l…

Exactly as you indicate, even in "classic" terminals we have features like unicode support, color, geometry reporting, mouse reporting, window title manipulation, arbitrary cursor movement, etc. All these are in widespread use today. These features could not have been implemented in a real tty, but nowadays I think it makes sense to have them. Maybe some are a little kludge-ish, but are we really arguing about their…

For a start I think it would be really awesome, if the terminal could display html (+css).

Re: Rich Command Shells

#34

Post by anon1385 »

zorbo wrote: post #16

Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It's compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it. The command line works with text. The command l…

Text isn't the universal interface in Unix, byte streams are. You can quite happily send non-textual control characters and such around in Unix, or pipe data containing NULLs from one process to another. 'Text' is a very seductive abstraction, but it's one of the most brutal to work with once you start interacting with the real world and have to give up on ascii and deal with encodings and unicode and so on.

Putting commands and data inline is a recipe for disaster and a million command injection exploits. The Unix philosophy has broken the minds of generations of programmers. It leads them to doing things like concatenating strings to build SQL queries or doing IPC with ad-hoc regex-parsed protocols or using a couple of magical characters to indicate that the contents of a variable should be parsed and executed instead of just stored. Take a read of some of the earlier threads on HN about Shellshock, and you will find numerous people blaming Apache for not "escaping" the data it was putting in a shell variable. As if it even could.

Even Unix nerds have at least partially internalised the dangerousness of the paradigm -- "don't parse the output of ls" and so on. The fact that the Unix paradigm (passing everything as strings with magical characters and escape sequences) is broken for the most fundamental computing tasks like working with file names ought to be a damning inditement of the paradigm. Sadly people merely parrot the rote learned lesson "don't parse ls because file names can't be trusted", without thinking about all the other untrusted data they expose to unix shells all the time.

Just this week Yahoo got exploited. At first people thought it was Shellshock, but no, it was just a routine command injection vulnerability in their log processing shell scripts. A problem blighting just about every non-trivial shell script ever written.

The usual reply is "don't use shells with untrusted data". But auditing where any particular bit of data came from can be just about impossible once it has been across several systems through programmes written in a variety of languages, stored on a file system, read back and so on. The only sane solution is to never use shell scripts.

Like the C memory and integer model makes writing secure C code borderline impossible, the Unix "single pipe of bytes that defaults to being commands" paradigm makes writing secure shell scripts borderline impossible.

Unix needs to be taken out back and shot.

Re: Rich Command Shells

#35

Post by a3n »

Dewie wrote: post #30
a3n wrote: post #25

Earlier quoted context omitted.

For me, because I can't compose strings of gui clicks into an ad hoc list of transformations on text. And I do that a lot in the shell. There is also no command history for my gui clicks; once you've clicked on something, there's no way to reuse that click in some slightly different way.

It's perfectly possible for a GUI to have a command history, if the GUI is just a front end to a CLI. Then you can click around when you want to explore, and can go to over to the CLI when you know what you want to do and want to establish a more streamlined workflow. Or even click around and do stuff, and then extract a script from that recent history of clicks and interactions. Some R (programming language) GUI fro…

Not sure why, but I'm reminded of the old WordPerfect dual mode, with rendered text on top and raw mode on the bottom. It was a little annoying because sometimes that was the only way to get something done, but it was also fairly powerful.

It would be kind of cool to have gui interfaces (including the general desktop gui) have something like this dual mode.

Re: Rich Command Shells

#36

Post by BruceM »

lmm wrote: post #27
aduitsis wrote: post #20

Earlier quoted context omitted.

Exactly as you indicate, even in "classic" terminals we have features like unicode support, color, geometry reporting, mouse reporting, window title manipulation, arbitrary cursor movement, etc. All these are in widespread use today. These features could not have been implemented in a real tty, but nowadays I think it makes sense to have them. Maybe some are a little kludge-ish, but are we really arguing about their…

Like extending email, there's a a chicken-and-egg problem. What terminal emulator is going to add a command that no program uses? What program is going to use a command that no terminal implements? By all means implement this thing - I wouldn't be surprised if there were already terminals that did that. But personally I'd be surprised if it caught on. Compatibility matters.

In my post, I mention that iTerm supports inline images (although only in nightly builds so far). So does Terminology.

xterm actually support Sixel graphics now (although with 16 colors and a configure flag being set). Other terminals also support Sixel graphics, but not all terminal emulators and not the primary ones (Terminal.app, PuTTY, iTerm2, GNOME Terminal, etc).

Sixel and Regis graphics used to be available in actual terminals. I didn't mention Regis graphics in my post, nor did I mention Tektronix graphics, also available in vintage terminals. Both Sixel and Regis graphics were designed by DEC (Digital Equipment Corporation). Sixel was raster-based while Regis was vector-based.

Should we bother with Sixel today? Who knows? But there used to be standards for this sort of thing, but in the actual physical terminals, before we all switched to terminal emulators, most of which stuff with VT100 / VT220 emulation rather than anything too advanced. (Regis was available in the VT240, while Sixel came with the VT340, I think.)

Once the iTerm inline image support is out in an actual release, I have some tools that I'll update to support soon after.

But I have some follow up posts where I'll talk about some of this in-depth. This wasn't a random one-off post that I wrote. :)

Re: Rich Command Shells

#37

Post by to3m »

lorenzfx wrote: post #32
aduitsis wrote: post #20

Earlier quoted context omitted.

Exactly as you indicate, even in "classic" terminals we have features like unicode support, color, geometry reporting, mouse reporting, window title manipulation, arbitrary cursor movement, etc. All these are in widespread use today. These features could not have been implemented in a real tty, but nowadays I think it makes sense to have them. Maybe some are a little kludge-ish, but are we really arguing about their…

For a start I think it would be really awesome, if the terminal could display html (+css).

This would probably be a good starting point. I've already found it quite useful sometimes to have programs output HTML+images so that the results can be viewed formatted. A terminal that could display that inline would be very handy! I don't really want one window for my text output and one for my HTML formatted output. There are some open questions (support links? do anything with javascript? etc.) but for my purposes just displaying reasonably-formatted graphical HTML output would be a useful improvement.

(Writing HTML files is workable, but a bit annoying to use in practice, because if you don't run the web browser from your program (= more windows) you have to tab over to the web browser and hit F5. And that assumes you're overwriting prior results on each new run, of course, which you might not want to do (= more coding and hassle).)

I suppose it wouldn't even have to be HTML necessarily, but HTML has the advantage of being some kind of standard and many people are familiar with it.

Re: Rich Command Shells

#38

Post by pjmlp »

MrBuddyCasino wrote: post #28
pjmlp wrote: post #22

Earlier quoted context omitted.

I rather use objects and function composition in a REPL. Kudos to Microsoft for bringing to Windows a little bit of Lisp Machine experience with Powershell.

I have used PowerShell, and currently learning Clojure. They never occurred to me as being similar - or did I miss the point?

Is a very subtle one.

Imagine having a workstation where the whole stack is written in Clojure (e.g. Lisp Machine).

Now when you open a REPL window, similar to what Common Lisp Interface Manager is, you can (:require) anything public from the OS, including applications, to interact with.

Powershell is similar in that, you are using objects and are able to reference any .NET class, COM instance or public functions from native DLLs by importing them.

So you can for example, import the Office COM automation API and interact with an Excel document that you just selected from the shell.

Re: Rich Command Shells

#39

Post by rkrzr »

anon1385 wrote: post #34
zorbo wrote: post #16

Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It's compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it. The command line works with text. The command l…

Text isn't the universal interface in Unix, byte streams are. You can quite happily send non-textual control characters and such around in Unix, or pipe data containing NULLs from one process to another. 'Text' is a very seductive abstraction, but it's one of the most brutal to work with once you start interacting with the real world and have to give up on ascii and deal with encodings and unicode and so on. Putting…

Agree that text is being abused in Unix all the time. The problem with passing everything around as text is that you cannot reason about anything, because everything is of the same type. One big advantage of object-based systems is that they can catch type errors and notify you of the problem. Text pipelines will simply break because one of your implicit assumptions didn't hold.
Post reply on HN