TermKit - a graphical terminal replacement

I don't know that we have to make the commands themselves data-aware. The UNIX philosophy is that everything is a stream of bytes and you build on from there. After all, we have plenty of command-line tools for audio, video, structured text, archives, etc.

This tool could simplify cognitive load in two ways. One is by helping you visualize a given stream - untangling the mess of text, data, and what-have-you, perhaps scanning for known headers and letting you drill down on individual components.

Another is by helping you composite functions to operate on data. Say I have a video stream, and I want to extract every third frame, scale and quantize them, and convert to an animated gif. Quick, what's the syntax? Yargh, man page hell. 20 minutes later, I've got it, but it wasn't any fun, and some of the commands weren't stdout-friendly so I couldn't apply pipes that way I wanted.

I'd love a better way to explore functions available to me perhaps based on data type (e.g. Image* -> Image) and even browse and preview user-contributed transformations. There was a Haskell shell that went in this direction, although Haskell is sort of the opposite of UNIX so not sure this is part of the plan ;) 

I played around with what I think is a very similar idea a while back: https://github.com/ianb/jsshell -- I think the basic architecture is the same, but this is much more advanced; I never really got past the point of displaying all output as literals.

In both cases I think this is really as much a replacement for the shell (e.g., bash) as for the terminal. The truly fundamental verb in a Unix system is executing something with a set of string parameters, an environment, and a cwd, and passing stdin in, with stderr and stdout coming out. That's pretty much everything, so there's a lot of flexibility about how you can present that to a person -- all the stuff like &, if statements, file redirection, shell quoting, etc., is part of the shell UI, it isn't really core to the OS or any of the commands.

There's a lot of graphics and icons in this particular implementation, but IMHO that's not really the important part. Taking out the statefulness of the shell is the more interesting part to me. "cd" seems magic, but it's just setting an internal variable in the shell. Foreground and background processes seem core, but they are just a way of handling the inability for a terminal to handle more than one thing at once. Variable substitution, redirection, backticks... these are all abstractions; and they are useful abstractions, but they might deserve a bit of rethinking.

Ditto to that. I admit predisposition to liking Termkit because I also had a similar idea in the past and I had neither the time nor talent to go anywhere with it. Kudos to this guy for producing something that looks like a very large step in the direction of improved usability and a potential step towards improved performance if programs can be made to pass each other common structures without needing to serialize and reparse the data until it needs to be seen by a user.

In addition to the frontend and pipe changes, I also imagined changing the way files are accessed. Some subsystem could put indexes and attributes on certain data files so you could run something like:

$ query --tsv login, uid, name[last='Smith'] mysmiths.tsv

or:

$ cat /etc/passwd[@uid=0]@login

and you would get the desired set of information without needing to write potentially buggy regex scripts. If there was a new type of file that you wanted to get data from in a few different ways, you could write only one buggy regex script to use as a filter and then query the file with the shell's normal query methods to pull down any information you might need. In the example of pulling users from a file, the shell could know from the attribute metadata that you are looking at a list of users and it could show the results as widgets that you could right-click to get the user's properties.

This all implies rewriting every utility in the system to accept recordsets instead of text, adding custom code for every different targeted data file, and making sure it all works with existing tools that have not been converted yet. That could be difficult, or at least time-consuming.

that webkit will render faster than a terminal emulator is just pure fantasy, is like saying that a smart phone with all the fancy apps will eventually use less power than a solar powered calculator. you ppl are addicted to osx overdesign. no graphical user interface will beat a keyboard in the right hands, like it or not. pure fantasy, hipster hackers