TermKit - a graphical terminal replacement | Hacker News Reader

TermKit - a graphical terminal replacement

acko.net

1,056 pointspimeys200 comments

It's funny, his 'ls' by default prints out an information-sparse grid of icons (only showing 10 items with a horizontal scrollbar?), whereas when I use the command-line, I'm looking for exactly the opposite of a GUI - an information-dense table of text. I agree with the commenter that -r-xr-xr-x - or even 0555 - is far better than "you can't touch this" (which doesn't describe who can't touch it, and in what ways). His "rich display" is actually a display of poverty - it conveys less information than text.

The typing of file / stream data is interesting, but I don't think it's realistic - it requires all tools to change virtually overnight to preserve the headers. And it's not enough just to preserve headers; what if you pump stuff out to a temporary file and read it in a few milliseconds later? What about compound files, with data chopped out of them? If you want pretty pictures, syntax highlighting etc., ISTM better to have an enriched terminal communication protocol along with a couple of viewer programs which can render data formats to it, rather than change the whole world to type every data flow everywhere.

On the other hand, ls isn't showing you the file type, and will never show you content. And you're mixing presentation with content, which is poor engineering - see the guys coming up with regexs to handle time because the only way time is presented to them is as text,

Good shells have prompted object pipeline based tools before - PoSH is only a few years old. And it's still possible for older tools to run with no degradation in quality from their previous environments.

This is really compelling.

ls shows file type by coloring - check out ~/.dircolors/dircolors/LS_COLORS and ls --color=auto - and kind by extension - ls -F. Showing things like thumbnails seems to me to be of limited use. When I want to see the directory in all its glory, I'll do the moral equivalent of "cygstart/open/whatever .". That'll give me a proper shell window designed for viewing content with thumbnails etc., rather than trying to stick it into the terminal. I've had enough experience with things like dodgy video decoders crashing the shell's thumbnail preview mechanism to know I don't want that stuff anywhere near my terminal unless I specifically ask for it.

Powershell - I do indeed wish Unix shells worked a little more like it for jobs like parsing ps output portably across platforms, but it has poor performance for what I use the shell for, because it doesn't run each pipeline process as a separate process or thread - everything is single-threaded. I frequently run sed, awk, grep, sort over multi-GB files and rely on processes and job control (fork-join through mktemp, & and wait, and xargs -P) to make it work quickly.

But if, as I mentioned, the terminal supported a richer communication protocol - one smart enough to show render full 32-bit images including alpha - then a version of ls could be written that does what his ls command does, without needing to go as far as he does.

Consider these bugs to be fixed, not irreparable complaints ;).

On the other hand, imagine being able to 'jump' into the output with a cursor, hit enter and open any file, or hit delete, or F2 to rename etc. From a UI point of view, it could be great (notwithstanding my other comments).

> 'His "rich display" is actually a display of poverty'

Presumably the "view" for `ls` will be configurable, so this is not an important issue. The worrying part for me is that it's another of layer of separation between me and my data.

I had a similar idea about 10 years ago, but never got around to implementing it.

I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!. But clearly it can. For example - wouldn't it be nice to have a terminal status bar with your CWD / git branch / etc in, without cluttering up space before $? Yep, you can use screen, and that destroys your ability to use the scrollbars.

Or, consider filename completion. Wouldn't it be nice to show the intended completions in a popup as you're typing (like web browsers do) ?

Why, when I do 'ls', can I not drag & drop one of the files to another finder window? Why is the terminal forever isolated?

Why when I run 'mvn install', which generates umpteen bazillion lines of output, can the result not be folded into a single line showing the summary, that I could expand if I wished?

There's lots of scope for this kind of thing. My main concern would be whether a single WebKit control is the right way to go - it'd be nice to, for example, embed custom controls within the shell (but this might also be possible).

So I think it's an awesome idea.

I also think this is a great implementation of a useful idea.

Why all the haters? Surely the next step is a MIXED-MODE console where you can have both the power features shown, and a simple mode for the die-hard traditionalists.

Again... stirling work and I'm looking forward to it.

Yes, that's possible. Webkit embeds JS, and you can do the craziest of controls in JS, communicating with your process through JSON packets (at least, that's how I understand the article). This would need some extension mechanism at the side of the shell, though, but that's not rocket science.

"I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!"

Improve it all you want, I'm totally into that. The problem is that once your "terminal" ceases to be a terminal emulator then you lose so much it's pretty unrecoverable.

Most of the things that you suggest are very much technically possible for a shell (perhaps zsh with some extensions) running in xterm. You'd be left with some sort of unholy combination of a rather modernized `mc` and an otherwise modern shell, but it'd be a very interesting product.

tl;dr: We're not opposed to improving the 'terminal'. I'm opposed to 1) mistaking "improving the terminal" with "improving the shell" and 2) losing the terminal.

A terminal emulator running on an object-oriented system like Termkit could run vt100-friendly filters to convert everything to text before it is sent down the line to the user. Users who did not know they were connecting to such a system might not notice the difference.

Although I am not entirely sure what you are attempting to communicate, what I will say is this:

If you do not provide direct user access to a pseudo terminal through a terminal emulator, then you will undoubtedly lose functionality. You need both the pseudo-terminal and the terminal emulator. If you do provide direct user access to the pty through a terminal emulator, then what the hell is the rest of the crap there for?

> wouldn't it be nice to have a terminal status bar with your CWD / git branch / etc in, without cluttering up space before $?

You can already do this. http://www.faqs.org/docs/Linux-mini/Xterm-Title.html

> Wouldn't it be nice to show the intended completions in a popup as you're typing (like web browsers do)?

This can probably be written as an extension to bash/tcsh/zsh to use the pop-up completion facilities of vim. If you want nice webapp-looking ones, you might be able to get away with terminal escape codes and use a perl script (this is how rxvt lets you click on http links automatically).

> can the result not be folded into a single line showing the summary, that I could expand if I wished?

An interesting point, and I was going to counter with a small one-liner using 'tee,' but I couldn't think of a good one quickly that does what you really want: 'auto-collapse.' The problem with this is that often with giant lines of output you really only want to look at the last few to see what happened. Otherwise your output is typically some kind of streaming log (you do not want auto-collapse for this) or a poorly written program. "walls of text" suck and are usually an indication of something you expect to have a lot of output (looooong makefile) and can do a less accordingly, or an unexpected error. If it's an error you want to see what it is, so you're going to click on the 'expand' button -- an extra click every time on an all-typing interface kind of sucks.

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'] < /etc/passwd > 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.

I just saw this: http://jsonselect.org/#tryit

So putting that in.

man, if you had to operate daily hundreds of files you will forget quickly about drag'n'dropping, scrollbars and all that annoyances. about the popup is useless on a keyboard controlled interface as the number of keystrokes needed are the same. the problem you have, is that you think that your terminal application is badly-glued into your graphic system, when in fact your graphic system is badly-glued on terminal applications

I love this!

It has fundamental conceptional flaws. But hell, finally someone is rethinking the terminal, please continue working on this!

Here's the direction I would propose:

It must be 100% backwards compatible. This is not optional, anything else is a non-starter. Likewise trying to re-invent the entire unix userspace toolchain is a terrible idea.

So why not do it the UNIX-way and how terminals have always done it:

Start by emulating a normal terminal (xterm/vt10x). Add support for a special ESC-sequence that switches the terminal into TermKit mode (and another one to switch back).

This way we have a normal terminal, with a bonus-mode.

A simple cli-wrapper could be provided to mix the "magic" in. E.g. to cat a PNG I would: 'cat foo.png | tk_wrap'.

And on the screen that image would magically be embedded below my command line, just like any text output would.

tk_wrap would be small wrapper that first emits the termkit-esc, then the stdin-data (converted to the json meta-format), and finally the termkit-end-esc.

That's the basic architecture that I'd like to see. And from there, sky's the limit.

I hear what you're saying, but respectfully I disagree.

To me, it's like suggesting that the iPhone would be better if you added a physical slide out keyboard to make it more old-school; sure, you could do that, and would probably score popularity points with unconvinced customers.

