15 ms·

TermKit - a graphical terminal replacement

1056 points by pimeys 15y ago

chalst 15y ago
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.pdf http://www.deinprogramm.de/scheme-2005/05-knauel/05-knauel.p... I've not been able to build Termkit yet, mind.
- unconed 15y ago
  Shouldn't need to build it, there is a zipped .app included. You do have to build node.js though.
tezza 15y ago
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
- unconed 15y ago
  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 https://github.com/unconed/TermKit/issues
lut4rp 15y ago
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.)
wladimir 15y ago
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.
- bruceboughton 15y ago
  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?
  - wladimir 15y ago
    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...).
    - mikemaccana 15y ago
      Doesn't the article say it's TK? Which means it's already got X bindings.
      - deleted 15y ago
        [deleted]
      - unconed 15y ago
        TK just means TermKit, sorry.
      - adestefan 15y ago
        I believe TK stands for TermKit, not the tk widget set.
rrrazdan 15y ago
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.
- blackRust 15y ago
  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 http://i.imgur.com/jqIcv.jpg Also I mean as a hacker, not as an entrepreneur.
  - unconed 15y ago
    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.
    - henrikschroder 15y ago
      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.
AdamGibbins 15y ago
Awesome highly recommended Linux terminal, allows GUI splitting and has very almost 100% key-shortcut coverage: http://www.tenshu.net/terminator/ http://www.tenshu.net/terminator/
barrkel 15y ago
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.
- mikemaccana 15y ago
  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.
  - barrkel 15y ago
    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.
MatthewPhillips 15y ago
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.
- unconed 15y ago
  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.
sehugg 15y ago
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.
mhd 15y ago
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.
telemachos 15y ago
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 http://www.faqs.org/docs/artu/ch01s06.html [2] Cf. Ryan Tomayko's Shell Haters talk: http://shellhaters.heroku.com/ http://shellhaters.heroku.com/
- unconed 15y ago
  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.
hellweaver666 15y ago
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.
senthilnayagam 15y ago
awesome, my kids and the touch generation would now start using termkit as their terminal in this natural way
andrewcooke 15y ago
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 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?
- benatkin 15y ago
  Here's the link to the comments: http://news.ycombinator.com/item?id=2559361 http://news.ycombinator.com/item?id=2559361
skrebbel 15y ago
Only his response to the AVS question in http://acko.net/blog/on-termkit#comment-4240 http://acko.net/blog/on-termkit#comment-4240 made me realise exactly how powerful this premise is. TermKit could become my OS of choice.
balakk 15y ago
On windows have a look at http://poshconsole.codeplex.com/ http://poshconsole.codeplex.com/ Same idea, with powershell as the base.
- unconed 15y ago
  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.
- josephcooney 15y ago
  That's what I thought when I first saw TermKit too.
perlgeek 15y ago
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.
- djhworld 15y ago
  I think this guy should look into implementing something like this as a compromise.
  - wladimir 15y ago
    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.
- jrockway 15y ago
  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.
agentultra 15y ago
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.
bernardwilson 15y ago
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.
- tezza 15y ago
  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.
- wladimir 15y ago
  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). 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.
- burgerbrain 15y ago
  "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.
rglover 15y ago
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.
- adambyrtek 15y ago
  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.
sunkencity 15y ago
Inspiring! And gorgeous look and feel to the site.
StuffMaster 15y ago
>monospace text just doesn't cut it anymore Maybe in your terminal world, but not mine buddy.
- qjz 15y ago
  Seriously. But I wish all fonts included a monospaced variant. Why shouldn't I use Helvetica in my terminal?
  - romland 15y ago
    Did you even try to find it? Google "helvetica monospaced".
gurraman 15y ago
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/ http://ranger.nongnu.org/ [2] http://sup.rubyforge.org/ http://sup.rubyforge.org/
- beza1e1 15y ago
  "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/ http://notmuchmail.org/
  - carmen 15y ago
    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-your-IRC-logs-w/-examine http://blog.whats-your.name/post/2011/02/14/sifting-thru-you...
    - BCM43 15y ago
      That's something that they are working on. One example of a useful application is a text ebook collection.
