For example, personally, I believe the completion belongs to the shell not the terminal, and i'd rather not use the mouse on a terminal's displayed text except for copy/paste.
Doesn't mean its not cool.
Lots of people here are making really cool stuff, and I love hearing about it! Keep it up!
If the terminal receives untrusted data back then I've got bigger problems than a security hole in my terminal emulator.
Also here is an overview of some of the possible ways things can go wrong: http://lists.kde.org/?l=konsole-devel&m=104617524910254&w=2
The entire concept of exploiting a terminal by supplying hostile input has been around for over 10 years now. Unix veterans and BBS users have been exposed to this type of problem since the very beginning, a newsgroup search can turn up all sorts of exploits, from the ever-popular "flash" program to the abuse of logging features in xterm which were disabled in R5
Untrusted data being sent to a terminal emulator does not imply you are logged into an untrusted system with it. Users should be able to view arbitrary files through their terminal emulator safely, should be able to use IRC safely, should be able to use finger safely, etc.
There are enough people here reporting errors (having it hang with certain output, crashing X.org, etc) to cause me to be very wary of this. I am not confident it would stand up to a security review.
Oh, and if the NSA is listening, I wouldn't actually kill, that's just an expression. Please don't arrest me.
Currently it looks like this.
Should work for you if you are using anything. But works out of the box with cmd + msys-git + some other godness.
Also spit window support, aliases, fullscreen, history search. Sublime Text like shortcuts.
If my assumption holds, I did find this article recommending Console2.
I like the tabbed interface and the way it does select/copy/paste (close to the Windows way) in the CMD console. And, it has some pretty cool support for the FAR Manager.
Here's a nice writeup by Scott Hanselman: http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsol...
Select-to-copy is yuck for two reasons:
1: After you select, it copies and then deselects. This is annoying if you want to see that you selected the right thing, and it doesn't allow you to change your selection if you see you were off by a character.
2: I like to select to mark my place sometimes, but I don't want that to change what's on my system clipboard.
ctrl/shift Insert is yuck because it's a two-hand keystroke and doesn't have an easy way to remember whether shift or ctrl is the copy. (I don't often make mistakes between the two, but it leaves me unsure of myself which is a half second lost to hesitation each time.)
I miss middle-click to paste and select-to-copy where ever I can't use them.
So to the humour. The issue is HN can't tell the difference between satire of itself and real advice. Each of which is probably equally valuable. Nobody wants to hear this. They all want to feel good. And get rich! And have authority!
Humour has no place here...
Cygwin is pretty awful as well. I hear a lot of people suggest it but I really couldn't get on with Cygwin. I found MinGW to be a much better solution (which also ships some pretty cool terminal emulators as well)
Before mintty, I used Putty and connected to a local SSH server. Putty is pretty nice too.
Have you tried MinGW? It's a fork of Cygwin and (in my opinion at least) fixes a lot of problems with Cygwin's install process.
Clink (https://code.google.com/p/clink/) is also something I have found useful.
* single binary installer
* X server
* Automatic SFTP sidebar when connecting via SSH
* painless SSH-tunneling (I can never remember the order of arguments on the command line)
* dancing Tuxes
There's probably more things I haven't even discovered yet (which may be too much for some people, who just want a simple terminal emulator). It's not all roses, it has locked up a couple times on me, but thanks to tmux it doesn't bother me much.
I'm not a bash scripting poweruser though.
I like the FuTTY fork of it at the moment.
Pull request is from less than 12 hours ago, so I'm not sure how long it'll take to get into a release.
Does everything FinalTerm does, and probably more (and can be driver with the keyboard only).
Funny thing, I don't like e-shell. I rarely, if ever, have to interact with the output of the previous command.
For command re-editing, most shells (zsh, bash) offer very powerful completition/editing capabilities that probably FinalTerm cannot match.
Admittedly, I sometimes (but rarely) have to use the output of the previous command. The problem is, if it's an url, you probably just want to click it/copy it, and then pretty much all terminals can do this already.
If I want to process the output of the command, I just re-execute it in a pipeline. Just compare the number of keystrokes to go up ~10 lines and the time to type !! (or up-arrow) | grep 'something'. Heck, even copying the output to the clipboard is faster by using a pipe: cmd | xsel
Reflowing is also something many terminals do nowdays. I personally use urxvt because it's the fastest terminal I could test, and actually supports fallback fontsets. VTE-based terminals (even the ones that pretend to be small and fast) are 5-6 orders of magnitude slower at redrawing. e-shell, by comparison, is a dog due to the much more complex display.
These kinds of extra-helpful term emulators seem like the natural progression of auto-completion and all the other goodies people love about oh-my-zsh. Once someone gets this right, it will seem silly to use a 'dumb' terminal in a graphical environment.
The separation between shells and terminals is a good thing and should not be ignored. New features should be added to shells, and only if necessary, we can add new features to terminal emulators to support those shell features. Many, if not most, of those supporting features are already in terminal emulators. For example, every single modern terminal emulator supports mouse input (pretty much by definition): this could be used by shells if they were so inclined. If you want to add some sort of menu-based completion that supports mouse selection, great! The shell is the correct place to do it. Want to display some images or vector graphics? Some terminal emulators will have your back even in those situations, though support for those things would need to be more widespread before that stuff could really be used properly.
Talking specifically about TermKit: If I'm on a Mac using Terminal to access the local shell, why would I care if the features are coming from the shell itself or the Terminal app?
Of course it would be 'better' or more 'proper' if all the functions were built into the shell, but like you say, it takes widespread adoption. I don't see what the problem is with starting to add features to your terminal and then let the good ones trickle back down into the shell as they become widely adopted.
Seems like a confusing nightmare, but I'm not fundamentally against it.
This one look nicer. At least it doesn't make the error of the previously mentioned attempts like trying to create a custom shell instead of using regular ones. Nor it does screw up existing workflow. As for trying to understand the terminal content, it is a "challenge" and I don't think it is a good idea as it will remain command specific and it has been proven to be a problem in the past, and it still is.
That said, there may be very valid reasons which are performance or convenience-related for choosing Vala. Would be interested in a discussion of those if so.
IMHO: use something else...
Are the GNOME folks crazy?
Terminal emulator is, in fact, a GUI application, it's just that it mostly consists of a single text matrix widget. I believe many people use mouse to select text, so I don't think there's anything wrong if the text is somehow more interactive, as long as this is non-obtrusive.
The thing is, GUIs aren't wrong, it's just that the GUI applications have no uniform interoperability like their CLI counterparts. Whose fault is that? Certainly NOT the authors! The fault is much deeper in the OS.
P.S. It doesn't have to do with hating GUIs for most people, it has to do with using a terminal efficiently, which often times means avoiding the mouse when possible.
yes, but that's exactly the argument I expected. Not using the mouse on GUIs is entirely possible, but your argument let's GUIs look as if they are antiquated technology not able to handle hotkeys or vim motions or anything else you want to improve efficiency.
You refer to efficiency as driving point, which I'm a big fan of, although you probably know quite well that you wouldn't use an OS if it had no GUI. The cost of entry into the IT community isn't just time, but capability and intelligence. These are the reasons why still many people are digitally divided and can't use computers efficiently. The GUIs aren't easy enough for them, forget about the terminal efficiency.. You only reach efficiency when you have the possibility to collect enough routine. How will your Grandfather get that routine, when the "cost of entry" is too high for him to master in his age.
We're not on facebook, don't expect anyone to go phishing for upvotes. We care to improve the knowledge, efficiency, health and productivity of startup people on HN.
but it would be sweet (more for my folks than for me, but still) if you could click on a filename in a terminal to open it, or drag from one directory listing to another to move it
You don't have to use the GUI I'd imagine.
I would love to have FinalTerm's features in some sane terminal (no gtk, no super slow libraries etc)
Who is "you"? Different people have different needs and preferences.
Maybe, but that makes the GUI look worse.
1.8 Changelog: http://sourceforge.net/p/tmux/tmux-code/ci/master/tree/CHANG...
It may not reflow as expected if you have more than one client connected to the same session - since it limits itself to the smallest attached client. If you leave your ssh session connected to the session and then connect again locally it is not obvious why reflow won't work, but you may need to just disconnect the other client.
I'm currently using Terminator, but it's rather ugly in terms of scripting for panes and tabs. If you could implement those two features out of the box, I'd pay for this software.
About the only thing that does work is the autocomplete, which is certainly nice, but not nice enough that I'm going to give up on a ton of functionality I've gotten used to.
Don't get me wrong, I appreciate the work you're doing and don't want to discourage you, the terminal is certainly due for a rework, and this is a huge step in the right direction. If more of the features on your website were implemented/worked I would be very tempted to make a permanent switch, but I spend 8 hours a day in a terminal window, everything needs to just work.
I don't suppose there's a way to use this with Windows, either as the shell emulator for Cygwin or a shell emulator for an SSH connection? Then I could actually have nice shells when I have to work on a Windows box too.
Looks like no port to Mac yet...? That's cool. I''ll wait.
I'm a pretty basic user loving iTerm on Mac. One feature I really want is mouse positioning and selection of text (for the current command line). Arrow navigation is okay, but I'm a casual user not a power user.
But: The autocomplete doesn't seem to work for me, do I need to install something else?
Also the typing effect makes input feel laggy and I can't find a way to turn it off.
I'm on Ubuntu 12.04
I think what I like so much is that it is a rare example of an expert ui, designed for when you are really proficient rather than for learning or discoverability.
I noticed that the terminal does not work well with my zsh right-prompt (ends up printing on the left and getting overwritten by what I type), and has some issues with my prompt when my little Git status line appears when browsing inside a repo. But I will be keeping an eye on this project.
Error begins at "cmake .."
This is pretty standard for compiling and installing any software from source.
Read further down and you'll see there's a shake-n-bake PPA ready to go.
We'll have to see of this Terminal Emulator goes terminal or can break out into a fulfilling life.
No mention of unicode support on the page?
should be typed in terminal, as above?
or ".." should be, what? sort of a newbie with terminal...
is ".." a location ...? can anyone provide a reasonable example (to put in place of "..")?
I tried the install commands, as listed in the README (on the Final Term Github Source page)... and the install failed.
Since one uses terminals for several different things, it kind of makes sense the idea to use ones specialized for each purpose. I think it's an interesting idea.