But you would compromise tons of secondary aspects of the device to do so.

If TermKit would have a "traditional" mode of operation, and let you switch back to it, it would mean that TermKit has failed in being a comprehensive tool. I hope I can get around that.

Thanks for replying, and I am the one to be respectful, as you are the one who is doing all the work. So please take all my comments as an attempt at constructive criticism. :-)

While I can understand your viewpoint I'm worried that it will prove difficult to gain mindshare by attempting to replace existing terminals instead of augmenting them. As long as I can't use TermKit as my only terminal my motivation to even try it is non-existant. And I'm sure most people are like me in that regard.

Either way, I hope you will keep on working on it, as I'd love to see terminals become smarter. Once it's fit to fully replace my iTerm I will give it a shot.

You could put the "new" mode of operation directly against the "traditional" one only if you were proposing an actually new paradigm (like the point-and-click interface). And even then you would still want to allow a way to fall back to what's tried and true.

As TK is essentially an _improved terminal_, I don't see a reason to totally break off from the current power of the traditional CLI, especially if alienating current power users in the process.

The biggest limitation are the existing applications. Initially the new features could be opt-in, and as the new idea picks up, you would then have more and more console applications support the new type of terminal.

> TermKit has failed in being a comprehensive tool.

As it should. Unix disdains comprehensive tools in favor of the pipeline and, generally, picking the right tool for the job.

After seeing something about this yesterday, I said on Rstat.us/Twitter that I thought it was pretty but disagreed with the whole premise. I still do, I think, but I'm very impressed with how reasonable Steven's response was. He wrote me and asked pretty much "Why?" I said essentially "Unix philosophy" and attached the link that ended up in his blog post.[1] He wrote back and at some point he wrote this post, probably replying to all the people who were taking snipes at him. So this is a long way around to say, kudos for being gracious and serious in the face of people glibly writing off your hard work.

Having said that, I'm still not sold on the concept - yet. I've played with it a bit this morning. Obviously it's still pretty alpha (more than one seize up or crash), but that's fine. My larger problem is in figuring out how it would fit into my daily work flow. After trying it out now, here are some concrete issues:

+ No monospace fonts for code. The output of cat looks like teeny-tiny website font. Things are no longer "lined up". That's bad.

+ I can't use any applications that take over the terminal (irssi, mutt, vim, less). Steven says as much - it's not part of his design - but for me it's a big problem. It means that even if I embrace TermKit, I still need those 1980s terminals.

+ No scripting language built in. As bad as shell scripting might be, I get an absolute ton done with it. I don't want to give that up unless something will make up for all that "getting shit done".[2]

+ TermKit (maybe?) forces me to change habits I can't afford to lose. One small, but I think important, example: If you try to run this:

    awk '{print $1}' file.txt

TermKit doesn't echo the single quotes. That is, you can type them, but they don't show up on the screen. I'm not really sure what to do with that. Does that mean I should stop typing them? Does that mean that I still must type them, but TermKit strips them because they aren't pretty? Does TermKit allow me to do it either way? I'm going to need to remember how to quote things when I log into a remote machine over ssh, so if TermKit will force me to change habits, that's a big, big problem. (After a few experiments, it seems like the single quotes are still required. Without them, TermKit tokenizes the stream differently. If that's the case, why refuse to echo them to the screen?)

[1] http://www.faqs.org/docs/artu/ch01s06.html

[2] Cf. Ryan Tomayko's Shell Haters talk: http://shellhaters.heroku.com/

To address some of your concerns:

- Monospace fonts for code is definitely in. Try catting a .js file, it will get syntax highlighted. Most likely, it doesn't recognize the mime type of your file. It's using the old mime.types DB + some custom additions... also, the highlighter I'm using only has so many languages defined. I looked for the most comprehensive / least fail one.

- Regarding vim... I admit I just don't like those tools. I can operate vim just fine, but I hate every second of it. I would much rather be able to type "edit file", have it open up the file in my local editor, and sync back saved changes.

- No scripting language... except the whole thing is built on Node.js... :) What's not discussed in the article is that the UI is not tied to the shell at all. You can just as easily make a back-end worker for SQL, for SFTP, for a scripting console, etc. I haven't worked out how this works in the UI, but the protocol supports it. Session types can be multiplexed freely over one socket. Basically, for scripting, I think the command line is a shitty place for it, and we should just switch to using a real language in its own little console when needed.

- Regarding habits... it's not my goal to break any without reason, just to reduce the number of keystrokes. Consider it a bug. Regarding quotes... the idea is WYSIWYG. If there is a visual divider, it's a separate argument. Otherwise, it gets passed as a single unit. This may sometimes be buggy, the Unix command support is 1 week old, and I hack on this very late at night.

And on another note... it's been hilarious how people have been questioning my professional credentials just because I want to make something more usable.

I've implemented over a dozen RFCs, can match regexps with the best of them and do know which end of a pipe does what ;).

I'm also a bit disappointed on how most people here react. I personally think your idea is great and pretty futuristic. I would certainly use a tool like this. Also it's open source so if a specific detail (such as the font) bugs them it can simply be changed.

I've had similar ideas (based on Python) but never got around to executing them. Keep up the good work and don't let the angry bearded UNIX dinosaurs get to you :)

I'm having a blast and interpreting all the flak as a sign I must be doing something right...

Absolutely! Don't lose that attitude. You won't win over everyone and the fact that anyone cares enough about something you made to share their opinion with you is awesome.

Bingo. If you haven't pissed anyone off, it's because you're not doing anything important. There are people who invested DECADES of their life into a vanilla terminal ... and here you are, fucking with THAT.

the only thing that pisses me off is the guy posting how many years he was administering UNIX systems and how this monster was an "obvious" step in the field, web designers are quite arrogant

I'm so impressed with that. If I was getting that much criticism (for something so obviously excellent!) I'd be shaking in my boots. :-(

Well, a few years ago I made this Line Rider video, and then 10,000 people on YouTube told me to get a life.

Who cares what people on the internet say, they're the ones wasting their time posting it.

Regarding your quote problem: the idea is that the highlighted token signifies "quoted string". I plan to add regexp tokens, user@host tokens, etc. each with appropriate autocomplete.

I thought the current minimalistic approach was ok, but it might be worth to add subtle quotes around the edges to reinforce the idea. That's why it's made out of HTML/CSS...

The token idea is genius. This could be applied to programming languages as well. Why settle with crazy delimiters like ',"; /xxx/ and manual escaping with \n \x \\\\\\ (making a \ in a regexp in a string :P). A subtle visual hint could be enough to distinguish different kinds of textual "object".

Sure, not everyone will like this, but for people that are visually oriented like me it will make things a lot of fun.

"quoted string" or 'quoted string'? Big difference. :)

The difference is in whether escaping is necessary. What happens when you no longer need to escape things? It no longer matters which quotes you use.

That sounds great, although I would like to have a nice fall-back for those odd programs that the terminal doesn't know the appropriate token for.

I agree. I haven't actually tried your terminal, but so far it looks very nice.

Considering that when the interface for the terminal was created it was all about being able to do everything and anything without breaking a sweat. Simple things like automatic source code highlighting, animated progress bars, being able to view (now common) files like pdf and jpeg that were not common back in the old days. Popup tab complete, I can't believe that that isn't standard on all terminals already (especially since tab complete is all about being lazy, a popup makes a lot of sense).

I'll download the source and poke around it later this evening (right now I need to work on my exam of implementing the go-back-n protocol).

Cheers and keep up the good work.

PS: RDF support would be great (since you have json). RDF is the standard for sharing data (often statistics) openly online, check out http://data.gov.uk/linked-data

It's not futuristic, it's retro. I've seen three or four of these be announced with great fanfare, and then dropped. No one cares enough, the backwards compatibility is never good enough, and it's almost certainly too slow.

I wouldn't be surprised if Webkit was just as fast or even faster in rendering than your average Linux terminal emulator.

About caring enough, yeah, that depends, maybe the world is ready for this now :) At least it isn't some overengineered XML grotesquery this time.

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