- lallysingh 15y ago
  Either way, large experiments like this are a necessary part of the path there.
ZoFreX 15y ago
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 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 https://github.com/unconed/TermKit [2]: http://howtonode.org/how-to-install-nodejs http://howtonode.org/how-to-install-nodejs
- telemachos 15y ago
  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/ 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.
- scott_s 15y ago
  It is a pity, but it's completely understandable since this is one man's year-old hobby project.
- unconed 15y ago
  I don't mind, the project is in too rough a shape to interest anyone but hackers. Please come back in a month.
  - ZoFreX 15y ago
    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 :(
bmaeser 15y ago
one word: genius!
caf 15y ago
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?
- maratd 15y ago
  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.
- sehugg 15y ago
  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 ;)
swah 15y ago
Post about TermKit: http://axisofeval.blogspot.com/2011/05/termkit.html http://axisofeval.blogspot.com/2011/05/termkit.html
tvon 15y ago
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 http://www.xml.com/pub/a/2000/06/07/xmlterm/index.html Interesting to see someone pick this up again.
Symmetry 15y ago
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 http://en.wikipedia.org/wiki/Fish_shell
jorsh 15y ago
ls | grep js? really?
philjackson 15y ago
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.
- unconed 15y ago
  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 :).
CMay 15y ago
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.
tjarratt 15y ago
I really hope this guy gets hired by Apple. There are some really great ideas here.
moe 15y ago
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.
- unconed 15y ago
  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.
  - moe 15y ago
    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.
GrandMasterBirt 15y ago
Its good to see modern development in the terminal space. Sure it may be wrong what this guy implemented, but at least its some progress. Lets keep the ideas flowing.
mtogo 15y ago
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.
adnam 15y ago
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.
- unconed 15y ago
  You already trust the accuracy of your visualizers: your eyes. Is it space or a delimiter? Is that a quote or a backtick?
samlevine 15y ago
More proof that people who don't understand UNIX are condemned to reinvent it, poorly.
- unconed 15y ago
  People keep saying that, and then fail to tell me any solid reason why I'm wrong.
amosson 15y ago
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.
- william42 15y ago
  «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 http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
  - amosson 15y ago
    Here is Atwood's response http://www.codinghorror.com/blog/2008/03/revisiting-keyboard-vs-the-mouse-pt-1.html http://www.codinghorror.com/blog/2008/03/revisiting-keyboard...
jimmyjazz14 15y ago
"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.
- DanI-S 15y ago
  Text is a simple format, but text with intrinsic formatting is most definitely not a simple format.
  - jimmyjazz14 15y ago
    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.
Tycho 15y ago
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
- klochner 15y ago
  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/
- ak217 15y ago
  > 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.
bostonvaulter2 15y ago
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.
rbranson 15y ago
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.
- sehugg 15y ago
  Have you listened to the radio recently? ;)
  - rbranson 15y ago
    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.
swlkr 15y ago
Wow this is awesome. This project basically just showed me everything I never knew I wanted.
mixmastamyk 15y ago
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.
ChuckMcM 15y ago
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.
- ianb 15y ago
  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.
