8 ms·

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 re

• aduitsis 12y ago
  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 usefulness? So why shouldn't we have a couple of extra escape sequences where the terminal could, e.g. draw an arbitrary bitmap? You are right, that would certainly require some sort of standard becoming prevalent, but why would a little extra capability (that doesn't break compatibility) be a bad thing?
  • a3n 12y ago
    I wouldn't mind it.
  • lmm 12y ago
    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.
    • BruceM 12y ago
      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. :)
  • lorenzfx 12y ago
    For a start I think it would be really awesome, if the terminal could display html (+css).
    • to3m 12y ago
      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.
    • rsync 12y ago
      "For a start I think it would be really awesome, if the terminal could display html (+css)." That's scary. My browser is a very complicated tool that does a lot of complicated things and has a huge attack surface. OTOH, the terminal is incredibly simple and does almost nothing. That has been a very useful division of labor these past 20 years and I'd like to keep it that way.
  • rsync 12y ago
    "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." Is that true ? For instance, I am not aware that (for instance) the OSX terminal app does mouse reporting or geometry reporting. Does default xterm ?
    • Crito 12y ago
      Yes. For instance, Vim necessarily knows how large the terminal it is in is. Vim also supports mouse input, allowing you to click around in different windows and whatnot.
    • judk 12y ago
      In Terminal.app you can use the mouse to move the cursor at the command line. Since at least 10 years.
• pjmlp 12y ago
  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.
  • MrBuddyCasino 12y ago
    I have used PowerShell, and currently learning Clojure. They never occurred to me as being similar - or did I miss the point?
    • pjmlp 12y ago
      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.
      • MrBuddyCasino 12y ago
        Office COM automation is what I did. I get what you mean, but in my experience, interfacing with native code is not always straightforward. Also there are odd cornercases where you need to fallback to p/invoke. But More importantly, you can't change anything, you can only use it. So the FFI is nice and easy, but you could say the same about other languages. Or am I confusing things with Smalltalk images? Cl was somewhat before my time.
• userbinator 12y ago
  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.
  • BruceM 12y ago
    Okay. But sometimes, the logical output format for the response from a command is going to be an image. And sometimes, you'd like to view that inline with your commands in the terminal. That isn't that radical a suggestion. And it doesn't turn anything into a big old GUI suddenly. :)
  • tbrownaw 12y ago
    Clearly, the proper solution for this is pervasive hi-def videoconferencing. :)
• anon1385 12y ago
  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.
  • rkrzr 12y ago
    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.
• deeviant 12y ago
  I agree with you and disagree at the same time. Command line interfaces are extremely powerful, simple to implement, extend and leverage, but, GUI's have their own advantages mainly in information density, context clues, and ease of operation. There is a world for them to both live in, but I would disagree with OP's approach of bring graphics to command line and suggest the approach of bringing command lines to GUIs. I have already embedded a command line terminal in several GUI's I've built for industrial machines. The users can see the corresponding command line command pop up in the terminal when they click a GUI button and are free to type commands into the terminal. They can also define a script or batch of commands and easily assign it to a GUI button. It was amazingly efficient for engineers to work with prototype machines whose functionality and controls were constantly in flux. Downsides are that exposing a terminal to a potentially non-expert operator is a potentially dangerous, and I had to spend a good deal of time validating and sanitizing inputs(and risk missing something). In the end, the terminal was removed in the production GUI, but was extremely helpful in the creation of a functional GUI that worked for the operator, rather than the opposite. In the case where the operator is always going to be an expert and is working with a complicated or constantly changing process, I could see a CLI/GUI interface working well.