What was the last time you had any problems with the rendering speed of Webkit in reality? Have you tried the other link in HN, that boots Linux in your browser, with a terminal app, and it still manages to be fast even on my modest system?

Have you looked at some WebGL / Canvas based demos lately? There are now very efficient GPU offloaded rendering APIs that make rendering graphics a breeze, it is no longer a big-overhead thing. If you don't use fancy graphics you're underutilizing your GPU.

[also, TermKit is not just about fancy graphics, but also about user friendlyness/usefullness for some tasks that are not very well handled in terminals otherwise]

It is amusing how we hackers, who are supposed to embrace change, become as Luddite as anyone else when our sacred tools are questioned. Personally I see room for this and a whole lot more. I'd like to see an amalgam of this and the traditional terminal (easy way to pull up a traditional terminal if you need it). There is no need to "replace"; I think this makes a fine addition to a hackers workspace.

Thing is, it's not about the tools being sacred. My problem with this is that he's not just solving problems I don't have -- he's solving them in a way that would make my problems worse!

For instance, I very rarely want more informations about the files from an "ls" command; and if I did, I'd probably use Finder instead. On the other hand, not having enough terminal real estate to display the entire directory at once is a very frequent problem. From that perspective, adding icons is a step in the wrong direction.

Thinking about it, if I were playing with making a better terminal, one of my first lines of thought would be things that made it quick and easy to break information out into other windows, because scrolling back and forth in the terminal's buffer is a PITA.

Of course, this new terminal might be exactly what the author needs, and more power to him if it is. There's no need for us all to use the same tools. (Thanks heavens -- I want nothing to do with Emacs or vi!)

Regarding the too-small windows for ls output option I would love if his ls could display it's output full-screen temporarily rather than needing to make the terminal full-screen first and then running ls

"if I did, I'd probably use Finder instead."

The thing that strikes me as very, very cool about this project is that you might not need the Finder at all any more.

See, here's the thing: I like Finder. It's not perfect, but sometimes it is very handy. Even if TermKit ends up implementing the complete functionality of Finder, I'm not sure why I'd particularly like to have that functionality in my terminal window. And if it's only implementing the one Finder view I virtually never use? Forget about it.

You know what would rock my world? A "lsf" command that emulated "ls" as much as possible, but launched a Finder window appropriately sized to display the results.

I've always thought Raskin's ZUI held some promise as an alternative UI paradigm. I'm pretty much a quicksilver addict now and use that to kind of combine the command line and GUI desktop worlds a little bit more at least.

That's what I aim for termkit ls to be. The current ls is a toy meant to show off the potential.

As for why? Because it will be optimized for keyboard interaction and rapid context switching.

It is amusing how we hackers, who are supposed to embrace change, become as Luddite as anyone else when our sacred tools are questioned.

In my experience, programmers as a whole are actually more luddite and irrationally reactionary than the general populace.

Really? I see the same thing whenever you get a bunch of professionals together and start arguing about their tools.

Doctors and different drugs/treatments, Contractors and brands of power tools.

Programmers do seem to make the biggest deal about "all the fighting", everyone else seems to just accept that professionals are opinionated and arguing is how progress is made. But I'm on the inside with the programming stuff and on the outside looking in for the rest of these fields so maybe that's not true.

Doctors and different drugs/treatments, Contractors and brands of power tools.

From what I've seen, smart Doctors and Contractors eventually get to discussing empirical data and costs. Far too often, I've seen programmers just make up crap and state it emphatically.

Very good point. Do doctors and contractors have more sources of empirical data (or more widely known sources), or are they simply more willing to look for them? Does anyone here know of a good general resource for empirical data regarding the tools we are constantly debating?

Do doctors and contractors have more sources of empirical data (or more widely known sources), or are they simply more willing to look for them?

I think the culture would be a vital part of an ecosystem of empirical observation. For the sciences generally, the culture predated the sources and gave rise to them. For medicine, I think a culture of empiricism was imported from other scientific fields. For contractors, they are very motivated to note what works, what breaks, and what enables them to make more money.

Thanks for bringing up this great point.

I actually built in anonymous usage logging into TermKit using Google Analytics over SSL. It logs the types of commands you execute (no data). It's my plan to release this data back to the community regularly. I don't think anyone has done a large-scale survey of command-line unix usage before. Should be interesting.

Edit: and you can easily turn it off if you wish.

... like you just did.

Yeah, just look at the Rails/CoffeeScript thing recently.

Bloomberg found the same thing when they tried to redesign their terminals for traders - existing users were so invested in their knowledge of the "incantations" of the old interface that they were hugely resistant to a UI with a more modern learning curve and interaction.

It's very hard to make a product that essentially devalues things that your customers spent a lot of time learning. You're probably better off ignoring people who already happy with their shell experience, and going after people who have not yet invested in learning all that crap.

And yes, it's crap. And I say that not because I don't know it myself, but because in the end, much of it is not essential to the actual job we're trying to get done, it's the tools we use. And the tools are not the job.

The thing about changes involving a "more modern learning curve and interaction" is that it's replacing something that already worked and users knew how to use.

I'm quite bad for upgrading for upgrading's sake but I can understand why, of all people, traders at Bloomberg didn't want any kind of learning curve on their terminals.

Yes, it's clearly better but users don't always want to change to something that does what they already do in a more modern way.

That doesn't mean you have to stop innovating. It just means that your customers might not be the people who are already using what you want to replace.

I think that's absolutely right.

It's just my point of view, I don't really like the stance seem to take here.