wickedchicken 15y ago
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.
- ernesth 15y ago
  Instead of 'cat image.png', if I want to see the image, I just 'image.png' (zsh's "alias -s" magic).
wooster 15y ago
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 http://www.userland.com/whatIsStopEnergy Kudos to unconed for doing something remarkable. I look forward to seeing where it goes from here.
- l3vitat3 15y ago
  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
  - Sudarshan 15y ago
    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...
  - adw 15y ago
    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.
TylerBrock 15y ago
This is amazing, it's like quicksilver and terminal and coda mashed together.
ianb 15y ago
I played around with what I think is a very similar idea a while back: https://github.com/ianb/jsshell 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.
mikey_p 15y ago
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 &.
- unconed 15y ago
  Added to my todo list. Thanks, didn't know about this one.
tlrobinson 15y ago
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.
dadro 15y ago
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.
risotto 15y ago
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!
technomancy 15y ago
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.
bdunbar 15y ago
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.
swift 15y ago
This is just fantastic. Great work. I look forward to see how it evolves further.
joe_the_user 15y ago
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.
blackman 15y ago
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.
yason 15y ago
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.
arnoooooo 15y ago
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.
JunkDNA 15y ago
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.
TomLimoncelli 15y ago
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!)
gcb 15y ago
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...
Rhapso 15y ago
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.
pnathan 15y ago
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.
planckscnst 15y ago
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.
boohiss420 15y ago
Why is the focus on the "terminal" as an application? This isn't about the terminal; it is about changing the convention by which many small programs interact with one another. To fetishize the "terminal" aspect of this is to ignore the fact that these tools are used most often in non-interactive ways. Should these tools use a different contract? Maybe. There have been much better thought out attempts to do so.
jesheit 15y ago
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.
ytart 15y ago
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!^_^
jiyinyiyong 15y ago
主意很棒,十分佩服作者所做的工作,之前我也有过类似的想法为了不说错太多,我不知道这里是不是允许用中文? . 图形化取得的成功有目共睹,而偏偏终端保持纯文本的简单从学习linux的经历和这么久接触互联网看 .个人用户接触到的图形视频信息远多于文字命令行有着天生的优越性,图形界面的鼠标操作完全显得累赘同时另一方面命令行却难以控制界面又显得苍白了太多即便是掌握了多数常用的快捷键也难以足够高效对于一个整天上网并且忙碌于控制各种信息的人来说 .不能获得快速的操作方式是非常纠结的一件事情 . 在思考当中我期待着命令行可以和图形界面深度的结合 .就像是语音搜索和移动平台漂亮的界面结合那样显然,命令行更精确,能做更多的事情,效率更高期间关注了Ubiquity和Vimperator这类在浏览器的实现 .从效果上说,功能实在不足以让人将日常的操作迁移上去 .总归是一个好的尝试,我期待这更多 . 所以我认为作者的方向与上文两个插件走在同方向不同的路上最终也许图形与命令深入契合之后便利更加明显 .也有可能此类产品难以被普通用户接纳有点像从js console里面直接抓去和操作界面元素的意思我想那么的未来总是会被不同的各种创意实现 .最终图形和命令的合作亲密无间 . youtube的搜索参数也有点这意思我附上Ubiquity和Vimperator的视频吧 http://www.youtube.com/watch?v=r54O47ZR64A&hd=1 http://www.youtube.com/watch?v=r54O47ZR64A&hd=1 http://youtu.be/XI1XwdtmtQY?hd=1 http://youtu.be/XI1XwdtmtQY?hd=1

1056 points by pimeys 15y ago

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.pdf http://www.deinprogramm.de/scheme-2005/05-knauel/05-knauel.p... I've not been able to build Termkit yet, mind.

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

tezza 15y ago

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

unconed 15y ago
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 https://github.com/unconed/TermKit/issues

lut4rp 15y ago

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

wladimir 15y ago

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.

bruceboughton 15y ago
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?
- wladimir 15y ago
  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...).
  - mikemaccana 15y ago
    Doesn't the article say it's TK? Which means it's already got X bindings.
    - deleted 15y ago
      [deleted]
    - unconed 15y ago
      TK just means TermKit, sorry.
    - adestefan 15y ago
      I believe TK stands for TermKit, not the tk widget set.

rrrazdan 15y ago

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.

blackRust 15y ago
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 http://i.imgur.com/jqIcv.jpg Also I mean as a hacker, not as an entrepreneur.
- unconed 15y ago
  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.
  - henrikschroder 15y ago
    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.

AdamGibbins 15y ago

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

barrkel 15y ago

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.

mikemaccana 15y ago
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.
- barrkel 15y ago
  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.

MatthewPhillips 15y ago

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.

