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.)
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?
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.
I think my point is that we've all been so locked into these tools that we've become blind as to where their failing are. I wanted to start TermKit from a fresh slate and only slowly add bits of existing Unix to it, so I could make sure the resulting whole still made sense.
For me, as someone that does all his work in Windows and stays away from consoles as much as possible, this entire discussion is hilarious.
I think your project is cool, it certainly is a fresh take on the console, but the minority of people that like the unix console will be very resistant to anything graphical, and the majority of people that prefer graphical interfaces will just wonder why the hell you still need to do all of that typing. :-)
The fundamental problem with consoles is that it's impossible to explore the interface. You can only use it by knowing the possible commands beforehand.
Hmm.. Perhaps that's something you could explore with Termkit? With the added graphical output, is it possible to show hints for what I can/want to do, given what I've already typed? I dunno, just an idea.
The power is in knowing the shell. You can do things quickly and do exactly what you want if you know how to use it. No GUI can give you with the same speed and efficiency.
The learning curve is steep, I like your suggestion of 'exploring' the interface. I think this deserves more merit than making the shell glossy.
It's funny, his 'ls' by default prints out an information-sparse grid of icons (only showing 10 items with a horizontal scrollbar?), whereas when I use the command-line, I'm looking for exactly the opposite of a GUI - an information-dense table of text. I agree with the commenter that -r-xr-xr-x - or even 0555 - is far better than "you can't touch this" (which doesn't describe who can't touch it, and in what ways). His "rich display" is actually a display of poverty - it conveys less information than text.
The typing of file / stream data is interesting, but I don't think it's realistic - it requires all tools to change virtually overnight to preserve the headers. And it's not enough just to preserve headers; what if you pump stuff out to a temporary file and read it in a few milliseconds later? What about compound files, with data chopped out of them? If you want pretty pictures, syntax highlighting etc., ISTM better to have an enriched terminal communication protocol along with a couple of viewer programs which can render data formats to it, rather than change the whole world to type every data flow everywhere.
On the other hand, ls isn't showing you the file type, and will never show you content. And you're mixing presentation with content, which is poor engineering - see the guys coming up with regexs to handle time because the only way time is presented to them is as text,
Good shells have prompted object pipeline based tools before - PoSH is only a few years old. And it's still possible for older tools to run with no degradation in quality from their previous environments.
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.
On the other hand, imagine being able to 'jump' into the output with a cursor, hit enter and open any file, or hit delete, or F2 to rename etc. From a UI point of view, it could be great (notwithstanding my other comments).
> 'His "rich display" is actually a display of poverty'
Presumably the "view" for `ls` will be configurable, so this is not an important issue. The worrying part for me is that it's another of layer of separation between me and my data.
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.
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.
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.
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?)
- Monospace fonts for code is definitely in. Try catting a .js file, it will get syntax highlighted. Most likely, it doesn't recognize the mime type of your file. It's using the old mime.types DB + some custom additions... also, the highlighter I'm using only has so many languages defined. I looked for the most comprehensive / least fail one.
- Regarding vim... I admit I just don't like those tools. I can operate vim just fine, but I hate every second of it. I would much rather be able to type "edit file", have it open up the file in my local editor, and sync back saved changes.
- No scripting language... except the whole thing is built on Node.js... :) What's not discussed in the article is that the UI is not tied to the shell at all. You can just as easily make a back-end worker for SQL, for SFTP, for a scripting console, etc. I haven't worked out how this works in the UI, but the protocol supports it. Session types can be multiplexed freely over one socket. Basically, for scripting, I think the command line is a shitty place for it, and we should just switch to using a real language in its own little console when needed.
- Regarding habits... it's not my goal to break any without reason, just to reduce the number of keystrokes. Consider it a bug. Regarding quotes... the idea is WYSIWYG. If there is a visual divider, it's a separate argument. Otherwise, it gets passed as a single unit. This may sometimes be buggy, the Unix command support is 1 week old, and I hack on this very late at night.
And on another note... it's been hilarious how people have been questioning my professional credentials just because I want to make something more usable.
I've implemented over a dozen RFCs, can match regexps with the best of them and do know which end of a pipe does what ;).
I'm also a bit disappointed on how most people here react. I personally think your idea is great and pretty futuristic. I would certainly use a tool like this. Also it's open source so if a specific detail (such as the font) bugs them it can simply be changed.
I've had similar ideas (based on Python) but never got around to executing them. Keep up the good work and don't let the angry bearded UNIX dinosaurs get to you :)
Absolutely! Don't lose that attitude. You won't win over everyone and the fact that anyone cares enough about something you made to share their opinion with you is awesome.
Bingo. If you haven't pissed anyone off, it's because you're not doing anything important. There are people who invested DECADES of their life into a vanilla terminal ... and here you are, fucking with THAT.
the only thing that pisses me off is the guy posting how many years he was administering UNIX systems and how this monster was an "obvious" step in the field, web designers are quite arrogant
Regarding your quote problem: the idea is that the highlighted token signifies "quoted string". I plan to add regexp tokens, user@host tokens, etc. each with appropriate autocomplete.
I thought the current minimalistic approach was ok, but it might be worth to add subtle quotes around the edges to reinforce the idea. That's why it's made out of HTML/CSS...
The token idea is genius. This could be applied to programming languages as well. Why settle with crazy delimiters like ',"; /xxx/ and manual escaping with \n \x \\\\\\ (making a \ in a regexp in a string :P). A subtle visual hint could be enough to distinguish different kinds of textual "object".
Sure, not everyone will like this, but for people that are visually oriented like me it will make things a lot of fun.
I agree. I haven't actually tried your terminal, but so far it looks very nice.
Considering that when the interface for the terminal was created it was all about being able to do everything and anything without breaking a sweat. Simple things like automatic source code highlighting, animated progress bars, being able to view (now common) files like pdf and jpeg that were not common back in the old days. Popup tab complete, I can't believe that that isn't standard on all terminals already (especially since tab complete is all about being lazy, a popup makes a lot of sense).
I'll download the source and poke around it later this evening (right now I need to work on my exam of implementing the go-back-n protocol).
Cheers and keep up the good work.
PS: RDF support would be great (since you have json). RDF is the standard for sharing data (often statistics) openly online, check out http://data.gov.uk/linked-data
It's not futuristic, it's retro. I've seen three or four of these be announced with great fanfare, and then dropped. No one cares enough, the backwards compatibility is never good enough, and it's almost certainly too slow.
that webkit will render faster than a terminal emulator is just pure fantasy, is like saying that a smart phone with all the fancy apps will eventually use less power than a solar powered calculator. you ppl are addicted to osx overdesign. no graphical user interface will beat a keyboard in the right hands, like it or not. pure fantasy, hipster hackers
What was the last time you had any problems with the rendering speed of Webkit in reality? Have you tried the other link in HN, that boots Linux in your browser, with a terminal app, and it still manages to be fast even on my modest system?
Have you looked at some WebGL / Canvas based demos lately? There are now very efficient GPU offloaded rendering APIs that make rendering graphics a breeze, it is no longer a big-overhead thing. If you don't use fancy graphics you're underutilizing your GPU.
[also, TermKit is not just about fancy graphics, but also about user friendlyness/usefullness for some tasks that are not very well handled in terminals otherwise]
It is amusing how we hackers, who are supposed to embrace change, become as Luddite as anyone else when our sacred tools are questioned. Personally I see room for this and a whole lot more. I'd like to see an amalgam of this and the traditional terminal (easy way to pull up a traditional terminal if you need it). There is no need to "replace"; I think this makes a fine addition to a hackers workspace.
Thing is, it's not about the tools being sacred. My problem with this is that he's not just solving problems I don't have -- he's solving them in a way that would make my problems worse!
For instance, I very rarely want more informations about the files from an "ls" command; and if I did, I'd probably use Finder instead. On the other hand, not having enough terminal real estate to display the entire directory at once is a very frequent problem. From that perspective, adding icons is a step in the wrong direction.
Thinking about it, if I were playing with making a better terminal, one of my first lines of thought would be things that made it quick and easy to break information out into other windows, because scrolling back and forth in the terminal's buffer is a PITA.
Of course, this new terminal might be exactly what the author needs, and more power to him if it is. There's no need for us all to use the same tools. (Thanks heavens -- I want nothing to do with Emacs or vi!)
Regarding the too-small windows for ls output option I would love if his ls could display it's output full-screen temporarily rather than needing to make the terminal full-screen first and then running ls
See, here's the thing: I like Finder. It's not perfect, but sometimes it is very handy. Even if TermKit ends up implementing the complete functionality of Finder, I'm not sure why I'd particularly like to have that functionality in my terminal window. And if it's only implementing the one Finder view I virtually never use? Forget about it.
You know what would rock my world? A "lsf" command that emulated "ls" as much as possible, but launched a Finder window appropriately sized to display the results.
I've always thought Raskin's ZUI held some promise as an alternative UI paradigm. I'm pretty much a quicksilver addict now and use that to kind of combine the command line and GUI desktop worlds a little bit more at least.
Really? I see the same thing whenever you get a bunch of professionals together and start arguing about their tools.
Doctors and different drugs/treatments, Contractors and brands of power tools.
Programmers do seem to make the biggest deal about "all the fighting", everyone else seems to just accept that professionals are opinionated and arguing is how progress is made. But I'm on the inside with the programming stuff and on the outside looking in for the rest of these fields so maybe that's not true.
Doctors and different drugs/treatments, Contractors and brands of power tools.
From what I've seen, smart Doctors and Contractors eventually get to discussing empirical data and costs. Far too often, I've seen programmers just make up crap and state it emphatically.
Very good point. Do doctors and contractors have more sources of empirical data (or more widely known sources), or are they simply more willing to look for them? Does anyone here know of a good general resource for empirical data regarding the tools we are constantly debating?
Do doctors and contractors have more sources of empirical data (or more widely known sources), or are they simply more willing to look for them?
I think the culture would be a vital part of an ecosystem of empirical observation. For the sciences generally, the culture predated the sources and gave rise to them. For medicine, I think a culture of empiricism was imported from other scientific fields. For contractors, they are very motivated to note what works, what breaks, and what enables them to make more money.
I actually built in anonymous usage logging into TermKit using Google Analytics over SSL. It logs the types of commands you execute (no data). It's my plan to release this data back to the community regularly. I don't think anyone has done a large-scale survey of command-line unix usage before. Should be interesting.
Bloomberg found the same thing when they tried to redesign their terminals for traders - existing users were so invested in their knowledge of the "incantations" of the old interface that they were hugely resistant to a UI with a more modern learning curve and interaction.
It's very hard to make a product that essentially devalues things that your customers spent a lot of time learning. You're probably better off ignoring people who already happy with their shell experience, and going after people who have not yet invested in learning all that crap.
And yes, it's crap. And I say that not because I don't know it myself, but because in the end, much of it is not essential to the actual job we're trying to get done, it's the tools we use. And the tools are not the job.
The thing about changes involving a "more modern learning curve and interaction" is that it's replacing something that already worked and users knew how to use.
I'm quite bad for upgrading for upgrading's sake but I can understand why, of all people, traders at Bloomberg didn't want any kind of learning curve on their terminals.
Yes, it's clearly better but users don't always want to change to something that does what they already do in a more modern way.
That doesn't mean you have to stop innovating. It just means that your customers might not be the people who are already using what you want to replace.
It's just my point of view, I don't really like the stance seem to take here.
You built something great, made it open source, which is even more great, and you're here to answer people, which is amazing. Now, please don't act like "I implemented x RFCs, I can do y like the best...", it's simply useless here.
One reason is that people already know you can code well, and they can even read your source if they want to know better, there's no need to brag.
Another reason is that HN is the place of some very good developers, and I believe humility is appreciated here, at least until you build some life changing software (and I won't debate about what is or is not life changing).
Anyways, thanks for building this and releasing the source code as open, it's cool.
I love the idea. But as someone who also loves vim, to hear that your vision of a new terminal excludes a tool as powerful and expressive as vim makes me sad, because it means that apparently I won't be able to benefit from this new terminal. I'll watch with interest, however.
The file I was trying to cat is group_add.sh. I understand if syntax highlighting isn't done for shell files, but I'm surprised that '.sh' doesn't trigger monospace fonts. That said, I'm glad to hear that in general monospace for code is the plan.
We can agree to disagree about Vim and shell scripting. I use those both, all day and every day. Tastes vary. That's fine.
I really wish you would reconsider the single quoting/WYSIWYG/visual divider business. It's extremely jarring to see awk (or sed, etc.) without those single quotes.
Doubting your credentials on the basis of this is silly, and will probably be the minority reaction in the long run. I would be surprised if you don't get offered a few jobs as the result of making TermKit.
While, I understand your dislike of Vim, Vi, Nano, Emacs, etc. (I can't work in them for extend periods of time either do to hand problems) They remain essential tools for many programmers and system administrators. Sometimes, you don't want to have the file pulled down and edited in a local edit and pushed back even if it is seamless. The benefits of inplace editing on remote machines is invaluable.
I think this is a cool idea. I think it needs to be cross platform. However, it must be fully backwards compatible with the full unix toolchain to be useful. If it isn't I can't use it, and a lot of other potential users will also be unable to use it.
I love the idea thanks for rethinking the terminal.
There is potential for TermKit to send files to your client's Vim, which opens a lot of possibilities. For example, it would be easy to have files from two different servers open. It would also reduce the number of places you need your configuration files.
TermKit's author may dislike Vim, but I suspect that he's helped its users in the long run.
vim (and other editors) have lockfiles, recovery files in case of session crashes, and assume directory locality (e.g., oops I opened the wrong file; :r filename).
> Sometimes, you don't want to have the file pulled down and edited in a local edit and pushed back even if it is seamless. The benefits of inplace editing on remote machines is invaluable.
The benefits of having your vim settings whenever you type 'vim' rather than whatever's on the server is invaluable, too. It's not an easy task to satisfy everyone, and I wouldn't expect TermKit too; nevertheless I'm excited to see how it develops.
If it's a server I plan on logging into more than once or twice, it's easy enough to pull down my git-managed dotfiles and have everything I come to expect.
It seems like TermKit could handle curses applications fairly straightforwardly and without modifying those applications. Just set TERM=xterm, and when you see the xterm initialization string, either open a new tab or define a region in the existing tab, and emulate an xterm within that region. (If you use a region in the existing tab, it could have a control attached to it that splits that region out into a new tab.) That would allow existing programs like vim, htop, powertop, and mutt to work perfectly within your terminal.
Personally, I'd like to use this like an enhanced standard terminal. So, for instance, I'd like to have the standard ls output rather than something graphical, but I'd like the filenames in the ls output to act as links, so I can click to open or hover for a preview. And while I want the standard cat command, I'd also like to have the command that displays something inline in the terminal (with the above-mentioned control to move it to a new tab).
Where I work, everybody has linux development machines, but use their machine of choice as their actual workstation. This either forces people to use vim/emacs through SSH, or set up some local file sharing so that they can use their bloated eclipse thing.
Personally, I've spent months each with a few of the popular editors around, and I fall back on vim just because my .vimrc has been tuned so much over the past few years that it's just painful to use anything else. I don't even care if the editors have more features.
Now, if I had a fancier terminal, where my mouse click picked the right vim split view instance, or highlighting text in a split view vim selected only text in that window, instead of the whole line of the terminal, I would use that. MacVim is pretty much the perfect tool for me, but it's local and not remote (and also not inside a terminal that I can split up with screen).
> highlighting text in a split view vim selected only text in that window
Try to control-select in the terminal. Works with my Gnome term 2.
> vim/emacs through SSH
We work like that too, and I see only advantages to this set-up, the least being forcing everyone to learn find, grep, vim. These powerful tools increase productivity but have a high barrier of entry, so best is to have no other choice.
> I'd like to use this like an enhanced standard terminal
Same here. Just adding a tiny little bit of enhancement without changing anything in the standard behavior could be a bettter idea. Examples:
- ls output is pure text but hoverable (parent's idea)
- add a way to see thumbnails of pics in ls
- drag and drop files in the pwd
In the article the author says "The interaction is strictly limited to a linear flow of keystrokes, always directed at only one process" and take it as a limitation. From my point of view, when doing geek work on big machines, I need to drive a "linear flow of keystroke" in the machine. It is the way to have a deterministic behavior. It is the way to be able to script my work. I feel empowered by the control I have on what the machine does. Everything else (ie Windows, Mac UI) feel like a console game to me, in the sense that I give away my full control on the machine in exchange of impressive graphics, ease of interaction and safety-for-kids.
Regarding liking vim, I have no issue with typing "edit foobar.txt" and having a local MacVim open up :)
Most of what TermKit is doing doesn't immediately appeal to me (as a longtime shell junkie of sorts), but one thing I would love to have in a terminal is tooltips, or popups of some sort. For example, say I get a 40 line stack trace, I'd like to just see one line (the exception, where it was thrown from) but have the option to learn more by clicking on a line in the terminal. Basically how exceptions are reported in the browser in Django or Rails, but in the terminal.
> - No scripting language... except the whole thing is built on Node.js... :) [...] Basically, for scripting, I think the command line is a shitty place for it, and we should just switch to using a real language in its own little console when needed.
I could see this being done well-- it's not hard to beat bash for syntax and functionality-- but I could also see it being done poorly or considered an ancillary feature.
Shell scripting sucks, but it's the only language I know that lets me write tiny little scripts in not minutes but seconds, inline, without breaking out of the flow. Just like dynamic versus static languages, the quantitative difference in writing speed is enough to make a qualitative difference in the types of programs that can be written; and the difference between a non-scriptable shell and a scriptable one is like the difference between a GUI and a good CLI.
A large part of that scriptability is just grep and sed and friends, which TermKit apparently does support, but sometimes bash's loop structures are also required...
That's all fine. There's probably a ton of other things it can't do. I certainly can't use it for my work and I spend a ton of time behind a terminal. At the same time, don't you see the potential?
It probably won't be "production ready" for years, but I would hate to think that 20 years from now we're still typing into a dinky terminal that has been around since the 70s! We won't get the next-best-thing down the road unless we start working on it now. TermKit is the first step.
It's a first step. Maybe it's not in the right direction, maybe it is, but it looks well-polished, and like good work. My instinctive reaction was not a positive one, but the more I read, the more I liked it, and you have to applaud a good effort like this in any event. People have to get out there and try for things to improve.
it's curious this is on the front page at the same time as oh (or was that on reddit? - can't seem to find it now). https://github.com/michaelmacinnis/oh
both allow the shell to use structured data. i like the idea of using json myself (not that keen on the gui parts of the implementation, but moving pipes to something with more structure seems like a good idea). did plan 9 do anything similar?
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.
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.
No, he shouldn't be making compromises at all. He's rightfully aiming at making the shell of the future. Features to comfort people that are stuck in their current ways can easily be backported in later, as we know how they work since the 70's.
I agree. I think it can be easily implemented as a slight modification to a standard terminal: bind some UNIX socket, announce the address in an environment variable, and then accept connections and commands from applications that are interested in enhancing their output.
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.
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).
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.
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.
"I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!"
Improve it all you want, I'm totally into that. The problem is that once your "terminal" ceases to be a terminal emulator then you lose so much it's pretty unrecoverable.
Most of the things that you suggest are very much technically possible for a shell (perhaps zsh with some extensions) running in xterm. You'd be left with some sort of unholy combination of a rather modernized `mc` and an otherwise modern shell, but it'd be a very interesting product.
tl;dr: We're not opposed to improving the 'terminal'. I'm opposed to 1) mistaking "improving the terminal" with "improving the shell" and 2) losing the terminal.
A terminal emulator running on an object-oriented system like Termkit could run vt100-friendly filters to convert everything to text before it is sent down the line to the user. Users who did not know they were connecting to such a system might not notice the difference.
Although I am not entirely sure what you are attempting to communicate, what I will say is this:
If you do not provide direct user access to a pseudo terminal through a terminal emulator, then you will undoubtedly lose functionality. You need both the pseudo-terminal and the terminal emulator. If you do provide direct user access to the pty through a terminal emulator, then what the hell is the rest of the crap there for?
> Wouldn't it be nice to show the intended completions in a popup as you're typing (like web browsers do)?
This can probably be written as an extension to bash/tcsh/zsh to use the pop-up completion facilities of vim. If you want nice webapp-looking ones, you might be able to get away with terminal escape codes and use a perl script (this is how rxvt lets you click on http links automatically).
> can the result not be folded into a single line showing the summary, that I could expand if I wished?
An interesting point, and I was going to counter with a small one-liner using 'tee,' but I couldn't think of a good one quickly that does what you really want: 'auto-collapse.' The problem with this is that often with giant lines of output you really only want to look at the last few to see what happened. Otherwise your output is typically some kind of streaming log (you do not want auto-collapse for this) or a poorly written program. "walls of text" suck and are usually an indication of something you expect to have a lot of output (looooong makefile) and can do a less accordingly, or an unexpected error. If it's an error you want to see what it is, so you're going to click on the 'expand' button -- an extra click every time on an all-typing interface kind of sucks.
Ditto to that. I admit predisposition to liking Termkit because I also had a similar idea in the past and I had neither the time nor talent to go anywhere with it. Kudos to this guy for producing something that looks like a very large step in the direction of improved usability and a potential step towards improved performance if programs can be made to pass each other common structures without needing to serialize and reparse the data until it needs to be seen by a user.
In addition to the frontend and pipe changes, I also imagined changing the way files are accessed. Some subsystem could put indexes and attributes on certain data files so you could run something like:
and you would get the desired set of information without needing to write potentially buggy regex scripts. If there was a new type of file that you wanted to get data from in a few different ways, you could write only one buggy regex script to use as a filter and then query the file with the shell's normal query methods to pull down any information you might need. In the example of pulling users from a file, the shell could know from the attribute metadata that you are looking at a list of users and it could show the results as widgets that you could right-click to get the user's properties.
This all implies rewriting every utility in the system to accept recordsets instead of text, adding custom code for every different targeted data file, and making sure it all works with existing tools that have not been converted yet. That could be difficult, or at least time-consuming.
man, if you had to operate daily hundreds of files you will forget quickly about drag'n'dropping, scrollbars and all that annoyances. about the popup is useless on a keyboard controlled interface as the number of keystrokes needed are the same. the problem you have, is that you think that your terminal application is badly-glued into your graphic system, when in fact your graphic system is badly-glued on terminal applications
As a UI designer, even though I've just begun working with terminal, I can't say I like this too much. Don't get me wrong, it looks GREAT, but much as I expected, it goes against a lot of ideas and based on some of the comments, strips a bit of functionaity (a huge no no). I think Steven's intentions are solid, but he's sort of playing with fire on this one. Cool idea, though.
Of course he is playing with fire, that's the only way to do real innovation. Remember that this is just a proof of concept, and a very compelling one.
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.
"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."
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?
It's a pity that this is so difficult to try. The blog post has so much detail and effort put into it, but all that shine and polish disappears when you try to install it.
Specifically Step 1 of the instructions[1] has a link titled "install node and npm" [2] which has the line 'git clone git://github.com/ry/node.git', which is incorrect. The correct URL (as far as I can tell) would be 'git://github.com/joyent/node.git'.
In addition the linked instructions say nothing of npm, which can be installed quite easily by running 'curl http://npmjs.org/install.sh | sh' as root.
Back to the TermKit instructions again, and step 5 says 'git clone git@github.com:unconed/TermKit.git --recursive', which didn't work for me. What worked was 'git clone git://github.com/unconed/TermKit.git --recursive'.
Finally after all that, I just see 'You cannot use this version of the application TermKit.app with this version of Mac OS X.'. Would have been nice to mention that at the start.
Fyi, I think the current recommendation is to install both node and npm as a regular user.
I generally follow the pattern described here for node: http://blog.nodejs.org/2011/04/04/development-environment/. If you do that, and then install npm as you describe (but as a regular user), then npm will automatically be installed under the node installation.
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 :(
207 comments
[ 3.2 ms ] story [ 244 ms ] threadI've not been able to build Termkit yet, mind.
It should be possible to map the output for the Current Working Host too.
So:
that should be mapped to(P.S. - Apart from this, unconed has also been a prolific Drupal contributor and done some amazing visualization work for Winamp. Awesome hacker.)
Too bad it's very much bound to MacOSX/Cocoa, so this kind of rules it out as general nextgen UNIX/Linux shell.
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...).
Reminds me of this: http://i.imgur.com/jqIcv.jpg
Also I mean as a hacker, not as an entrepreneur.
I think your project is cool, it certainly is a fresh take on the console, but the minority of people that like the unix console will be very resistant to anything graphical, and the majority of people that prefer graphical interfaces will just wonder why the hell you still need to do all of that typing. :-)
The fundamental problem with consoles is that it's impossible to explore the interface. You can only use it by knowing the possible commands beforehand.
Hmm.. Perhaps that's something you could explore with Termkit? With the added graphical output, is it possible to show hints for what I can/want to do, given what I've already typed? I dunno, just an idea.
The learning curve is steep, I like your suggestion of 'exploring' the interface. I think this deserves more merit than making the shell glossy.
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.
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.
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.
Presumably the "view" for `ls` will be configurable, so this is not an important issue. The worrying part for me is that it's another of layer of separation between me and my data.
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.
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.
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.
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:
TermKit doesn't echo the single quotes. That is, you can type them, but they don't show up on the screen. I'm not really sure what to do with that. Does that mean I should stop typing them? Does that mean that I still must type them, but TermKit strips them because they aren't pretty? Does TermKit allow me to do it either way? I'm going to need to remember how to quote things when I log into a remote machine over ssh, so if TermKit will force me to change habits, that's a big, big problem. (After a few experiments, it seems like the single quotes are still required. Without them, TermKit tokenizes the stream differently. If that's the case, why refuse to echo them to the screen?)[1] http://www.faqs.org/docs/artu/ch01s06.html
[2] Cf. Ryan Tomayko's Shell Haters talk: http://shellhaters.heroku.com/
- 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.
I've implemented over a dozen RFCs, can match regexps with the best of them and do know which end of a pipe does what ;).
I've had similar ideas (based on Python) but never got around to executing them. Keep up the good work and don't let the angry bearded UNIX dinosaurs get to you :)
Who cares what people on the internet say, they're the ones wasting their time posting it.
I thought the current minimalistic approach was ok, but it might be worth to add subtle quotes around the edges to reinforce the idea. That's why it's made out of HTML/CSS...
Sure, not everyone will like this, but for people that are visually oriented like me it will make things a lot of fun.
Considering that when the interface for the terminal was created it was all about being able to do everything and anything without breaking a sweat. Simple things like automatic source code highlighting, animated progress bars, being able to view (now common) files like pdf and jpeg that were not common back in the old days. Popup tab complete, I can't believe that that isn't standard on all terminals already (especially since tab complete is all about being lazy, a popup makes a lot of sense).
I'll download the source and poke around it later this evening (right now I need to work on my exam of implementing the go-back-n protocol).
Cheers and keep up the good work.
PS: RDF support would be great (since you have json). RDF is the standard for sharing data (often statistics) openly online, check out http://data.gov.uk/linked-data
About caring enough, yeah, that depends, maybe the world is ready for this now :) At least it isn't some overengineered XML grotesquery this time.
Have you looked at some WebGL / Canvas based demos lately? There are now very efficient GPU offloaded rendering APIs that make rendering graphics a breeze, it is no longer a big-overhead thing. If you don't use fancy graphics you're underutilizing your GPU.
[also, TermKit is not just about fancy graphics, but also about user friendlyness/usefullness for some tasks that are not very well handled in terminals otherwise]
For instance, I very rarely want more informations about the files from an "ls" command; and if I did, I'd probably use Finder instead. On the other hand, not having enough terminal real estate to display the entire directory at once is a very frequent problem. From that perspective, adding icons is a step in the wrong direction.
Thinking about it, if I were playing with making a better terminal, one of my first lines of thought would be things that made it quick and easy to break information out into other windows, because scrolling back and forth in the terminal's buffer is a PITA.
Of course, this new terminal might be exactly what the author needs, and more power to him if it is. There's no need for us all to use the same tools. (Thanks heavens -- I want nothing to do with Emacs or vi!)
The thing that strikes me as very, very cool about this project is that you might not need the Finder at all any more.
You know what would rock my world? A "lsf" command that emulated "ls" as much as possible, but launched a Finder window appropriately sized to display the results.
As for why? Because it will be optimized for keyboard interaction and rapid context switching.
In my experience, programmers as a whole are actually more luddite and irrationally reactionary than the general populace.
Doctors and different drugs/treatments, Contractors and brands of power tools.
Programmers do seem to make the biggest deal about "all the fighting", everyone else seems to just accept that professionals are opinionated and arguing is how progress is made. But I'm on the inside with the programming stuff and on the outside looking in for the rest of these fields so maybe that's not true.
From what I've seen, smart Doctors and Contractors eventually get to discussing empirical data and costs. Far too often, I've seen programmers just make up crap and state it emphatically.
I think the culture would be a vital part of an ecosystem of empirical observation. For the sciences generally, the culture predated the sources and gave rise to them. For medicine, I think a culture of empiricism was imported from other scientific fields. For contractors, they are very motivated to note what works, what breaks, and what enables them to make more money.
I actually built in anonymous usage logging into TermKit using Google Analytics over SSL. It logs the types of commands you execute (no data). It's my plan to release this data back to the community regularly. I don't think anyone has done a large-scale survey of command-line unix usage before. Should be interesting.
Edit: and you can easily turn it off if you wish.
It's very hard to make a product that essentially devalues things that your customers spent a lot of time learning. You're probably better off ignoring people who already happy with their shell experience, and going after people who have not yet invested in learning all that crap.
And yes, it's crap. And I say that not because I don't know it myself, but because in the end, much of it is not essential to the actual job we're trying to get done, it's the tools we use. And the tools are not the job.
I'm quite bad for upgrading for upgrading's sake but I can understand why, of all people, traders at Bloomberg didn't want any kind of learning curve on their terminals.
Yes, it's clearly better but users don't always want to change to something that does what they already do in a more modern way.
You built something great, made it open source, which is even more great, and you're here to answer people, which is amazing. Now, please don't act like "I implemented x RFCs, I can do y like the best...", it's simply useless here. One reason is that people already know you can code well, and they can even read your source if they want to know better, there's no need to brag. Another reason is that HN is the place of some very good developers, and I believe humility is appreciated here, at least until you build some life changing software (and I won't debate about what is or is not life changing).
Anyways, thanks for building this and releasing the source code as open, it's cool.
Again, the architecture supports it.
We can agree to disagree about Vim and shell scripting. I use those both, all day and every day. Tastes vary. That's fine.
I really wish you would reconsider the single quoting/WYSIWYG/visual divider business. It's extremely jarring to see awk (or sed, etc.) without those single quotes.
Doubting your credentials on the basis of this is silly, and will probably be the minority reaction in the long run. I would be surprised if you don't get offered a few jobs as the result of making TermKit.
I think this is a cool idea. I think it needs to be cross platform. However, it must be fully backwards compatible with the full unix toolchain to be useful. If it isn't I can't use it, and a lot of other potential users will also be unable to use it.
I love the idea thanks for rethinking the terminal.
TermKit's author may dislike Vim, but I suspect that he's helped its users in the long run.
The benefits of having your vim settings whenever you type 'vim' rather than whatever's on the server is invaluable, too. It's not an easy task to satisfy everyone, and I wouldn't expect TermKit too; nevertheless I'm excited to see how it develops.
So maybe TermKit isn't the app for them.
> However, it must be fully backwards compatible with the full unix toolchain to be useful.
"Must"? If this app does something useful for you, great. If not, that's fine too. Every app doesn't need to be used by every person.
happy?
It seems like TermKit could handle curses applications fairly straightforwardly and without modifying those applications. Just set TERM=xterm, and when you see the xterm initialization string, either open a new tab or define a region in the existing tab, and emulate an xterm within that region. (If you use a region in the existing tab, it could have a control attached to it that splits that region out into a new tab.) That would allow existing programs like vim, htop, powertop, and mutt to work perfectly within your terminal.
Personally, I'd like to use this like an enhanced standard terminal. So, for instance, I'd like to have the standard ls output rather than something graphical, but I'd like the filenames in the ls output to act as links, so I can click to open or hover for a preview. And while I want the standard cat command, I'd also like to have the command that displays something inline in the terminal (with the above-mentioned control to move it to a new tab).
Where I work, everybody has linux development machines, but use their machine of choice as their actual workstation. This either forces people to use vim/emacs through SSH, or set up some local file sharing so that they can use their bloated eclipse thing.
Personally, I've spent months each with a few of the popular editors around, and I fall back on vim just because my .vimrc has been tuned so much over the past few years that it's just painful to use anything else. I don't even care if the editors have more features.
Now, if I had a fancier terminal, where my mouse click picked the right vim split view instance, or highlighting text in a split view vim selected only text in that window, instead of the whole line of the terminal, I would use that. MacVim is pretty much the perfect tool for me, but it's local and not remote (and also not inside a terminal that I can split up with screen).
:help mouse
All of the things you mentioned are supported and work with most terminal emulators (tested with xterm, gnome-terminal, iterm2 on OSX)
Try to control-select in the terminal. Works with my Gnome term 2.
> vim/emacs through SSH
We work like that too, and I see only advantages to this set-up, the least being forcing everyone to learn find, grep, vim. These powerful tools increase productivity but have a high barrier of entry, so best is to have no other choice.
Same here. Just adding a tiny little bit of enhancement without changing anything in the standard behavior could be a bettter idea. Examples:
In the article the author says "The interaction is strictly limited to a linear flow of keystrokes, always directed at only one process" and take it as a limitation. From my point of view, when doing geek work on big machines, I need to drive a "linear flow of keystroke" in the machine. It is the way to have a deterministic behavior. It is the way to be able to script my work. I feel empowered by the control I have on what the machine does. Everything else (ie Windows, Mac UI) feel like a console game to me, in the sense that I give away my full control on the machine in exchange of impressive graphics, ease of interaction and safety-for-kids.Most of what TermKit is doing doesn't immediately appeal to me (as a longtime shell junkie of sorts), but one thing I would love to have in a terminal is tooltips, or popups of some sort. For example, say I get a 40 line stack trace, I'd like to just see one line (the exception, where it was thrown from) but have the option to learn more by clicking on a line in the terminal. Basically how exceptions are reported in the browser in Django or Rails, but in the terminal.
I could see this being done well-- it's not hard to beat bash for syntax and functionality-- but I could also see it being done poorly or considered an ancillary feature.
Shell scripting sucks, but it's the only language I know that lets me write tiny little scripts in not minutes but seconds, inline, without breaking out of the flow. Just like dynamic versus static languages, the quantitative difference in writing speed is enough to make a qualitative difference in the types of programs that can be written; and the difference between a non-scriptable shell and a scriptable one is like the difference between a GUI and a good CLI.
A large part of that scriptability is just grep and sed and friends, which TermKit apparently does support, but sometimes bash's loop structures are also required...
Just my two cents.
It probably won't be "production ready" for years, but I would hate to think that 20 years from now we're still typing into a dinky terminal that has been around since the 70s! We won't get the next-best-thing down the road unless we start working on it now. TermKit is the first step.
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?
http://news.ycombinator.com/item?id=2559361
TermKit could become my OS of choice.
Same idea, with powershell as the base.
Thanks for the tip.
Sadly that typically only worked in full-screen mode.
If somebody wrote an ordinary terminal emulator that allowed pixel graphics as part of the normal text flow, and created an easy API for programs to use it, I'd be very happy.
TermKit looks cool, but I fear I'm too old-fashioned to move away from ordinary shell in such large steps.
I 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.
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.
Why all the haters? Surely the next step is a MIXED-MODE console where you can have both the power features shown, and a simple mode for the die-hard traditionalists.
Again... stirling work and I'm looking forward to it.
Yes, that's possible. Webkit embeds JS, and you can do the craziest of controls in JS, communicating with your process through JSON packets (at least, that's how I understand the article). This would need some extension mechanism at the side of the shell, though, but that's not rocket science.
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.
If you do not provide direct user access to a pseudo terminal through a terminal emulator, then you will undoubtedly lose functionality. You need both the pseudo-terminal and the terminal emulator. If you do provide direct user access to the pty through a terminal emulator, then what the hell is the rest of the crap there for?
You can already do this. http://www.faqs.org/docs/Linux-mini/Xterm-Title.html
> Wouldn't it be nice to show the intended completions in a popup as you're typing (like web browsers do)?
This can probably be written as an extension to bash/tcsh/zsh to use the pop-up completion facilities of vim. If you want nice webapp-looking ones, you might be able to get away with terminal escape codes and use a perl script (this is how rxvt lets you click on http links automatically).
> can the result not be folded into a single line showing the summary, that I could expand if I wished?
An interesting point, and I was going to counter with a small one-liner using 'tee,' but I couldn't think of a good one quickly that does what you really want: 'auto-collapse.' The problem with this is that often with giant lines of output you really only want to look at the last few to see what happened. Otherwise your output is typically some kind of streaming log (you do not want auto-collapse for this) or a poorly written program. "walls of text" suck and are usually an indication of something you expect to have a lot of output (looooong makefile) and can do a less accordingly, or an unexpected error. If it's an error you want to see what it is, so you're going to click on the 'expand' button -- an extra click every time on an all-typing interface kind of sucks.
In addition to the frontend and pipe changes, I also imagined changing the way files are accessed. Some subsystem could put indexes and attributes on certain data files so you could run something like:
$ query --tsv login, uid, name[last='Smith'] < /etc/passwd > mysmiths.tsv
or:
$ cat /etc/passwd[@uid=0]@login
and you would get the desired set of information without needing to write potentially buggy regex scripts. If there was a new type of file that you wanted to get data from in a few different ways, you could write only one buggy regex script to use as a filter and then query the file with the shell's normal query methods to pull down any information you might need. In the example of pulling users from a file, the shell could know from the attribute metadata that you are looking at a list of users and it could show the results as widgets that you could right-click to get the user's properties.
This all implies rewriting every utility in the system to accept recordsets instead of text, adding custom code for every different targeted data file, and making sure it all works with existing tools that have not been converted yet. That could be difficult, or at least time-consuming.
So putting that in.
Maybe in your terminal world, but not mine buddy.
Google "helvetica monospaced".
There are, however, some concepts that are worth copying and that are in fact doable in current terminal environments. What I would like to see is more innovation in the world of console programs. There are lots of things to do in terms of auto-completion, navigation and integration etc.
Take a look at ranger [1] and sup [2] for examples of new neat console applications.
[1] http://ranger.nongnu.org/ [2] http://sup.rubyforge.org/
http://notmuchmail.org/
http://blog.whats-your.name/post/2011/02/14/sifting-thru-you...
Specifically Step 1 of the instructions[1] has a link titled "install node and npm" [2] which has the line 'git clone git://github.com/ry/node.git', which is incorrect. The correct URL (as far as I can tell) would be 'git://github.com/joyent/node.git'.
In addition the linked instructions say nothing of npm, which can be installed quite easily by running 'curl http://npmjs.org/install.sh | sh' as root.
Back to the TermKit instructions again, and step 5 says 'git clone git@github.com:unconed/TermKit.git --recursive', which didn't work for me. What worked was 'git clone git://github.com/unconed/TermKit.git --recursive'.
Finally after all that, I just see 'You cannot use this version of the application TermKit.app with this version of Mac OS X.'. Would have been nice to mention that at the start.
[1]: https://github.com/unconed/TermKit [2]: http://howtonode.org/how-to-install-nodejs
I generally follow the pattern described here for node: http://blog.nodejs.org/2011/04/04/development-environment/. If you do that, and then install npm as you describe (but as a regular user), then npm will automatically be installed under the node installation.