You built something great, made it open source, which is even more great, and you're here to answer people, which is amazing. Now, please don't act like "I implemented x RFCs, I can do y like the best...", it's simply useless here. One reason is that people already know you can code well, and they can even read your source if they want to know better, there's no need to brag. Another reason is that HN is the place of some very good developers, and I believe humility is appreciated here, at least until you build some life changing software (and I won't debate about what is or is not life changing).

Anyways, thanks for building this and releasing the source code as open, it's cool.

He brought up his own credentials because he is amused that others have questioned them. I find that reasonable and not "bragging."

I love the idea. But as someone who also loves vim, to hear that your vision of a new terminal excludes a tool as powerful and expressive as vim makes me sad, because it means that apparently I won't be able to benefit from this new terminal. I'll watch with interest, however.

If I can make TermKit deliver on its promise, then I'm pretty sure on of you vim guys will take a VT100 JS emulator and make it work in TermKit.

Again, the architecture supports it.

The file I was trying to cat is group_add.sh. I understand if syntax highlighting isn't done for shell files, but I'm surprised that '.sh' doesn't trigger monospace fonts. That said, I'm glad to hear that in general monospace for code is the plan.

We can agree to disagree about Vim and shell scripting. I use those both, all day and every day. Tastes vary. That's fine.

I really wish you would reconsider the single quoting/WYSIWYG/visual divider business. It's extremely jarring to see awk (or sed, etc.) without those single quotes.

Doubting your credentials on the basis of this is silly, and will probably be the minority reaction in the long run. I would be surprised if you don't get offered a few jobs as the result of making TermKit.

While, I understand your dislike of Vim, Vi, Nano, Emacs, etc. (I can't work in them for extend periods of time either do to hand problems) They remain essential tools for many programmers and system administrators. Sometimes, you don't want to have the file pulled down and edited in a local edit and pushed back even if it is seamless. The benefits of inplace editing on remote machines is invaluable.

I think this is a cool idea. I think it needs to be cross platform. However, it must be fully backwards compatible with the full unix toolchain to be useful. If it isn't I can't use it, and a lot of other potential users will also be unable to use it.

I love the idea thanks for rethinking the terminal.

There is potential for TermKit to send files to your client's Vim, which opens a lot of possibilities. For example, it would be easy to have files from two different servers open. It would also reduce the number of places you need your configuration files.

TermKit's author may dislike Vim, but I suspect that he's helped its users in the long run.

vim (and other editors) have lockfiles, recovery files in case of session crashes, and assume directory locality (e.g., oops I opened the wrong file; :r filename).

> Sometimes, you don't want to have the file pulled down and edited in a local edit and pushed back even if it is seamless. The benefits of inplace editing on remote machines is invaluable.

The benefits of having your vim settings whenever you type 'vim' rather than whatever's on the server is invaluable, too. It's not an easy task to satisfy everyone, and I wouldn't expect TermKit too; nevertheless I'm excited to see how it develops.

If it's a server I plan on logging into more than once or twice, it's easy enough to pull down my git-managed dotfiles and have everything I come to expect.

> They remain essential tools for many programmers and system administrators.

So maybe TermKit isn't the app for them.

> However, it must be fully backwards compatible with the full unix toolchain to be useful.

"Must"? If this app does something useful for you, great. If not, that's fine too. Every app doesn't need to be used by every person.

edit: However, it must be fully backwards compatible with the full unix toolchain to be useful to me.

happy?

My local editor is vim in a terminal. :)

It seems like TermKit could handle curses applications fairly straightforwardly and without modifying those applications. Just set TERM=xterm, and when you see the xterm initialization string, either open a new tab or define a region in the existing tab, and emulate an xterm within that region. (If you use a region in the existing tab, it could have a control attached to it that splits that region out into a new tab.) That would allow existing programs like vim, htop, powertop, and mutt to work perfectly within your terminal.

Personally, I'd like to use this like an enhanced standard terminal. So, for instance, I'd like to have the standard ls output rather than something graphical, but I'd like the filenames in the ls output to act as links, so I can click to open or hover for a preview. And while I want the standard cat command, I'd also like to have the command that displays something inline in the terminal (with the above-mentioned control to move it to a new tab).

I agree with this.

Where I work, everybody has linux development machines, but use their machine of choice as their actual workstation. This either forces people to use vim/emacs through SSH, or set up some local file sharing so that they can use their bloated eclipse thing.

Personally, I've spent months each with a few of the popular editors around, and I fall back on vim just because my .vimrc has been tuned so much over the past few years that it's just painful to use anything else. I don't even care if the editors have more features.

Now, if I had a fancier terminal, where my mouse click picked the right vim split view instance, or highlighting text in a split view vim selected only text in that window, instead of the whole line of the terminal, I would use that. MacVim is pretty much the perfect tool for me, but it's local and not remote (and also not inside a terminal that I can split up with screen).

You might want to do

:help mouse

All of the things you mentioned are supported and work with most terminal emulators (tested with xterm, gnome-terminal, iterm2 on OSX)

> highlighting text in a split view vim selected only text in that window

Try to control-select in the terminal. Works with my Gnome term 2.

> vim/emacs through SSH

We work like that too, and I see only advantages to this set-up, the least being forcing everyone to learn find, grep, vim. These powerful tools increase productivity but have a high barrier of entry, so best is to have no other choice.

> I'd like to use this like an enhanced standard terminal

Same here. Just adding a tiny little bit of enhancement without changing anything in the standard behavior could be a bettter idea. Examples:

  - ls output is pure text but hoverable (parent's idea)
  - add a way to see thumbnails of pics in ls
  - drag and drop files in the pwd

In the article the author says "The interaction is strictly limited to a linear flow of keystrokes, always directed at only one process" and take it as a limitation. From my point of view, when doing geek work on big machines, I need to drive a "linear flow of keystroke" in the machine. It is the way to have a deterministic behavior. It is the way to be able to script my work. I feel empowered by the control I have on what the machine does. Everything else (ie Windows, Mac UI) feel like a console game to me, in the sense that I give away my full control on the machine in exchange of impressive graphics, ease of interaction and safety-for-kids.

Regarding liking vim, I have no issue with typing "edit foobar.txt" and having a local MacVim open up :)

Most of what TermKit is doing doesn't immediately appeal to me (as a longtime shell junkie of sorts), but one thing I would love to have in a terminal is tooltips, or popups of some sort. For example, say I get a 40 line stack trace, I'd like to just see one line (the exception, where it was thrown from) but have the option to learn more by clicking on a line in the terminal. Basically how exceptions are reported in the browser in Django or Rails, but in the terminal.

> - No scripting language... except the whole thing is built on Node.js... :) [...] Basically, for scripting, I think the command line is a shitty place for it, and we should just switch to using a real language in its own little console when needed.

I could see this being done well-- it's not hard to beat bash for syntax and functionality-- but I could also see it being done poorly or considered an ancillary feature.

Shell scripting sucks, but it's the only language I know that lets me write tiny little scripts in not minutes but seconds, inline, without breaking out of the flow. Just like dynamic versus static languages, the quantitative difference in writing speed is enough to make a qualitative difference in the types of programs that can be written; and the difference between a non-scriptable shell and a scriptable one is like the difference between a GUI and a good CLI.

A large part of that scriptability is just grep and sed and friends, which TermKit apparently does support, but sometimes bash's loop structures are also required...

Just my two cents.

That's all fine. There's probably a ton of other things it can't do. I certainly can't use it for my work and I spend a ton of time behind a terminal. At the same time, don't you see the potential?

It probably won't be "production ready" for years, but I would hate to think that 20 years from now we're still typing into a dinky terminal that has been around since the 70s! We won't get the next-best-thing down the road unless we start working on it now. TermKit is the first step.

It's a first step. Maybe it's not in the right direction, maybe it is, but it looks well-polished, and like good work. My instinctive reaction was not a positive one, but the more I read, the more I liked it, and you have to applaud a good effort like this in any event. People have to get out there and try for things to improve.

It's a pity that this is so difficult to try. The blog post has so much detail and effort put into it, but all that shine and polish disappears when you try to install it.

Specifically Step 1 of the instructions[1] has a link titled "install node and npm" [2] which has the line 'git clone git://github.com/ry/node.git', which is incorrect. The correct URL (as far as I can tell) would be 'git://github.com/joyent/node.git'.

In addition the linked instructions say nothing of npm, which can be installed quite easily by running 'curl http://npmjs.org/install.sh | sh' as root.

Back to the TermKit instructions again, and step 5 says 'git clone git@github.com:unconed/TermKit.git --recursive', which didn't work for me. What worked was 'git clone git://github.com/unconed/TermKit.git --recursive'.

Finally after all that, I just see 'You cannot use this version of the application TermKit.app with this version of Mac OS X.'. Would have been nice to mention that at the start.

[1]: https://github.com/unconed/TermKit [2]: http://howtonode.org/how-to-install-nodejs

Fyi, I think the current recommendation is to install both node and npm as a regular user.

I generally follow the pattern described here for node: http://blog.nodejs.org/2011/04/04/development-environment/. If you do that, and then install npm as you describe (but as a regular user), then npm will automatically be installed under the node installation.

It is a pity, but it's completely understandable since this is one man's year-old hobby project.

I don't mind, the project is in too rough a shape to interest anyone but hackers. Please come back in a month.

I get that it's not meant to be release quality yet, it's just a shame that your blog post was so comprehensive and detailed and fell down on that last point. Certainly spending half an hour installing software only to find out I need to upgrade my OS X wasn't fun :(

I really think Steven went about marketing this in the wrong way. It really should have been dubbed as a terminal alternative. By calling it a replacement he's just inviting a mass of critique which focuses on what it lacks rather than what it offers over an xterm.

I really doubt that would have changed people's reaction. Besides, to be taken seriously, I have to believe that TermKit can eventually be a fully functional replacement.

As for being hard to try and not at a useful stage yet... hey, that's not my problem. I wasn't the one who upvoted it all over the internets :).