unconed 15y ago
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.

sehugg 15y ago

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.

mhd 15y ago

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.

telemachos 15y ago

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 http://www.faqs.org/docs/artu/ch01s06.html [2] Cf. Ryan Tomayko's Shell Haters talk: http://shellhaters.heroku.com/ http://shellhaters.heroku.com/

unconed 15y ago
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.

hellweaver666 15y ago

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.

senthilnayagam 15y ago

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

andrewcooke 15y ago

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 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?

benatkin 15y ago
Here's the link to the comments: http://news.ycombinator.com/item?id=2559361 http://news.ycombinator.com/item?id=2559361

skrebbel 15y ago

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

balakk 15y ago

On windows have a look at http://poshconsole.codeplex.com/ http://poshconsole.codeplex.com/ Same idea, with powershell as the base.

unconed 15y ago
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.
josephcooney 15y ago
That's what I thought when I first saw TermKit too.

perlgeek 15y ago

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.

djhworld 15y ago
I think this guy should look into implementing something like this as a compromise.
- wladimir 15y ago
  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.
jrockway 15y ago
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.

agentultra 15y ago

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.

bernardwilson 15y ago

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.

tezza 15y ago
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.
wladimir 15y ago
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). 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.
burgerbrain 15y ago
"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.

rglover 15y ago

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.

adambyrtek 15y ago
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.

sunkencity 15y ago

Inspiring! And gorgeous look and feel to the site.

StuffMaster 15y ago

>monospace text just doesn't cut it anymore Maybe in your terminal world, but not mine buddy.

qjz 15y ago
Seriously. But I wish all fonts included a monospaced variant. Why shouldn't I use Helvetica in my terminal?
- romland 15y ago
  Did you even try to find it? Google "helvetica monospaced".

gurraman 15y ago

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/ http://ranger.nongnu.org/ [2] http://sup.rubyforge.org/ http://sup.rubyforge.org/

beza1e1 15y ago
"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/ http://notmuchmail.org/
- carmen 15y ago
  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-your-IRC-logs-w/-examine http://blog.whats-your.name/post/2011/02/14/sifting-thru-you...
  - BCM43 15y ago
    That's something that they are working on. One example of a useful application is a text ebook collection.
lallysingh 15y ago
Either way, large experiments like this are a necessary part of the path there.

ZoFreX 15y ago

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 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 https://github.com/unconed/TermKit [2]: http://howtonode.org/how-to-install-nodejs http://howtonode.org/how-to-install-nodejs

telemachos 15y ago
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/ 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.
scott_s 15y ago
It is a pity, but it's completely understandable since this is one man's year-old hobby project.
unconed 15y ago
I don't mind, the project is in too rough a shape to interest anyone but hackers. Please come back in a month.
- ZoFreX 15y ago
  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 :(

bmaeser 15y ago

one word: genius!

caf 15y ago

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?

maratd 15y ago
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.
sehugg 15y ago
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 ;)

swah 15y ago

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

tvon 15y ago

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 http://www.xml.com/pub/a/2000/06/07/xmlterm/index.html Interesting to see someone pick this up again.

Symmetry 15y ago

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 http://en.wikipedia.org/wiki/Fish_shell

jorsh 15y ago

ls | grep js? really?

philjackson 15y ago

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.

unconed 15y ago
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 :).

CMay 15y ago

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.

tjarratt 15y ago

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

moe 15y ago

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.

unconed 15y ago
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.
- moe 15y ago
  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.

GrandMasterBirt 15y ago

Its good to see modern development in the terminal space. Sure it may be wrong what this guy implemented, but at least its some progress. Lets keep the ideas flowing.

mtogo 15y ago

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.

adnam 15y ago

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.

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

samlevine 15y ago

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

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

amosson 15y ago

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.

william42 15y ago
«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 http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
- amosson 15y ago
  Here is Atwood's response http://www.codinghorror.com/blog/2008/03/revisiting-keyboard-vs-the-mouse-pt-1.html http://www.codinghorror.com/blog/2008/03/revisiting-keyboard...

