Hello. I'm the author of Black Screen, and I'm upset this post has appeared on Hacker News. The terminal is at a very early stage; I don't even use it by myself. Although, it's nice to see that people show some interest.
You should probably put a note saying as much at the top of the README.
Pretty cool looking project though, I have been thinking about something like this for a while now. The two biggest problems seem to be performance(I spawn throwaway shells all the time, so my terminal emulator need to open pretty much instantly), and fully compatibility(I use vim in the terminal as my main editor).
A new terminal/shell is a very hard sell, as I know from my own experience. Six years ago I wrote my own terminal/shell combination ( http://wiki.tcl.tk/23446 ). It works well enough that I've been using it myself full-time at work ever since, but although a few other people have tried it, no-one else ever adopted it. My own attempt is implemented in Tcl/Tk, an older but much lighter-weight framework (it has no problem with cat-ing a 50MB file).
I combined the functions of shell and terminal because I found the shell/terminal split made some of the functionality I wanted difficult or impossible. One example is that I colour text written to stderr in red - standard shells mix stderr and stdout together before the terminal even sees them.
I decided early on that I would not support terminal escape sequences. I set the TERM environment variable to "dumb" which tells well-behaved programs not to use escape sequences. So you can't run vi/vim in one of my windows, but I always use gvim so I don't find this a problem.
Similarly after some experimentation I decided not to use ptys as they created as many problems as they solved. So programs which change behaviour based on whether they are connected to a terminal behave as if running from a script. Eg. running "man command" lists the whole man page rather than trying to page it - but this is what I want since one can page up/down in the shell anyway.
However it seems that people who use a terminal get very attached to its idiosyncracies and will reject anything even slightly different. Since it's very difficult to make any real improvements without introducing incompatibilies, attempts at improving the terminal/shell user experience rarely catch on. In contrast, a few other tools I have implemented using the same technology have been adopted by a worthwhile user community at work. I think the difference is that they are used for more specialised tasks and don't require the user to change their everyday workflow.
One of these seems to pop up every few months, which is great, terminals are old crusty awful things, but it seems like they always die out in development before they can run existing things like Vim which makes them fun POC's and not much else :/
The problem seems to be that they come at things from the wrong direction - you can't run vim without being backwards compatible with at minimum terminfo pages, very likely vim also makes an assumption also that the terminal communicates over a tty, and possibly you may just need to support actual ANSI Escape Codes. You can't run anything else without that either. Running vim should be the first thing this terminal can do.
Just like the web itself, any new teminal client needs to be backwards compatible with the capabilities of prior terminal clients, because programs that run in the terminal expect it. And if your terminal can't run the programs everyone runs in their terminals, no one will adopt your terminal. But many of these projects seem to have no intention of maintaining that backward compatibility. Some, like TermKit, fully conflate the terminal and the shell and even many UNIX utilities.
You can't hope to supplant ANSI compatible terminals when you let them have the enormous advantage of running all the software anyone wants to run in a terminal that already exists. It would be like saying you have a new, better web browser that can't open any existing web pages.
No idea if this particular project has learned from past examples and is backwards compatible or not. (EDIT: It doesn't have a terminfo page, so probably not.)
The thing is, the web stack is not how to do it (for a prototype, maybe).
As they say above, this thing would halt when you cat a 50MB file.
It takes someone who's familiar with terminals, and can use a language fit for the task (and without too many depenedencies -- so if you built it in Haskell and I need the Platform and half of Cabal to build it, it will never fly -- and it being in Haskell it will not attrack many UNIX hands, who are the people familiar with Terminals most).
I would really love it if one of these web-based terminals managed to stick around. Just being able to view images in a terminal would be amazing. The trouble with building on web technologies seems to be that the overhead is just too high (eg. Atom) considering how many terminals the average developer has open at a time.
I guess at least since it's based on Electron, it might have more longevity than something built from a cobbled together base. Here's hoping!
black-screen$ gulp
[17:35:09] Using gulpfile ~/black-screen/gulpfile.js
[17:35:09] Starting 'default'...
[17:35:09] Starting 'watch'...
[17:35:09] Starting 'clean'...
[17:35:09] Finished 'default' after 359 ms
[17:35:09] Finished 'clean' after 58 ms
[17:35:09] Starting 'typescript'...
[17:35:09] Starting 'sass'...
[17:35:10] Starting 'react'...
[17:35:11] gulp-notify: [Black Screen Watcher] React has been compiled.
[17:35:11] Finished 'react' after 1.83 s
~/black-screen/node_modules/typescript/lib/typescript.js:35171
if (host.fileExists(fileName)) {
^
TypeError: undefined is not a function
...
That's understandable. It's like with editors. There is vim and there is Intellij IDEA (sorry, JetBrains, for calling your child an editor). I want it to be smart.
Ha-ha, I get that a lot after telling about React and Electron. Initially I was thinking about Swift + Cocoa, but I figured CSS would give me more flexibility in designing the UI, and it would allow more people to write plugins. Everybody knows JavaScript, right?
So, I use a terminal emulators pretty extensively, and I'm tired of their dumbness. Compare any operating system from 1980 and 2015 - there is a huge difference. The same with web-sites, text editors, and pretty much any other category of software. Except terminals. The biggest achievement they made is 256 colours support. Good job!
It doesn't take a genius to understand that the limitations are caused by the text user interface. Of course, text is a great and universal tool. It's easily parsable (or not so easily, but still parsable). It can be piped, after all.
But who said we can't take the good old text and present it beautifully? Imagine you fired an sql client, wrote a select statement and received an ASCII table as an output. Wouldn't it be useful if the terminal understood that it looks like a table and converted it into an HTML table, with sorting by any column, resizing, filtering, and everything else. The same with XML, JSON and every other format: why should I type `jq` after a command that outputs JSON? Is that so hard to just detect and parse it for me?
Output formatters was the idea that made me start the development. I also plan to let users write custom formatting plugins.
But even besides that point there is a lot of room for improvement in current terminal emulators. For example, I have a git branch displayed in RPROMPT of my ZSH. It works well, but if I checkout another branch from a different place, my shell will still show the old branch, which can have certain consequences, if you rely on it.
The current feature I work on is autocompletion. I plan to parse man files and provide only what can be displayed in that place. By the way, folks from the Fish team do the same.
Unfortunately, right now Black Screen can not be used as a replacement for your favourite terminal, it has a long path to the first release.
I kind of don't want to have my terminal emulator run a complete webbrowser because that's how all the cool kids now pull off the Delphi window skinning look of 2000.
If we can have a teletype metaphor today in 2015, 40-odd (or thereabouts) years later, with the awfulness of this whole idea being a minority viewpoint, perhaps we need to just go with the web browser metaphor today, and see what comes of it by 2055.
Thanks to people insisting for years that the TTY is just fine, we don't appear have any other options. Ideally, we'd have progress - but as it is, we have nothing, or a shit sandwich. Forgive me for not going for nothing.
I think that what these JS-based UI toolkits are doing is really great, but I really dislike the idea of bundling basically a browser with the application.
I have a feeling that when enough things want to run "a complete web browser", what we'll get instead is a single web-browser window server process for these applications to talk to.
When I saw this post I thought it was going to be an xterm with an oldschool CRT look. I got someone to build me one of those for playing rougelikes a few years ago - see here if anyone is interested:
http://ubuntuforums.org/showthread.php?t=1884955
I don't disagree, but as someone who has written a bunch of personal tools (including a Tinder assistant lol) with electron and nwjs, think about why people are using these runtimes before you rip on it. Since so many people are doing it, there must be some good reasons.
It looks like it uses "child_pty" to spawn pty's. child_pty hasn't been updated to support the latest nan/v8 api (in fact, it looks like it's been unmaintained since March). It also improperly uses fs streams to read and write to the pty fd which will exhaust the thread pool very quickly. So, even if you can compile it, it will still break.
It also looks like it doesn't handle sigchld with a waitpid anywhere, so be prepared to have a zombie apocalypse on your machine.
I'd recommend the author switch to pty.js[1] which now compiles on io.js >=3.0.0 and reads pty fd's properly, but I'm biased.
[+] [-] shockone|10 years ago|reply
[+] [-] giodamelio|10 years ago|reply
Pretty cool looking project though, I have been thinking about something like this for a while now. The two biggest problems seem to be performance(I spawn throwaway shells all the time, so my terminal emulator need to open pretty much instantly), and fully compatibility(I use vim in the terminal as my main editor).
I'll be watching to see how it turns out.
[+] [-] SalGnt|10 years ago|reply
[+] [-] cmacleod4|10 years ago|reply
A new terminal/shell is a very hard sell, as I know from my own experience. Six years ago I wrote my own terminal/shell combination ( http://wiki.tcl.tk/23446 ). It works well enough that I've been using it myself full-time at work ever since, but although a few other people have tried it, no-one else ever adopted it. My own attempt is implemented in Tcl/Tk, an older but much lighter-weight framework (it has no problem with cat-ing a 50MB file).
I combined the functions of shell and terminal because I found the shell/terminal split made some of the functionality I wanted difficult or impossible. One example is that I colour text written to stderr in red - standard shells mix stderr and stdout together before the terminal even sees them.
I decided early on that I would not support terminal escape sequences. I set the TERM environment variable to "dumb" which tells well-behaved programs not to use escape sequences. So you can't run vi/vim in one of my windows, but I always use gvim so I don't find this a problem.
Similarly after some experimentation I decided not to use ptys as they created as many problems as they solved. So programs which change behaviour based on whether they are connected to a terminal behave as if running from a script. Eg. running "man command" lists the whole man page rather than trying to page it - but this is what I want since one can page up/down in the shell anyway.
However it seems that people who use a terminal get very attached to its idiosyncracies and will reject anything even slightly different. Since it's very difficult to make any real improvements without introducing incompatibilies, attempts at improving the terminal/shell user experience rarely catch on. In contrast, a few other tools I have implemented using the same technology have been adopted by a worthwhile user community at work. I think the difference is that they are used for more specialised tasks and don't require the user to change their everyday workflow.
Anyway, good luck with your endeavour!
[+] [-] fibo|10 years ago|reply
. npm install black-screen
is far better t'han "install-all" for many reasons: better npm search, no namespace pollution, more semantic than such a generic name.
Please consider to change it.
[+] [-] JulianWasTaken|10 years ago|reply
[+] [-] tatterdemalion|10 years ago|reply
Just like the web itself, any new teminal client needs to be backwards compatible with the capabilities of prior terminal clients, because programs that run in the terminal expect it. And if your terminal can't run the programs everyone runs in their terminals, no one will adopt your terminal. But many of these projects seem to have no intention of maintaining that backward compatibility. Some, like TermKit, fully conflate the terminal and the shell and even many UNIX utilities.
You can't hope to supplant ANSI compatible terminals when you let them have the enormous advantage of running all the software anyone wants to run in a terminal that already exists. It would be like saying you have a new, better web browser that can't open any existing web pages.
No idea if this particular project has learned from past examples and is backwards compatible or not. (EDIT: It doesn't have a terminfo page, so probably not.)
[+] [-] coldtea|10 years ago|reply
As they say above, this thing would halt when you cat a 50MB file.
It takes someone who's familiar with terminals, and can use a language fit for the task (and without too many depenedencies -- so if you built it in Haskell and I need the Platform and half of Cabal to build it, it will never fly -- and it being in Haskell it will not attrack many UNIX hands, who are the people familiar with Terminals most).
So something like C, C++, Rust or Go.
[+] [-] ibrahima|10 years ago|reply
I guess at least since it's based on Electron, it might have more longevity than something built from a cobbled together base. Here's hoping!
[+] [-] scotchio|10 years ago|reply
Do you --or anyone reading this-- have a list of these? I would love to check them all out actually (not that I don't get your point).
[+] [-] otabdeveloper|10 years ago|reply
Not really, they're just poorly documented. They're based on ad-hoc standards that are scattered across many outdated documents.
It'd be nice if somebody could actually pull all that together and publish one comprehensible document that is readable and up-to-date.
[+] [-] mycelium|10 years ago|reply
I get this error on mac os Yosemite, I made a github issue here: https://github.com/shockone/black-screen/issues/21
[+] [-] tundrax|10 years ago|reply
[+] [-] scotchio|10 years ago|reply
Overall, actually really like the interface and the potential behind it. Super laggy and could use some work.
[+] [-] xnzakg|10 years ago|reply
[+] [-] jolux|10 years ago|reply
[+] [-] shockone|10 years ago|reply
[+] [-] blt|10 years ago|reply
[+] [-] shockone|10 years ago|reply
[+] [-] lazybum|10 years ago|reply
[+] [-] shockone|10 years ago|reply
So, I use a terminal emulators pretty extensively, and I'm tired of their dumbness. Compare any operating system from 1980 and 2015 - there is a huge difference. The same with web-sites, text editors, and pretty much any other category of software. Except terminals. The biggest achievement they made is 256 colours support. Good job!
It doesn't take a genius to understand that the limitations are caused by the text user interface. Of course, text is a great and universal tool. It's easily parsable (or not so easily, but still parsable). It can be piped, after all.
But who said we can't take the good old text and present it beautifully? Imagine you fired an sql client, wrote a select statement and received an ASCII table as an output. Wouldn't it be useful if the terminal understood that it looks like a table and converted it into an HTML table, with sorting by any column, resizing, filtering, and everything else. The same with XML, JSON and every other format: why should I type `jq` after a command that outputs JSON? Is that so hard to just detect and parse it for me?
Output formatters was the idea that made me start the development. I also plan to let users write custom formatting plugins.
But even besides that point there is a lot of room for improvement in current terminal emulators. For example, I have a git branch displayed in RPROMPT of my ZSH. It works well, but if I checkout another branch from a different place, my shell will still show the old branch, which can have certain consequences, if you rely on it.
The current feature I work on is autocompletion. I plan to parse man files and provide only what can be displayed in that place. By the way, folks from the Fish team do the same.
Unfortunately, right now Black Screen can not be used as a replacement for your favourite terminal, it has a long path to the first release.
[+] [-] revelation|10 years ago|reply
[+] [-] to3m|10 years ago|reply
Thanks to people insisting for years that the TTY is just fine, we don't appear have any other options. Ideally, we'd have progress - but as it is, we have nothing, or a shit sandwich. Forgive me for not going for nothing.
[+] [-] landr0id|10 years ago|reply
[+] [-] derefr|10 years ago|reply
[+] [-] nine_k|10 years ago|reply
[+] [-] arcameron|10 years ago|reply
http://acko.net/blog/on-termkit/
looking cool!
[+] [-] eggsome|10 years ago|reply
[+] [-] mamcx|10 years ago|reply
I will love to build a interactive REPL "terminal" for some data tool I'm building, but with a modern native GUI.
[+] [-] eeZi|10 years ago|reply
It lacks readline support, though, and does not implement all VT100 control characters.
[+] [-] rtz12|10 years ago|reply
[+] [-] mycelium|10 years ago|reply
[+] [-] jestinjoy1|10 years ago|reply
[+] [-] epmatsw|10 years ago|reply
[+] [-] chjj|10 years ago|reply
It also looks like it doesn't handle sigchld with a waitpid anywhere, so be prepared to have a zombie apocalypse on your machine.
I'd recommend the author switch to pty.js[1] which now compiles on io.js >=3.0.0 and reads pty fd's properly, but I'm biased.
[1] https://github.com/chjj/pty.js
[+] [-] ilaksh|10 years ago|reply
[+] [-] supster|10 years ago|reply