I'd like to offer a slightly different perspective on this. As someone who is a hybrid hacker/biologist, I welcome something like TermKit. I have invested a good chunk of time learning unix commands and the shell because lots of scientific applications require it. Furthermore, as a data wrangler, the unix tools are a necessity for quickly processing and pumping files around. I require unix to efficiently do my job. I often think, "Gosh, what do all these other people do when they need to do X?" where "X" is some ugly task that I can hack some grep and sed commands together to accomplish. I don't think most programmers understand the sheer number of exceptionally well-educated, genuinely smart people who spend huge chunks of their day doing menial "copy/paste" in Excel (because it's the only real tool they can use) when they should be designing bridges, curing diseases, analyzing data, etc...

If you're a unix sysadmin or a full-time hacker, you can justify the cost in time and effort of learning and memorizing all this stuff. In fact, you'd be foolish not to. But there are a lot of people who don't spend all day in a terminal. Nevertheless, they frequently need the unix terminal to get something done. A tool like TermKit could be a huge boost for those people allowing them to bootstrap their knowledge without having to dive into the deep end all at once.

There are legions of people out there who are smart enough to learn some bits of unix if only the learning curve wasn't a sheer brick wall. If you need evidence that man pages and "-h" don't cut it, start typing common unix commands into google (xargs, tar, grep, etc...) and you'll almost always find one of the top suggestions is "command_name examples" or something like that. Why is that? My grandma isn't trying to use "xargs" I assure you. Someone with enough knowledge of the unix command prompt to know they need xargs reads a man page and they still don't know how the hell to use the command properly. That's a usability problem and there are modern ways to help with it (as is demonstrated by all the things IDE's do to help programmers all the time).

I'm really excited to see where this goes. There are all sorts of possibilities it opens up.

Excellent exploration of alternatives to the old 'terminal' application. It would probably help for context to explore the Bell Labs 'BLIT' terminal and the Digital Equipment Corp VT340 (color graphic terminal) and the Tektronix 4010/4014/4064 terminals. These had capabilities that augumented the basic terminal stuff and made it prettier at least to use them.

The humorous thing for me is seeing the discussion which essentially devolves into creating a new windows type metaphor but with a lot of keyboard shortcuts.

It may sound pedantic but consider that the terminal is the terminal because terminals define a keyboard driven user interface. A user interface is a 'vocabulary' which describes actions. Its vocabulary scales from a communication channel that is 300 baud to one which has multi-megabaud connectivity. You can create a different vocabulary (which is what the other terminals above did) and get additional features.

And you can create an entirely new vocabulary if you're willing to change the minimum connectivity channel bandwidth as well (I doubt TermKit would work well over 300 baud for example). There was some good work done on this in the 80's with 'visual shells' on the PC and of course there is a ton of work that IBM did in creating optimized terminal environments (with visuals no less) on 3270 terminals which were in many ways a pre-cursor to todays IDE tools, although perhaps more like Eclipse. Their environment which ran airline reservations was a good example of optimizing the vocabulary (key strokes) against the variety of tasks an agent might need to do.

So rather than calling this a graphical terminal replacement (which it isn't) calling it a visual UI which can be driven entirely by the keyboard might be better. I think that fundamentally the "thing" about terminals that everyone sort of 'gets' is that you don't have to use a mouse, you always know where your 'focus' is, and there are millions of key combinations which you can use to express certain actions. For some, that is simply 'living in emacs' for others it could be something like this.

I bet TermKit would actually work awesome over 300 baud. The two-tier approach -- a backend that executes commands and a frontend that displays stuff -- is going to be pretty efficient (if you are only running the backend remotely). Well... perhaps the chattiness of something like filename completion will be a bit of a problem, but it'll still probably work better that more directly interactive systems because it's working with a more abstracted protocol than a terminal does.

"At the end of the day, Unix just has bad usability"

I have to say I highly disagree with this statement but, I also disagree that there is anything wrong with the classic terminal. I find a full screen terminal with nothing but text as a thing of beauty. They remove all but the most essential details and work on a very simple common format (text).

In a way this kinda makes me think of Windows Power Shell, which is trying to replace the classic shell with a more object oriented shell, it has a lot of good ideas but in ways it brings more complexity to the issue than most Unix users are looking for. Seems like this project could probably take some ideas from Power Shell though.

I certainly have nothing against this guys work but it is not really a classic unix shell replacement and should probably not strive to be such a thing.

Text is a simple format, but text with intrinsic formatting is most definitely not a simple format.

yeah thats true, thats why I get why Power Shell took an approach of passing object around as apposed to just text. I think I was thinking more from a visual standpoint when I said that text is simple.

Maybe I'm an old fogey but I'll stick with xterm and iterm. Having a terminal where I can have the same experience whether logged into a *nix box, on osx, or sshed into a remote server is far more appealing than being able to cat images or having a pretty progress bar. If I want to make json more readable I can just pipe it through one of the many json formatting scripts.

It might just be me but I find cocoa to be a bit boring and dated looking. Unix terminals are timeless. A nice tiling windows manager with 5 terminals is still one of the most beautiful set ups.

Note: the goal is to be able to run TermKit transparently over SSH. Maybe even do an "apt-get install termkit-backend" for you if you wish.

The first thing to realise is that the existing UNIX data processing tools deal fall into two categories - those that process (including generate or consume) an ordered sequence of text records (eg. sort, comm, uniq, awk, sed, grep, tr, cut, find, xargs, ls...) , and those that process arbitrary binary data (cat, dd). Most fall into the first category.

Now, while it might make sense to use a better interchange format than "newline-separated text" for those ordered text records, I don't think that adding other arbitrary data types is particularly useful, unless a way can be found to make these arbitrary data types self-describing. This is because there's little to no commonality in the types of processing that you do on different data types: the article shows the example of "cat termkit.png", but what does it mean to concatenate two images ("cat foo.png bar.gif"), or concatenate an image with a text file? Making some assumptions, we can certainly define arguably useful semantics for those, but what does it mean to "sort" an image?

And how do we write "cat" to deal sensibly with currently unknown data types, that will be defined in the future?

And how do we write "cat" to deal sensibly with currently unknown data types, that will be defined in the future?

Progressive enhancement. You get magic for the obvious things and standard behavior for the non-obvious. I still want the power and flexibility of my vanilla terminal, but I want it to do more when it can.

I want to open up a remote terminal to another server, on the other side of the planet, and do a "cat foo.png" so that I can see it. Better yet, I want to do an "ls -la" and have it show me the standard output, plus all the thumbnails of the images in the folder. I want to do a ton of other stuff too. At the same time, if load up some esoteric weird 30-year-old thing I found on the internet that I just compiled ... well, I expect that to work too. That's a must.

Of course, wanting and having are two different things.

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 ;)

This comment thread, both here and on the blog post, is the best example of stop energy being directed at forward motion I've seen in a long, long time:

http://www.userland.com/whatIsStopEnergy

Kudos to unconed for doing something remarkable. I look forward to seeing where it goes from here.

that's just a marketing site talking about a marketing term probably invented by a marketing guy, I'm okay if this gets as widespread as apple devices (and btw I really love my macbook pro) but I find it totally useless for the people working day by day with terminals, time will have the last word

Think of this as empowering people who will not use vi or emacs, but prefer Eclipse or Visual Studio, to have a visually appealing arsenal of tools which can be chained in a pipelined fashion.

What is wrong with that? Yahoo pipes for example provided pointy clickety interface to mashing up data. Lot of people used it to do useful work.

It really does not matter if a even single sysadmin who already uses the shell does not start using this. It just needs to have its OWN users that is all. If you just consider ALL Eclipse users + ALL Visual Studio users, that is a HUGE user base... Now the vi/emacs user may feel superior to the others...

but in reality anyone in this world can have their own reasons to create products and use various tools. All the best to the author of this tool for taking the pain to code this...

If it works out and gains users... awesome... else it shows we still find Old tools useful. We have not stopped using Fire or Wheels today though they very OLD technologies. Whether the shell is as important as fire or wheels OR transitionary like Hydrogen blimps or something in between only time will tell...

Even if it is - and reading the article, it's Dave Winer, who I doubt would think of himself as a marketer - then that doesn't make it wrong!

Marketing is a legit discipline with a bunch of charlatanry around it. So is programming. So is basically every field of human endeavour.

Many times you need to look beneath the veneer of abstractions that is the modern GUI, to work with speed and flexibility. However you don't want to strip away all the abstractions. That would yield the system very unwieldy. (example: Programming in C vs Programming in Assembly) The Unix command prompt is just the right amount of abstraction for me, and for many other users. What the project proposes is certainly novel, and this level of abstraction may work for some people.

Exactly, I think if you are a hacker you will stick with the shell the way it is, because knowing how stuff works with "zero" abstractions is power.

Reminds me of this: http://i.imgur.com/jqIcv.jpg

Also I mean as a hacker, not as an entrepreneur.

I think my point is that we've all been so locked into these tools that we've become blind as to where their failing are. I wanted to start TermKit from a fresh slate and only slowly add bits of existing Unix to it, so I could make sure the resulting whole still made sense.

For me, as someone that does all his work in Windows and stays away from consoles as much as possible, this entire discussion is hilarious.

I think your project is cool, it certainly is a fresh take on the console, but the minority of people that like the unix console will be very resistant to anything graphical, and the majority of people that prefer graphical interfaces will just wonder why the hell you still need to do all of that typing. :-)

The fundamental problem with consoles is that it's impossible to explore the interface. You can only use it by knowing the possible commands beforehand.

Hmm.. Perhaps that's something you could explore with Termkit? With the added graphical output, is it possible to show hints for what I can/want to do, given what I've already typed? I dunno, just an idea.

The power is in knowing the shell. You can do things quickly and do exactly what you want if you know how to use it. No GUI can give you with the same speed and efficiency.

The learning curve is steep, I like your suggestion of 'exploring' the interface. I think this deserves more merit than making the shell glossy.

A shell is far from ‘zero’ abstractions.

Hence the quotes. Like someone else mentioned its the 'right' level of abstractions for most. Heck even the assembly isin't zero abstractions.

The terminal hasn't changed much in 40 years because it very good at what it does, that is, allowing experts to get stuff done. One of the usability lessons of modern computing is that the mouse is a productivity killer. Having transitioned back to vi from TextMate, I have certainly found it to be true.

The author talks about how its a shame to give 2MM pixels to an 80 column terminal, but from what I've seen, developers are perfectly capable opening multiple terminal windows to view things like log files and running quick commands. Try that on a WYSE.

While I don't think I'd ever use this as a replacement for my terminal, I do think the "server" part of the architecture is interesting. What if you built a native OSX app to replace finder. That is something I'd use.

«One of the usability lessons of modern computing is that the mouse is a productivity killer.»

Actually, one of the usability lessons of modern computing is that the mouse makes you faster, but the keyboard makes you think you're faster.

reference: http://www.asktog.com/TOI/toi06KeyboardVMouse1.html

Here is Atwood's response

http://www.codinghorror.com/blog/2008/03/revisiting-keyboard...

This a cool project, albeit not my cup of tea. Sure, the terminals out there need a little work, but I'm skeptical about bringing too much of the "gui world" in.

There are, however, some concepts that are worth copying and that are in fact doable in current terminal environments. What I would like to see is more innovation in the world of console programs. There are lots of things to do in terms of auto-completion, navigation and integration etc.

Take a look at ranger [1] and sup [2] for examples of new neat console applications.

[1] http://ranger.nongnu.org/ [2] http://sup.rubyforge.org/

"Notmuch is an answer to Sup. Sup is a very good email program written by William Morgan (and others) and is the direct inspiration for Notmuch. Notmuch began as an effort to rewrite performance-critical pieces of Sup in C rather than ruby. From there, it grew into a separate project. One significant contribution Notmuch makes compared to Sup is the separation of the indexer/searcher from the user interface."

http://notmuchmail.org/

why should indexer/searcher be coupled to email files in particular, instead of dispatching on MIME types? why should the datamodel be something ad-hoc instead of RDF?

http://blog.whats-your.name/post/2011/02/14/sifting-thru-you...

That's something that they are working on. One example of a useful application is a text ebook collection.

Either way, large experiments like this are a necessary part of the path there.

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.

I find Unix usability standards generally pretty insane. Funny he should post this, as on the train today I was thinking of making a program I'd call 'SmartTerm' or something which would basically be a more usable, graphically augmented terminal for beginners (or people who just can't stand interfaces which depend on memorization and patience).