jimmyjazz14 15y ago

"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.

DanI-S 15y ago
Text is a simple format, but text with intrinsic formatting is most definitely not a simple format.
- jimmyjazz14 15y ago
  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.

Tycho 15y ago

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

klochner 15y ago
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/
ak217 15y ago
> 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.

bostonvaulter2 15y ago

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.

rbranson 15y ago

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.

sehugg 15y ago
Have you listened to the radio recently? ;)
- rbranson 15y ago
  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.

swlkr 15y ago

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

mixmastamyk 15y ago

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.

ChuckMcM 15y ago

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.

ianb 15y ago
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.

wickedchicken 15y ago

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.

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

wooster 15y ago

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 http://www.userland.com/whatIsStopEnergy Kudos to unconed for doing something remarkable. I look forward to seeing where it goes from here.

l3vitat3 15y ago
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
- Sudarshan 15y ago
  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...
- adw 15y ago
  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.

TylerBrock 15y ago

This is amazing, it's like quicksilver and terminal and coda mashed together.

ianb 15y ago

I played around with what I think is a very similar idea a while back: https://github.com/ianb/jsshell 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.

mikey_p 15y ago

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 &.

unconed 15y ago
Added to my todo list. Thanks, didn't know about this one.

tlrobinson 15y ago

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.

dadro 15y ago

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.

risotto 15y ago

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!

technomancy 15y ago

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.

bdunbar 15y ago

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.

swift 15y ago

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

joe_the_user 15y ago

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.

blackman 15y ago

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.

yason 15y ago

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.

arnoooooo 15y ago

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.

JunkDNA 15y ago

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.

TomLimoncelli 15y ago

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

gcb 15y ago

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...

Rhapso 15y ago

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.

pnathan 15y ago

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.

planckscnst 15y ago

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.

boohiss420 15y ago

Why is the focus on the "terminal" as an application? This isn't about the terminal; it is about changing the convention by which many small programs interact with one another. To fetishize the "terminal" aspect of this is to ignore the fact that these tools are used most often in non-interactive ways. Should these tools use a different contract? Maybe. There have been much better thought out attempts to do so.

jesheit 15y ago

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.

ytart 15y ago

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!^_^

jiyinyiyong 15y ago

主意很棒,十分佩服作者所做的工作,之前我也有过类似的想法为了不说错太多,我不知道这里是不是允许用中文? . 图形化取得的成功有目共睹,而偏偏终端保持纯文本的简单从学习linux的经历和这么久接触互联网看 .个人用户接触到的图形视频信息远多于文字命令行有着天生的优越性,图形界面的鼠标操作完全显得累赘同时另一方面命令行却难以控制界面又显得苍白了太多即便是掌握了多数常用的快捷键也难以足够高效对于一个整天上网并且忙碌于控制各种信息的人来说 .不能获得快速的操作方式是非常纠结的一件事情 . 在思考当中我期待着命令行可以和图形界面深度的结合 .就像是语音搜索和移动平台漂亮的界面结合那样显然,命令行更精确,能做更多的事情,效率更高期间关注了Ubiquity和Vimperator这类在浏览器的实现 .从效果上说,功能实在不足以让人将日常的操作迁移上去 .总归是一个好的尝试,我期待这更多 . 所以我认为作者的方向与上文两个插件走在同方向不同的路上最终也许图形与命令深入契合之后便利更加明显 .也有可能此类产品难以被普通用户接纳有点像从js console里面直接抓去和操作界面元素的意思我想那么的未来总是会被不同的各种创意实现 .最终图形和命令的合作亲密无间 . youtube的搜索参数也有点这意思我附上Ubiquity和Vimperator的视频吧 http://www.youtube.com/watch?v=r54O47ZR64A&hd=1 http://www.youtube.com/watch?v=r54O47ZR64A&hd=1 http://youtu.be/XI1XwdtmtQY?hd=1 http://youtu.be/XI1XwdtmtQY?hd=1