Like pretty much everybody, I can't stand electron. But there's an interesting angle here, which is integrating the thing running in the terminal emulator (the shell) with the terminal itself. What I'd be most interested to see though would be a terminal pushing curses support forward, since I use a lot of curses-based applications.
Taliing about integration, I like terminals with good mouse support, where one can plumb the selected text with a click.
For some reason, there aren't so many, except
- 9term from plan9,
- tilix or tylix, which has customisable actions for regex patterns
- URL, mostly http, in vte based terminal
I wrote a simple patch for st that process some escape sequence from the shell to have the terminal aware of its shell current working dir (ocs7).
Using this simple hack, one can just cd & ls & select "foo.pdf" & right click to have it handled by one ´s plumber (open, xdg-open, plumb ...) or even right click "path/to/file:line:column" from a log to the editor.
This feature is so simple, so addictive in plan9/acme, that I don't really get why it isn't offered by most terminals.
How's the performance? GNU yes can produce output at more than 10GB/s. Does it cope well with that? How about lots of output that contains lots of escape sequences?
Performance is definitely worse than in iTerm or gnome-terminal, but it's improved a lot in recent Upterm versions, and we plan to improve it further. I'd say it's good enough, but you can try yourself.
The author says that the most important things are typing delay and how quickly you can Ctrl+C a command, not how much text it prints per second. Upterm is good at both.
Not to dismiss concerns about terminal performance, but if you need a terminal to keep up at ten gigabytes per second of data, I question your goals* . How can you seek in that much data? Will you page-up or scroll for hours to find what you need? Past 1GB in the buffer, even iTerm2s search functionality lags out painfully, but . . . so does grep, on a file that big.
There are other aspects of terminal performance that are very important, and you may have meant to point towards those, but as it is this comment just reads as bikeshedding. "Performance is (a|the most important) feature" refers to performance in areas that matter.
* And yes, I know that yes(1) can be used for performance/stress testing of systems by outputting endlessly. Doing that to a human-consumed TTY seems like an example of spacebar heating: https://xkcd.com/1172/
> Not to dismiss concerns about terminal performance, but if you need a terminal to keep up at ten gigabytes per second of data, I question your goals* .
I don't want OOM killer to murder everything just because I accidentally catted a 1 GB file to stdout rather than another file. Or accidentally catted the .iso rather than the .iso.asc. Nor do I want to wait 5 minutes for the terminal to render it all.
Sure, accidents don't happen every day, but it's a massive inconvenience if it does. It was enough to make me abandon all feature-rich VTE based terminals in favour of rvxt.
Usually performance in GNU yes is a canary for other bad performance. Its more like saying "if you can handle yes, you can handle anything." I've legitimately crashed hyper term (another electron-base term) when dumping other large amounts of data, like in large log files.
Surprisingly it has pretty moderate resource usage. I have both iTerm and Upterm running on my laptop, here are the stats. Of course, your mileage may vary.
Almost all my terminals are ssh'd into some remote machine. Do you still get the features like enhanced command line completion in this scenario? What about integrated screen/some other kind of reconnection?
It's theoretically possible to have all the Upterm niceties over SSH, but not possible at the moment. As of screen and tmux, we have no plans to integrate with them.
We really need a modern take on terminals, so keep up the good work.
I know there is a lot of clash around electron apps these days, and I'm the first one to dislike the waste of resources. But maybe in 5 years electron and hardware will improve so much it won't matter anymore. So if it allows you to experiment with new stuff, keep going.
I've given this a play and I hope you don't mind some constructive criticism I've experienced:
First of, I really like the idea of this project despite normally being a vocal critic against Electron. However I think you bit off too much trying to write your own $SHELL as well as terminal emulator. The result is rather uncomfortable to use because there are shell bugs and incompatibilities compounding the usual expected bugs with any new terminal emulator. For example it took me 5 minutes to just cd into a directory because env vars weren't being recalled, the ~ variable wasn't being recalled, and auto-complete wasn't keyboard optimised (I'd arrow down and hit enter but it would crop the line rather than select the auto-complete entry).
So the next thing I did was to start my preferred shell and I then ran into a whole other series of bugs due to the terminal emulator being tailored for it's own specific shell. In fact the bugs there were so severe that it renders the term virtually unusable on any of the standard shells nor the more esoteric ones I contribute to.
One thing I was pleasantly surprised about though was how well it supported ANSI escape sequences - even ones that aren't part of the formal standard (such as the iTerms true colour sequences). But the bugs surrounding the terms handling of readline (and similiar) really feels like many of the basics are missing despite having some cool advanced features already.
Overall, as much as I'm ideologically against Electron, I can see the advantages of using it in this domain because it allows the ability to include rich content in the command line. It might be nice to get to the point where the command line can offer as much rich content as a web page (something I'm working towards with my own project in fact) - in which case Electron (or similar tech) seems the obvious choice for building a terminal emulator. However upterm's dependance on using your own implementation of Bash (I think it's a bit disingenuous calling your shell "Bash" but that's your prerogative) makes this highly frustrating compared to other rich terminal emulators already out there. And the inability to run your own shell within upterm makes this inflexible for anyone wanting to do something a little more indepth than just cat'ing a JSON file (even running a DB command line tool like mysql or redis-cli would be impractical in upterm in it's current state. And while I didn't try SSHing into remote boxes I can see the same issues happening there too).
I don't know the age of this project but I think it does have real potential. However if I was to ask for anything - and I appreciate this is your baby so I have no entitlement what-so-ever - it would be if you could offer a $SHELL'less version for power users.
edit: Also, I've noticed commands that fail don't appear in the upterm's history. Was this an intentional decision? I appreciate there are arguments for and against only including successful commands but sometimes you'd typo something and the inability to up-array and edit my failed commend added to my frustration. If this was an intentional design decision then is it worth including the last command regardless of success and then excluding it from all subsequent placements in the history?
This is a great piece of feedback, thank you so much!
We do utilize a login shell for executing commands, but we only support Bash and ZSH. So, it's a real Bash. However, there are some complications with environment interpolation and built-in commands; it's a known bug and we're working on it.
Unfortunately, I don't see how to allow using custom shells while providing a better command entering experience (i.e. zle or readline replacement). The core issue is that shells' interface is too primitive: it only consists of three streams with no per-job separation or anything; I wish Bash had a programmatic or REST-like interface.
I made a superficially similar thing but I've never released it.
My differences:
(1) The shell is in pure js. It's a thin wrapper around shelljs but I had plans to move to a builder type syntax, eg. fs.cp().f("/tmp/foo").t("/tmp/bar").x();
(2) I made an api so people could quickly code up graphical output for commands.
Just wondering if you'd be interested in integrating a feature like this. Do you have a chat channel?
I'm afraid it's not going to happen any time soon, if at all. But even if it does happen, it won't be cmd.exe or PowerShell support, but rather some kind of POSIX shell for Windows.
Tried it several months and left unimpressed. While by what the product aspires to be, it could be the IDE for command line, it's far from that. The only difference is essentially autocomplete, which is not intelligent (and probably can't be, nothing along the lines of parsing --help or man pages) and felt clunky when trying to edit part of a command and then try to get another "suggestion".
With zsh's built-in Ctrl+R it's at least possible to reduce list of suggestion and then travel up the history in those suggestions. While the more powerful fzf will give you the list of commands you've run in a selectable dropdown.
Upterm I think could be eliminating entire classes of tools which sometimes are unnecesary complex. Server automation could be part of pre-saved playbooks which are saved to your terminal history and can be easily brought up and run according to rules. Curl arguments could be arranged in a way where they are actually managable. Parsing --help and man pages (which is possible, there is a workable implementation in fish AFAIK). Upterm is in position to take on that functionality, but right now it's not much more than already mentioned hyper, but with custom handled prompt line.
Readit News
Author: I wrote something for people who care more about features than performance.
People who care more about performance than features: I am personally offended that you created this.
For some reason, there aren't so many, except - 9term from plan9, - tilix or tylix, which has customisable actions for regex patterns - URL, mostly http, in vte based terminal
I wrote a simple patch for st that process some escape sequence from the shell to have the terminal aware of its shell current working dir (ocs7). Using this simple hack, one can just cd & ls & select "foo.pdf" & right click to have it handled by one ´s plumber (open, xdg-open, plumb ...) or even right click "path/to/file:line:column" from a log to the editor.
This feature is so simple, so addictive in plan9/acme, that I don't really get why it isn't offered by most terminals.
Except, you know, all of the folks that say that they like Atom or Visual Studio Code: https://insights.stackoverflow.com/survey/2017#technology-mo...
(Atom and VS Code were specified by 20% of voters in each category).
It sure results in exciting and interesting bugs, if you look at upterm's issue tracker.
https://danluu.com/term-latency/ (Previous discussion: https://news.ycombinator.com/item?id=14798211)
Recently there was this terminal performance test https://danluu.com/term-latency/
The author says that the most important things are typing delay and how quickly you can Ctrl+C a command, not how much text it prints per second. Upterm is good at both.
Considering I dropped those because I consider them slow and bloated, good luck with this Electron monstrosity.
You can have my RXVT when you pry it from my cold, dead hands.
I dropped those because they're magnitudes slower than urxvt. You managed to make a terminal emulator that's even worse?
There are other aspects of terminal performance that are very important, and you may have meant to point towards those, but as it is this comment just reads as bikeshedding. "Performance is (a|the most important) feature" refers to performance in areas that matter.
* And yes, I know that yes(1) can be used for performance/stress testing of systems by outputting endlessly. Doing that to a human-consumed TTY seems like an example of spacebar heating: https://xkcd.com/1172/
I don't want OOM killer to murder everything just because I accidentally catted a 1 GB file to stdout rather than another file. Or accidentally catted the .iso rather than the .iso.asc. Nor do I want to wait 5 minutes for the terminal to render it all.
Sure, accidents don't happen every day, but it's a massive inconvenience if it does. It was enough to make me abandon all feature-rich VTE based terminals in favour of rvxt.
The only caveat is that I'm not sure I want to have another electron app chewing through 15% of my CPU...
https://imgur.com/a/bwD06
I know there is a lot of clash around electron apps these days, and I'm the first one to dislike the waste of resources. But maybe in 5 years electron and hardware will improve so much it won't matter anymore. So if it allows you to experiment with new stuff, keep going.
And good luck.
First of, I really like the idea of this project despite normally being a vocal critic against Electron. However I think you bit off too much trying to write your own $SHELL as well as terminal emulator. The result is rather uncomfortable to use because there are shell bugs and incompatibilities compounding the usual expected bugs with any new terminal emulator. For example it took me 5 minutes to just cd into a directory because env vars weren't being recalled, the ~ variable wasn't being recalled, and auto-complete wasn't keyboard optimised (I'd arrow down and hit enter but it would crop the line rather than select the auto-complete entry).
So the next thing I did was to start my preferred shell and I then ran into a whole other series of bugs due to the terminal emulator being tailored for it's own specific shell. In fact the bugs there were so severe that it renders the term virtually unusable on any of the standard shells nor the more esoteric ones I contribute to.
One thing I was pleasantly surprised about though was how well it supported ANSI escape sequences - even ones that aren't part of the formal standard (such as the iTerms true colour sequences). But the bugs surrounding the terms handling of readline (and similiar) really feels like many of the basics are missing despite having some cool advanced features already.
Overall, as much as I'm ideologically against Electron, I can see the advantages of using it in this domain because it allows the ability to include rich content in the command line. It might be nice to get to the point where the command line can offer as much rich content as a web page (something I'm working towards with my own project in fact) - in which case Electron (or similar tech) seems the obvious choice for building a terminal emulator. However upterm's dependance on using your own implementation of Bash (I think it's a bit disingenuous calling your shell "Bash" but that's your prerogative) makes this highly frustrating compared to other rich terminal emulators already out there. And the inability to run your own shell within upterm makes this inflexible for anyone wanting to do something a little more indepth than just cat'ing a JSON file (even running a DB command line tool like mysql or redis-cli would be impractical in upterm in it's current state. And while I didn't try SSHing into remote boxes I can see the same issues happening there too).
I don't know the age of this project but I think it does have real potential. However if I was to ask for anything - and I appreciate this is your baby so I have no entitlement what-so-ever - it would be if you could offer a $SHELL'less version for power users.
edit: Also, I've noticed commands that fail don't appear in the upterm's history. Was this an intentional decision? I appreciate there are arguments for and against only including successful commands but sometimes you'd typo something and the inability to up-array and edit my failed commend added to my frustration. If this was an intentional design decision then is it worth including the last command regardless of success and then excluding it from all subsequent placements in the history?
We do utilize a login shell for executing commands, but we only support Bash and ZSH. So, it's a real Bash. However, there are some complications with environment interpolation and built-in commands; it's a known bug and we're working on it.
Unfortunately, I don't see how to allow using custom shells while providing a better command entering experience (i.e. zle or readline replacement). The core issue is that shells' interface is too primitive: it only consists of three streams with no per-job separation or anything; I wish Bash had a programmatic or REST-like interface.
My differences: (1) The shell is in pure js. It's a thin wrapper around shelljs but I had plans to move to a builder type syntax, eg. fs.cp().f("/tmp/foo").t("/tmp/bar").x();
(2) I made an api so people could quickly code up graphical output for commands.
Just wondering if you'd be interested in integrating a feature like this. Do you have a chat channel?
i.e.
`cd $THAT_ENV_DIRECTORY`
however I always get
`The directory "$THAT_ENV_DIRECTORY" doesn't exist. `
although clearly it does as it is autocompletion suggested
Deleted Comment
With zsh's built-in Ctrl+R it's at least possible to reduce list of suggestion and then travel up the history in those suggestions. While the more powerful fzf will give you the list of commands you've run in a selectable dropdown.
Upterm I think could be eliminating entire classes of tools which sometimes are unnecesary complex. Server automation could be part of pre-saved playbooks which are saved to your terminal history and can be easily brought up and run according to rules. Curl arguments could be arranged in a way where they are actually managable. Parsing --help and man pages (which is possible, there is a workable implementation in fish AFAIK). Upterm is in position to take on that functionality, but right now it's not much more than already mentioned hyper, but with custom handled prompt line.
Also, we recently integrated monaco-editor by Microsoft, so editing is much less clunky than it was before.