Some things I find nuts about the current terminal is OS X (at least the default behaviour) are:

- half the line which you need to write in is taken up by repetitive info like User, Time, and Directory

- put the currend directory somewhere useful like the title bar

- when i start to type a command, give me graphical autocompletion automatically (unless i switch it off), along with a note/tooltip explaining what the command does

- after i've typed command, give me a pane somewhere which explains what all the stupid flag options are and what they do

- give me another pane with an audit trail in plain english of what my commands have accomplished, and then give suggestions on how these could be accomplished using simpler shortcuts (especially in something like Vim. give me some help to learn the shortcuts as i work, FFS. on a GUI you look at the keyboard shortcuts beside the menu items, and get to know them naturally. this would also give you some confirmation that your command worked as expected, rather than just a blank prompt staring back at you

- let me highlight text with shift and arrow keys

You can edit the user prompt[1] in most shells as well as the window title[2] in xterm. There's also a command-line editing mode in bash[3].

   [1] http://www.linuxselfhelp.com/howtos/Bash-Prompt/Bash-Prompt-HOWTO-2.html
   [2] http://tldp.org/HOWTO/Xterm-Title-3.html
   [3] http://www.catonmat.net/blog/bash-vi-editing-mode-cheat-sheet/

> especially in something like Vim. give me some help to learn the shortcuts as i work, FFS. on a GUI you look at the keyboard shortcuts beside the menu items, and get to know them naturally.

This. I hate both vi and emacs for not having a usable menu system that lets me browse through and learn the commands as I go.

I also think bash-completion, while a huge step forward in usability, really should have focused on integrating command option help from the beginning. So, in addition to a man page, each command line utility would need to bundle a machine readable key-value list of (option, help string). Then when I type <command> -<TAB>, it would show me that help.

Pretty sure Emacs has menus:

http://jrock.us/emacs-menus.png

It does. The problem is, the terminology in the menus is completely inscrutable (i.e. many commands are named unintuitively), the menus are poorly organized, they have a small subset of all the commands, etc. I've never been able to learn any of the shortcuts from the menus.

In the end, it's your fault because you don't want to learn. Emacs does not have "cut" and "paste", it has "kill" and "yank". They are different terms because they have different semantics.

Enjoy programming in Notepad.

- you can edit your bash prompt and clean it completely if that satisfies you, - I have no problems to remember exactly where I am the most of the time and if I forget I can type pwd - graphical autocompletion is useless in keyboard controlled interfaces as it hides part of the screen and takes the same number of keystrokes to reach a result - we call it man and if you are late for your date, -h - you are in front of a tool, not a teacher, rtfm - no comment

I've always wished the terminal would be upside down, so that new typing would happen at the top. Then you could put a bunch of descriptive info in the title bar and still wouldn't have to move the eyes much.

This is why I placed my xterm title bar at the bottom and it works like a charm.

I love the idea of experimenting with graphical output on the console. I've seen images and vidoes running on the terminal (not a terminal emulator) using "framebuffer" consoles.

Sadly that typically only worked in full-screen mode.

If somebody wrote an ordinary terminal emulator that allowed pixel graphics as part of the normal text flow, and created an easy API for programs to use it, I'd be very happy.

TermKit looks cool, but I fear I'm too old-fashioned to move away from ordinary shell in such large steps.

I think this guy should look into implementing something like this as a compromise.

No, he shouldn't be making compromises at all. He's rightfully aiming at making the shell of the future. Features to comfort people that are stuck in their current ways can easily be backported in later, as we know how they work since the 70's.

I agree. I think it can be easily implemented as a slight modification to a standard terminal: bind some UNIX socket, announce the address in an environment variable, and then accept connections and commands from applications that are interested in enhancing their output.

As much as the prospect of Webkit in my terminal makes me uncomfortable, I think this is amazing. The terminal is probably my most used application and any effort towards making it better is awesome.

(P.S. - Apart from this, unconed has also been a prolific Drupal contributor and done some amazing visualization work for Winamp. Awesome hacker.)

This has been tried before with the XUL-based xmlterm around the turn of the century, but it was very slow:

http://www.xml.com/pub/a/2000/06/07/xmlterm/index.html

Interesting to see someone pick this up again.

There's actually a lot that can be done to improve current shells even without breaking the current set of abstractions and tools: http://en.wikipedia.org/wiki/Fish_shell

On windows have a look at http://poshconsole.codeplex.com/

Same idea, with powershell as the base.

Interesting. I stayed away from powershell because it does the opposite of what I want to do: it makes the shell more like a programming language, and it still limits the output to text.

Thanks for the tip.

That's what I thought when I first saw TermKit too.

None of the examples really sound all that exciting. I see the Unix shell more of a text file manipulation toolkit, so apart from some corner cases I'm not sure if adding MIME types etc really would add much value for the usual tasks. If you're adding too much structure to things, you might as well go all the way and base everything around a programming language or framework (cf. Oberon, Powershell, Lisp Machines).

I agree that emulating a terminal from the late 70s isn't exactly the peak of programming. Character-addressed terminals are just another way to get (cheap) WIMPy GUIs.

Ironically enough, this reminds me a lot of eshell, the shell implemented in Emacs lisp. Since it runs in a rich environment, it can augment a lot of standard unix functionality with really useful features, and you can extend it in a language that's not insane.

For example, grep/find results are hyperlinked, you can pipe commands directly to buffers (or even lisp functions) rather than just files, and such. In fact, now I'm tempted to add the ability to cat an image and have it display inline; should be pretty easy to implement in elisp.

As far as I can tell you have to rewrite all your applications to use this. So he's not really advocating "a cool new terminal," he's advocating a "new Unix programming toolset, with accompanying terminal, to replace the BSD/GNU tools." This is great, and I wish you all the best of luck, but it looks like you're just rewriting Applescript.

Also, the reason Unix tools don't toss around JSON/XML/MIME is for sheer simplicity. It's a zen thing, something you OSX guys wouldn't understand.

Catting a png and getting a picture is nice though.

Instead of 'cat image.png', if I want to see the image, I just 'image.png' (zsh's "alias -s" magic).

I've toyed around with similar concepts, but went the way of trying to middle-man the input and display of a standard console instead of trying to recreate one. Admittedly that creates some limitations to how integrated things can look without extra work, but it allows for normal interactive programs and really only enhances what was already there. Plus there's the added benefit of being able to run commands even while something interactive is up.

In any case, these kinds of hybrids are inevitable due to the vast room for improvement that exists in desktop and system apps combined with how powerful the web standards have become for UI and interactivity.

Really though, while I think TermKit is a decently executed attempt at this, it alienates some of its audience for obvious reasons. It completely throws away the charm of a shell with visual style choices and breaks powerful features that people expect. That's fine, because even with those departures it can suffice as a casual mode with certain conveniences for times when it makes sense.

Visual styles can be fixed or customized, so that's just shortsightedness by others.

As far as expected features like interactivity and whatever else people feel TermKit lacks, it seems like any hybrid terminal that takes this route should really try to implement a quickswitch that lets you fade between a rich terminal and a standard text console, already at your working directory with the same permissions.

Sure, people could just task switch to another running console, but that segments the whole experience a bit more.

I just looked at this through the github link. Looks very nice and useful.

Too bad it's very much bound to MacOSX/Cocoa, so this kind of rules it out as general nextgen UNIX/Linux shell.

From the article it sounds like most of the heavy UI is implemented using webkit and HTML/CSS/JS. Wouldn't this make it reasonably easy to port to *nix?

I have no clue, I looked in the github repos very quickly and saw all kind of scary .m files and I gave up :)

If it's mainly HTML/js/webkit based then it would not be hard to port it to a portable window toolkit such as Qt4 (which has a QWebKit widget...).

Doesn't the article say it's TK? Which means it's already got X bindings.

TK just means TermKit, sorry.

I believe TK stands for TermKit, not the tk widget set.

This has a lot of great ideas, and I like the idea of an enhanced terminal in general, but I think it goes too far. Having to reimplement a large number of commands to support this concept of separate view and data streams is complex.

A few ideas I'd like to see integrated into an existing shell/terminal in a backwards compatible way:

* Syntax highlighting/tokenization of the command as you type. Show the different parts of the command you're typing: the executable, the arguments, the pipes, the IO redirects, shell constructs like loops and conditionals, quoted strings.

* Maybe command-specific syntax awareness like highlighting the flags and file arguments differently, regular expressions for sed/grep, awk syntax, etc. This would require descriptors for each command, similar to how autocomplete works?

* Enhanced output formatting, like the clickable paths, displayable images, etc. But rather than modifying/rewriting the program, have a way to describe how to display the output of certain commands. The shell should be able to figure out what the final command in a pipeline is, right?

* Detect and display binary file formats based on the content rather than the filename so support existing commands.

Post about TermKit: http://axisofeval.blogspot.com/2011/05/termkit.html

As a UI designer, even though I've just begun working with terminal, I can't say I like this too much. Don't get me wrong, it looks GREAT, but much as I expected, it goes against a lot of ideas and based on some of the comments, strips a bit of functionaity (a huge no no). I think Steven's intentions are solid, but he's sort of playing with fire on this one. Cool idea, though.

Of course he is playing with fire, that's the only way to do real innovation. Remember that this is just a proof of concept, and a very compelling one.

it's curious this is on the front page at the same time as oh (or was that on reddit? - can't seem to find it now). https://github.com/michaelmacinnis/oh

both allow the shell to use structured data. i like the idea of using json myself (not that keen on the gui parts of the implementation, but moving pipes to something with more structure seems like a good idea). did plan 9 do anything similar?

Here's the link to the comments:

http://news.ycombinator.com/item?id=2559361

Only his response to the AVS question in http://acko.net/blog/on-termkit#comment-4240 made me realise exactly how powerful this premise is.

TermKit could become my OS of choice.

>monospace text just doesn't cut it anymore

Maybe in your terminal world, but not mine buddy.

Seriously. But I wish all fonts included a monospaced variant. Why shouldn't I use Helvetica in my terminal?

Did you even try to find it?

Google "helvetica monospaced".

Very cool. I'm always amazed at how much one can do with a properly composed pipeline and a Makefile or two. The power of pipes + the interactivity of a spreadsheet -- that's what I want in my next gen shell. I'll be interested in seeing how this experiment plays out.

And I do see it as an experiment, not a threat to our way of life. I like to think that the UNIX command-line environment is a local minimum.

My god, this looks terrible. There's a reason we're still using text terminals from the 70s-- they work!

I sincerely hope i won't ever have to work with this.

This is interesting, but I have doubts. He wants to fix the terminal by 'separating the "data" part from the "human" part'; in practice, using separate visualizers for human display. This puts me another degree of separation away from my raw data and forces me to trust the accuracy of the visualizers.

You already trust the accuracy of your visualizers: your eyes. Is it space or a delimiter? Is that a quote or a backtick?

TermKit could really help unix overcome the problem of discovery.

On the command line it takes extra steps to discover the switches and arguments that a given command presents. It's easy to miss a specific incantation that will bring forth the full power of a given command in a given situation. Git, for example, has an amazingly rich command. It's hard to discover what you can do so most people end up using just the few commands that they absolutely need.

Just as TermKit offers a selectable list of directories when one types a path, it would be great if it could provide a structured way to build commands invocations, that presents options and perhaps help content as you go.

In addition to helping newbies dive in and get stuff done, it would help more experienced users continually advance their knowledge of how to get the most out of the tools they use.

Some interesting ideas there. He doesn't link to discussion of similar projects: I was reminded of Commander S: http://www.deinprogramm.de/scheme-2005/05-knauel/05-knauel.p...

I've not been able to build Termkit yet, mind.

Shouldn't need to build it, there is a zipped .app included. You do have to build node.js though.

I'm just curious if he has to re-write essentially every unix tool in javascript.

I can't really say whether most unix developers would appreciate this. I don't like it and I exclusively use tiling window managers, xterm, and emacs. Though if I wanted fancy features I might try rxvt-unicode or some such.

This is interesting and a cool proof of concept. I don't believe that, as you show it, it is something I'd want to live in.

I virtually live in a full-screen emacs (on CLI or GUI). Emacs provides a somewhat nicer shell world than straight up Terminal.app. Emacs has copy & paste, a fully editable window display and its own command history.

Why do I bring this up? Because I feel that your application as currently demoed is not going to help me. I don't want to see GUI icons in general.

What I do like is your connection to the OS display layer. The ability to render out a PDF-inshell is pretty nice. Without having to go grub around for the right configuration, I can't just go "load foo.pdf" and have it pop up automatically.

So I really look forward to see what kind of cool explorations you do.

Can't really say this or that about the project. It looks cool but I have no idea whether the user interface would lessen the friction between myself and the computer; it might just as well increase it.

But that's okay. We're not supposed to decide whether the prototype points to the right direction or not; we're just supposed to rant and ramble a bit about it.

However, the question of whether this turns out to be a good idea will be evident when and if TermKit delivers. In this context it means that TermKit or some of its derivatives turn out to be actually more useful than the standard Unix shell.

The indicator would be that instead of a traditional Unix shell, people start using TermKit in order to get more things done more easily and in shorter time.

Excellent shortcut for previewing files from the terminal:

  #!/bin/bash
  qlmanage -p "$@" >& /dev/null

Opens any file in Quicklook, ctrl-c to close, or use the mouse. If you want it to stay open, just add final &.

Added to my todo list. Thanks, didn't know about this one.

I really hope this guy gets hired by Apple. There are some really great ideas here.

Looks pretty cool. The problem with the vast majority of these 'rethinking' projects though is they never get finished. That's the hard part.

The classic unix toolset remains because it is finished--that is most major problems and workflow have been ironed out.

Unfortunately I'm time-constrained these days so I'll give it a go when it version five is out and all major issues have been addressed and ported to Linux. For now I'll use fish locally and bash over ssh on my servers. Also, as I can use nautilus to manage and edit remote files using gvfs. So I've already got most of what the project offers working today.

It looks like you've re-invented Midnight Commander, which was a re-invention of Norton Commander, which was probably a re-invention of something else.

Which is a good thing! I look forward to downloading and trying it out.

Awesome project.

Browser technology is on a tear recently, and terminals are ripe for innovation. For a newborn project, this is an impressive mashup.

The number of dismissive people in this thread shows how disruptive this idea is!

I tried to start a discussion on reddit with a very basic version of this idea, which was met with a lot of criticism.

In the end, I'm thinking it would be enough to have espace characters : for embedded graphics, and for some kind of terminal hyperlink. An exemple is file names in grep listings, which I would like to be able to click to get the filename pasted on my next command line.

I like the overall idea a lot and am working on something vaguely related (though more like Quicksilver/Gnome-do).

I doubt that a modern approach is going to be able to satisfy the entire historical legacy of the Unix terminal and it probably shouldn't. Everyone who's happy running vi in an ordinary terminal should probably continue to do so.

I'd like to see it be able to run a program in the background with the -h flag or --help flag to find at run-time what the available options are to help auto-completion. This way it would be able to support even programs that it doesn't know a priori.

This looks like a fantastic direction to experiment in. Kudos to the author.

Looks really good (haven't tried it yet though). The concept is great. I'd like to see some TextMate/CommandT style functionality for file and path completion (I've been thinking cd'ing around in shells has been cumbersome ever since trying commandT).

Some other inspiration could be taken from zsh autocomplete.

awesome, my kids and the touch generation would now start using termkit as their terminal in this natural way

主意很棒,十分佩服作者所做的工作,之前我也有过类似的想法

为了不说错太多,我不知道这里是不是允许用中文?

图形化取得的成功有目共睹,而偏偏终端保持纯文本的简单

从学习linux的经历和这么久接触互联网看

.个人用户接触到的图形视频信息远多于文字

命令行有着天生的优越性,图形界面的鼠标操作完全显得累赘

同时另一方面命令行却难以控制界面又显得苍白了太多

即便是掌握了多数常用的快捷键也难以足够高效

对于一个整天上网并且忙碌于控制各种信息的人来说

.不能获得快速的操作方式是非常纠结的一件事情

在思考当中我期待着命令行可以和图形界面深度的结合

.就像是语音搜索和移动平台漂亮的界面结合那样

显然,命令行更精确,能做更多的事情,效率更高

期间关注了Ubiquity和Vimperator这类在浏览器的实现

.从效果上说,功能实在不足以让人将日常的操作迁移上去

.总归是一个好的尝试,我期待这更多

所以我认为作者的方向与上文两个插件走在同方向不同的路上

最终也许图形与命令深入契合之后便利更加明显

.也有可能此类产品难以被普通用户接纳

有点像从js console里面直接抓去和操作界面元素的意思

我想那么的未来总是会被不同的各种创意实现

.最终图形和命令的合作亲密无间

youtube的搜索参数也有点这意思

我附上Ubiquity和Vimperator的视频吧

http://www.youtube.com/watch?v=r54O47ZR64A&hd=1

http://youtu.be/XI1XwdtmtQY?hd=1

It is pretty (and I want it for linux so I could use it!), but I think the real useful idea here is the separation of data out, and display out. If we could have that on a regular shell it would add a lot of usability. For this idea alone, my hat is off to you sir.

The problem with this fancy terminal is that the standardized tools, like cat and ls get abused in very bad ways...

What's the problem with ImageMagick's display for example? Or defining a new command that does pretty printing of images, like, say pls.

Don't fuck with our tool-chain buddy!^_^

Great. Looks awesome and is much needed.

It should be possible to map the output for the Current Working Host too.

So:

  home> ssh Server1
  Server1> ls
     server1file.bin

that

  server1file.bin

should be mapped to

  scp Server1:server1file.bin

I'm not sure what you mean. If you like, you can describe your idea in more detail and open an issue on github: https://github.com/unconed/TermKit/issues

The author talks about the hazards of parsing text streams, then talks about parsing ls, which is impossible to parse because there is no way of differentiating a newline in a filename from one that delimits the end of a line of output.

This is just fantastic. Great work. I look forward to see how it evolves further.

Amazing work. This kind of API has potential to be a real game changer. Imagine what this style interface could do for things like Image, Audio and Video processing. Can't wait to watch see this progress.

This will replace the terminal as much as the microwave replaced metal over fire for cooking or as much as synthesizers replaced real instruments in music.

Have you listened to the radio recently? ;)

Off and on in the car, but that's irrelevant. I'm not claiming every technology is irreplaceable, but that not all evolutions or supposed improvements of technologies REPLACE their predecessors.

Hmmmm. It's pretty, but sort of limited at the moment. I think it could be used sort of like training wheels for unix newbies.

OH MY GOD! THIS GUY WANTS ME TO CHANGE THE WAY I WORK!

I"VE BEEN WORKING THE SAME WAY FOR 20 YEARS

YOU CAN"T MAKE ME CHANGE!

CHANGE SCARES ME!

20 YEARS AGO MY TERMINAL DIDN"T HAVE LOWERCASE, COLOR, OR WINDOWS. WHY HE WANT ME TO CHANGE!!?!?

(Damn, I've never seen a group of people so change-adverse and closed minded about trying new things as the software developers that are in the business of making new stuff! Geeze! Download it and give it a try before you post a comment!)

Wow this is awesome. This project basically just showed me everything I never knew I wanted.

Awesome highly recommended Linux terminal, allows GUI splitting and has very almost 100% key-shortcut coverage: http://www.tenshu.net/terminator/

Inspiring! And gorgeous look and feel to the site.

More proof that people who don't understand UNIX are condemned to reinvent it, poorly.

People keep saying that, and then fail to tell me any solid reason why I'm wrong.

one word: genius!

it kind of defeats it's own purpose.

cat a.png -- show the image in a tiny terminal, but I have a billion pixel screen.

why not just open it on the image viewer window?

you advocate this even for editing plain text in vim!

think that if you had learned to use X your days would be more productive... maybe not as cool...

Reply on news.ycombinator.com