TTE: Terminal Text Effects(chrisbuilds.github.io)
chrisbuilds.github.io
TTE: Terminal Text Effects
https://chrisbuilds.github.io/terminaltexteffects/showroom/
278 comments
This is awesome. Thanks
Love it, thanks for posting!
Incredibly goofy, I like it. Especially the demo gifs on the page. Wonder how long until I see it be the default output for a CLI I'm using. Got surprised to see someone using lolcat in the wild before.
Great work, this will make a lovely splash screen for my tty-only machine.
In a similar vein in Emacs: M-x zone
Every time you run it, it triggers a random screen saver effect. Fun when it's on a timer and triggers so your work colleagues wonder wth is going on.
Every time you run it, it triggers a random screen saver effect. Fun when it's on a timer and triggers so your work colleagues wonder wth is going on.
dude thanks
Or neovim … cellular automaton
Emacs has game of life also. M-x life.
and animate.el by mister Stallman, see it in action with M-x animate-birthday-present
good one! The editor macros collection never ceases to amaze even after years of working daily in it.
> M-x zone
Available in the menu: Tools → Games → Zone Out
Available in the menu: Tools → Games → Zone Out
Thanks for everything you do for the Emacs community, mickeyp. I've learned so much from https://www.masteringemacs.org/
Next time someone donks Python for being incapable of building decent CLI tools, I'll burn their terminal using TTE.
I know Go has the crown for creating TUI apps, but Python isn't that awful. If the app doesn't need concurrency (like a terminal file manager [0] does), then Python is fine.
[0]: Yazzi (Rust) eats Ranger's (Python) lunch and dinner combined.
I know Go has the crown for creating TUI apps, but Python isn't that awful. If the app doesn't need concurrency (like a terminal file manager [0] does), then Python is fine.
[0]: Yazzi (Rust) eats Ranger's (Python) lunch and dinner combined.
I freaking love this library! It reminds me of a time that I don't even know happened when computers seemed like a scifi possibility come true. So happy to see it on the front page.
One of the coolest things is not just the ability to pipe cat outputs into it, but that it doubles up as a python library- next time you're making a throw away CLI with print outs and prompts, why not make it insanely jazzy?
One of the coolest things is not just the ability to pipe cat outputs into it, but that it doubles up as a python library- next time you're making a throw away CLI with print outs and prompts, why not make it insanely jazzy?
It's fun for silly stuff, but I've definitely been on enough slow links that I wouldn't put it in a serious tool.
EDIT: Don't get me wrong, I think it's really cool, but I wouldn't use it as a universal hammer.
EDIT: Don't get me wrong, I think it's really cool, but I wouldn't use it as a universal hammer.
On the contrary, I am currently scaffolding out the template projects for a new system at $DAYJOB and I'm seriously considering putting it in the CLI tool template.
On the one hand, these tools are going to be used for Serious Business™ but on the other hand... I owe it to 14 year old me. I'll probably add something to allow disabling it with a flag file that can be created with the tool or manually. ¯\_(ツ)_/¯
On the one hand, these tools are going to be used for Serious Business™ but on the other hand... I owe it to 14 year old me. I'll probably add something to allow disabling it with a flag file that can be created with the tool or manually. ¯\_(ツ)_/¯
I love this kind of things the first time I see them but I would hate it in a tool used everyday
./myfancytool -disablefx
./myfancytool -showfx
Or have an "on first run only" configuration that disables it for subsequent usage of the tool ¯\_(ツ)_/¯
./myfancytool -showfx
Or have an "on first run only" configuration that disables it for subsequent usage of the tool ¯\_(ツ)_/¯
[deleted]
[deleted]
I agree, a serious tool should be taking into account the length of the output delay and reducing effects to match the conditions. But you can still do some of it, sometimes.
Someone will add this to their javascript framework cli
Now we need this in esp32 !!
This is great, thanks!
My favorite is Beams (the one at the very top of the page), reminds me of MGS1 “game over” screen animation a lot.
My favorite is Beams (the one at the very top of the page), reminds me of MGS1 “game over” screen animation a lot.
This is cool! we can utilize the 'Burn' or 'ErrorCorrect' effects to highlight warnings or errors in logs dynamically, ensuring critical issues stand out in ongoing terminal output.
No. No, you don't. No one investigating log files wants animations playing in them.
Haha..I get where you're coming from. However, tool that show reports and outputs, that are CLI-first, can get a lot of help in improving the developer experience. Honestly, I was looking for something like this for my tool!
I'm glad to see we all take the same approach to these sorts of things ^_^
self.move_cursor_to_top()
sys.stdout.write(output_string)
sys.stdout.flush()Would there be a more canonical way do do this?
Back in the day (around 1990) I implemented a gif-like effect for terminals, which happened to be old monochrome hardware terminals on slow (9600?) RS-232 ports, attached to a venerable PDP-11.
It took several text files with ASCII "pictures" (character data only, no control codes, 80x24) as animation frames, and calculated simple per-line "diffs". Then it generated a sequence of cursor movements to only update the affected areas, skipping large parts of the picture.
That made it much faster than the naive overwriting the whole screenfuls from top, with a visible delay between parts of the screen. My version was able to run "simultaneous" small animations quickly at distant parts of the screen, because they took very few bytes to navigate to and update.
With current terminals giving you 60fps in true-color mode, it makes little sense, of course.
It took several text files with ASCII "pictures" (character data only, no control codes, 80x24) as animation frames, and calculated simple per-line "diffs". Then it generated a sequence of cursor movements to only update the affected areas, skipping large parts of the picture.
That made it much faster than the naive overwriting the whole screenfuls from top, with a visible delay between parts of the screen. My version was able to run "simultaneous" small animations quickly at distant parts of the screen, because they took very few bytes to navigate to and update.
*
*.
* o/
-/M
_H_
With current terminals giving you 60fps in true-color mode, it makes little sense, of course.
Not redrawing the parts of the screen that don't need to be redrawn. There's going to be a tradeoff between the amount of works the terminal has to do parsing the input stream, the amount of work the terminal has to do to redraw/update its own buffer, and the amount of work necessary in the program to compute the necessary move commands.
IIRC, ncurses does this under the hood.
IIRC, ncurses does this under the hood.
To be fair, the effects shown here update such a significant part of the screen that tracking the diffs might be bigger overhead than a full-screen refresh
This is amazing! Please never ever use it in production.
Idk I wouldn’t mind one or two of these as loading screens or something.
As a developer-only tool, I’m sure most of my coworkers would love the attention to details.
I actually love it.
As a product engineer, I'd love the attention to detail much more when placed toward changes that improve my ability to sustain velocity, than when toward changes that actively cut against that.
What CLI tools have a slow enough boot to require a loading screen? I'm sure there are some but...
The only one that comes to mine for me is FileBot[0] - and if the loading screen made it take ANY additional time, I'd be annoyed.
[0] https://www.filebot.net/
The only one that comes to mine for me is FileBot[0] - and if the loading screen made it take ANY additional time, I'd be annoyed.
[0] https://www.filebot.net/
Deployment scripts are what come to mind for me. I wouldn’t mind a cool loading screen that highlighted problem nodes in the burning font or something when I deploy to dev / test / hell, maybe even prod.
Anything that downloads from somewhere, eg rsync, wget, package managers, etc.
Anything that compresses or decompresses archives, like gzip/gunzip, tar, etc.
Anything that performs longer running recursive disk activities, like du, find, etc
I’m sure there are plenty more scenarios I haven’t thought of. Though to be clear, I definitely don’t want to see this as a default enabled option in any of these.
Anything that compresses or decompresses archives, like gzip/gunzip, tar, etc.
Anything that performs longer running recursive disk activities, like du, find, etc
I’m sure there are plenty more scenarios I haven’t thought of. Though to be clear, I definitely don’t want to see this as a default enabled option in any of these.
If things are working well, they are automated and I rarely see the real time output.
If I’m looking at real time output, it’s because I’m doing something manually because something isn’t working the way it’s supposed to, and I’m in no mood for anything that doesn’t help me understand and address the issue.
This work is impressive. I love it. For some reason I really like “printer.” I’d be all about it for games or toys. But too many tools for real work try to do cute Unicode things or fancy colors or animations. I don’t need it on anything I will ever have to develop or troubleshoot, personally. After the first lengthy wait for a broken container to come up, I’m well over the colorful attitude.
If I’m looking at real time output, it’s because I’m doing something manually because something isn’t working the way it’s supposed to, and I’m in no mood for anything that doesn’t help me understand and address the issue.
This work is impressive. I love it. For some reason I really like “printer.” I’d be all about it for games or toys. But too many tools for real work try to do cute Unicode things or fancy colors or animations. I don’t need it on anything I will ever have to develop or troubleshoot, personally. After the first lengthy wait for a broken container to come up, I’m well over the colorful attitude.
I deliberately mentioned stuff that people are likely to manually run on local and healthy systems. But yeah, I agree with you that the novelty of this stuff wares off quickly.
An example of this done well would be ‘pacman’ package manager where an Easter egg can be enabled to turn the progress bar into a little Pac-Man gobbling pills. It’s not there by default, but it can be enabled if you know how.
Personally, I’m in the same camp as yourself where I’d prefer our tools didn’t have all this cutesy stuff. But people like us seem to be a dying breed.
An example of this done well would be ‘pacman’ package manager where an Easter egg can be enabled to turn the progress bar into a little Pac-Man gobbling pills. It’s not there by default, but it can be enabled if you know how.
Personally, I’m in the same camp as yourself where I’d prefer our tools didn’t have all this cutesy stuff. But people like us seem to be a dying breed.
Not for booting but for processing (downloading files, processing a directory, waiting for an api, etc)
It could be cool for GUI programs, when run from a terminal, to show a terminal loading screen parallel to the gui loading screen. Totally unnecessary, but cool.
No. I still sometimes need to use a TTY over MOSH over a satellite connection.
No.
No.
In the old days, some software would actually check the terminal's baud rate (which you can see with 'stty') and behave differently on slow links. For example, vi would restrict itself to fewer lines of the screen so that drawing a new page didn't take as long.
Although I don't know if much software does it, that should still be possible to do it, so these animations could theoretically be auto-disabled on slow links. (And you could manually override the baud rate in your mosh terminal if necessary since it doesn't really have any other effect in a virtual terminal, not like when using an actual serial port, I mean.)
Although I don't know if much software does it, that should still be possible to do it, so these animations could theoretically be auto-disabled on slow links. (And you could manually override the baud rate in your mosh terminal if necessary since it doesn't really have any other effect in a virtual terminal, not like when using an actual serial port, I mean.)
It shouldn't matter, should it? Mosh keeps the state and only sends the differences. You would miss most of the animations, and there would be the overhead of sending the colouring escape codes (a few percent extra), but other than that, it wouldn't be any slower than an unanimated version that I can see.
Why not?
Imagine that the CLI tool you use most often every day - a compiler, a package manager, like that - adds animations like these in common operations. Now you have to wait for the animation to finish before you can continue your work. How do you feel about that?
Of course it would be obnoxious.
As an "about" screen, or in a opt-in funny theme why not !
As an "about" screen, or in a opt-in funny theme why not !
The idea that anyone would use this during "common operations" is laughable, but as one offs during specific operations, maybe.
> The idea that anyone would use this during "common operations" is laughable
It's been a while since I dared assume anything at all was so obviously absurd that no one could ever think to do it - not least since significant portions of my career to date have consisted of cleaning up after people who had.
It's been a while since I dared assume anything at all was so obviously absurd that no one could ever think to do it - not least since significant portions of my career to date have consisted of cleaning up after people who had.
?? Why would I imagine that? What does this have to do with using animations in production? What you are saying is "how would you feel about using animations in inappropriate places?"
> What does this have to do with using animations in production? What you are saying is "how would you feel about using animations in inappropriate places?"
Production will always be an inappropriate place. QED.
Production will always be an inappropriate place. QED.
I actually did some color animations to status bar of build tool I created while ago.
In my opinion this distracted enough to make build feel faster
Edit: popular example of less invasive animations would be new docker cli, (pulling, buildx build)
Edit: popular example of less invasive animations would be new docker cli, (pulling, buildx build)
Yeah. Animations covering time that'd be spent either way I see no problem with, so long as it's obvious the time would be spent either way. Animations that waste my time, not so much.
Better than either, of course, would be effort spent on speeding up the build in the first place. I realize that's less fun, though.
In general, the critical development path is not a place to thoughtlessly add friction.
Better than either, of course, would be effort spent on speeding up the build in the first place. I realize that's less fun, though.
In general, the critical development path is not a place to thoughtlessly add friction.
Also, I don't want to even imagine how it would look on a SSH connection.
It’s trivial to add in a keypress that short circuits the animation. God, this website is full of the grumpiest people on the planet.
It's not grumpy to prefer function over form in a tool. People optimize for different things. GP's comment is reasonable; they're optimizing for something different than you.
Those of us who live in the terminal do it because it's the fastest, most convenient option, not because it's pretty or to appear 1337. Animations like these get in the way. Cool project, but I would never use it.
[deleted]
[deleted]
Prod should be as robust and straightforward as possible; no distractions, no noise, no extra overhead. This is neat, but not useful, and it adds distractions and delays.
These are beautiful.
What I'd really like to see is this supported in the terminal emulator itself as an idle mode, i.e. don't run this in the buffer directly, but rather as a second buffer. This could function like a "screen saver". Once you interact, your primary terminal would be fully restored.
What I'd really like to see is this supported in the terminal emulator itself as an idle mode, i.e. don't run this in the buffer directly, but rather as a second buffer. This could function like a "screen saver". Once you interact, your primary terminal would be fully restored.
I was thinking about how fun it would be to add this my Python CLI [0] I made for launching Fedora CoreOS locally with QEMU for testing ignition, but with a flag that is turned off by default. Using the burn effect in TTE when launching a VM with my CLI would be so cool.
This instantly reminded me about Ansible and how it annoyed me that ANSIBLE_NOCOWS had to be enabled to disable the default output of Ansible with cowsay [1].
[0]: https://github.com/quickvm/bupy
[1]: https://github.com/ansible/ansible/issues/10530
This instantly reminded me about Ansible and how it annoyed me that ANSIBLE_NOCOWS had to be enabled to disable the default output of Ansible with cowsay [1].
[0]: https://github.com/quickvm/bupy
[1]: https://github.com/ansible/ansible/issues/10530
On a further tangent, that reminds me of two of my favorite things to install on a Linux system, ponysay and ascii-pony/systempony. I set each of my systems to a different character to show on bash logins with systempony (WSL instances included)
https://github.com/erkin/ponysay
https://blog.yjl.im/2016/01/ascii-pony-systempony-screenshot...
https://github.com/erkin/ponysay
https://blog.yjl.im/2016/01/ascii-pony-systempony-screenshot...
A while back I install ponysay on one of my servers, and put fortune | ponysay in the .bashrc, so I get a quip from a random mlp pony whenever I log in. Brightens my day a little
Hot damn, I have to respect the author for shutting down any attempt to make him give in to the pressure.
All these serious enterprise people worried about their cows, but then they do install ‘cowsay’ on their systems xD
All these serious enterprise people worried about their cows, but then they do install ‘cowsay’ on their systems xD
The people complaining probably don't have the authority to remove it from the base image they're forced to use, unfortunately.
How serious can your enterprise be if they install cowsay on their base image?
Please use this to reboot Trade Wars 2002.
You do not know how my production looks like. I _will_ use it in production!
Who wants to actually read text anyway.
all my run books use this
I propose that developers are allowed to use it in production... so long as they do all the development work on a 9600 baud dialup with a VT102.
A few years ago, a submarine cable was knocked out, between our startup's MVP servers in Singapore AWS, and our networked factory stations in Asia.
In lieu of the submarine cable, something closer to a wet string was being routed over. It had such high latency and packet loss, that a watchdog timer I'd implemented on the stations was timing out.
Fortunately, the remote access we'd built into our stations (SSH and OpenVPN) still worked, albeit at slow speeds, like a 300 baud dialup, and crazy-high latency.
Having occasionally dealt with performance a bit like that as a kid, and knowing my way around Linux, it was like "I've been training my whole life for this moment."
So I just flexed the old command-line-and-editor-when-you-feel-every-byte-transmitted skill, and got the stations working, before the factory even knew about the submarine cable, saving our infinite-9s uptime.
It was nothing compared to what NASA does, but terminal animation effects would've ended both of our missions.
In lieu of the submarine cable, something closer to a wet string was being routed over. It had such high latency and packet loss, that a watchdog timer I'd implemented on the stations was timing out.
Fortunately, the remote access we'd built into our stations (SSH and OpenVPN) still worked, albeit at slow speeds, like a 300 baud dialup, and crazy-high latency.
Having occasionally dealt with performance a bit like that as a kid, and knowing my way around Linux, it was like "I've been training my whole life for this moment."
So I just flexed the old command-line-and-editor-when-you-feel-every-byte-transmitted skill, and got the stations working, before the factory even knew about the submarine cable, saving our infinite-9s uptime.
It was nothing compared to what NASA does, but terminal animation effects would've ended both of our missions.
How exactly did you get the stations working? Be specific.
"Be specific" sounds like a high-stakes interview, so I'd better answer. :)
* SITUATION: Factory reports MVP factory stations for pilot customer "not turning on" for the day, reason unknown.
* TASK: Get stations up in time for production line, so startup doesn't go out of business.
* ACTION: Determined cause was unexplained networking problem outside our control, and that was triggering some startup time checks. But that the stations were resilient enough that I could carefully edit the code on the stations to relax some timeouts, and enough packets were getting through that we might be able to operate anyway. After that worked for one station, carefully changed the remaining ones.
* RESULT: Factory stations worked for that production day, and our startup was therefore still in business. We were later advised of the submarine cable failure, and the factory acknowledged connectivity problems. Our internal post mortem discussions included why the newer boot code hadn't been installed, and revisiting backup connectivity options. From there, thanks to various early-startup engineering magic, and an exciting mix of good and bad luck, we eventually finished a year contract in a high-quality brand's factory production line successfully.
No technical wizardry in the immediate story, but a lot of various smart things we'd done proactively (including triaging what we did and didn't spend precious overextended time on), plus some luck (and of course the fact that some Internet infrastructure heroes' work had them routing any packets at all)... all came together... and got us through a freak failure of a submarine cable we'd never heard of, which could've ended our startup right there.
(Details on Action, IIRC: Assumed command of the incident, and activated Astronaut Mode manner. Attempted to remote access, and found network very poor. Alerted factory of network problem in their connectivity to AWS Singapore, but they initially thought there was no problem. Could tell there was some very spotty connectivity problems (probably including using `mtr-tiny`), so focused troubleshooting stations on that assumption. Realized how the station would behave in this situation, and that the boot-ish checks for various network connectivity were probably timing out. Or, less likely, there could be a bug in handling the exceptional situation. Investigating, very slowly due to poor Internet, found that the stations didn't have the current version of the boot code, which would've reported diagnostics better on the station display, so factory personnel might see it and tell us. Using `vi`, made careful, minimal changes to the timeouts directly on one station, in the old version of the the code on there (in either Python or Bash; I forget). Restarted station, and it worked. Carefully did the same to the other stations. Everything worked, and other parts of the station software had been done smart enough that they could cope with the production day's demands. Despite the poor connectivity, and the need to do network requests for each production item that passed through the station, before it could move on.)
* SITUATION: Factory reports MVP factory stations for pilot customer "not turning on" for the day, reason unknown.
* TASK: Get stations up in time for production line, so startup doesn't go out of business.
* ACTION: Determined cause was unexplained networking problem outside our control, and that was triggering some startup time checks. But that the stations were resilient enough that I could carefully edit the code on the stations to relax some timeouts, and enough packets were getting through that we might be able to operate anyway. After that worked for one station, carefully changed the remaining ones.
* RESULT: Factory stations worked for that production day, and our startup was therefore still in business. We were later advised of the submarine cable failure, and the factory acknowledged connectivity problems. Our internal post mortem discussions included why the newer boot code hadn't been installed, and revisiting backup connectivity options. From there, thanks to various early-startup engineering magic, and an exciting mix of good and bad luck, we eventually finished a year contract in a high-quality brand's factory production line successfully.
No technical wizardry in the immediate story, but a lot of various smart things we'd done proactively (including triaging what we did and didn't spend precious overextended time on), plus some luck (and of course the fact that some Internet infrastructure heroes' work had them routing any packets at all)... all came together... and got us through a freak failure of a submarine cable we'd never heard of, which could've ended our startup right there.
(Details on Action, IIRC: Assumed command of the incident, and activated Astronaut Mode manner. Attempted to remote access, and found network very poor. Alerted factory of network problem in their connectivity to AWS Singapore, but they initially thought there was no problem. Could tell there was some very spotty connectivity problems (probably including using `mtr-tiny`), so focused troubleshooting stations on that assumption. Realized how the station would behave in this situation, and that the boot-ish checks for various network connectivity were probably timing out. Or, less likely, there could be a bug in handling the exceptional situation. Investigating, very slowly due to poor Internet, found that the stations didn't have the current version of the boot code, which would've reported diagnostics better on the station display, so factory personnel might see it and tell us. Using `vi`, made careful, minimal changes to the timeouts directly on one station, in the old version of the the code on there (in either Python or Bash; I forget). Restarted station, and it worked. Carefully did the same to the other stations. Everything worked, and other parts of the station software had been done smart enough that they could cope with the production day's demands. Despite the poor connectivity, and the need to do network requests for each production item that passed through the station, before it could move on.)
I love the five point order-esque style, warms my military heart
I think my first action in a situation like that would be an attempt to install mosh from a local mirror.
That needs a binary to run on the remote host for protocol support, doesn't it? I wonder how long that'd take to get transferred and running, over as slow a link as it sounds like this was.
Since you can reach the host, presumably it has some kind of access to system updates / packages. In that case, ideally you paste a command like "sudo apt update && sudo apt install -y mosh\n" or something. You can even paste the newline at the same time and save a round-trip.
"from a local mirror" does not involve transferring the binary over the slow link.
It isn't perfectly clear even in the detailed description whether any other link was available, but I tend to suspect that if anything faster had been, then it would have been used in preference to the one that actually was.
It's a cable going between entire countries that got cut. Anything inside the country should still be full speed.
There is no link that could be used in preference. Any repo that the factory stations could access would be unusable by Singapore AWS. And any repo that Singapore AWS could access would be unusable by the factory stations. But the two ends of the link don't have to use the same repo.
There is no link that could be used in preference. Any repo that the factory stations could access would be unusable by Singapore AWS. And any repo that Singapore AWS could access would be unusable by the factory stations. But the two ends of the link don't have to use the same repo.
I did something similar once when something broke while I was on a plane. The plane wifi was blocking ssh (I HATE when they do this) so I opened up an existing digital ocean instance, sshed into my home computer from it via the web interface, then uploaded some large files from the home computer and did a kubectl apply. The latency was insane but luckily the file upload was fast since my home connection is fast.
It was fun to think about the path each packet was taking - from my laptop to the plane router, to a satellite, back to a digital ocean computer in the UK, to my home computer in NJ, and back. It wasn’t as bad when you think about the magic there.
It was fun to think about the path each packet was taking - from my laptop to the plane router, to a satellite, back to a digital ocean computer in the UK, to my home computer in NJ, and back. It wasn’t as bad when you think about the magic there.
Smart, and not something someone would realize if they'd been too insulated from how things work.
Regarding planes/cafes/guest/etc. WiFi, I now usually put any "emergency remote plumbing access" on port 443 (though usually not HTTPS), to reduce the likelihood of some random non-SPI ruleset blocking us in an emergency.
Regarding planes/cafes/guest/etc. WiFi, I now usually put any "emergency remote plumbing access" on port 443 (though usually not HTTPS), to reduce the likelihood of some random non-SPI ruleset blocking us in an emergency.
You can also proxy 443 out with ssh.
Or setup a web ssh client and actually run HTTPS over port 443.
I think that by 2050, 443 will be the only port used by applications that require a non local connection, because the chance that some participant in the network has blocked any other port is simply too high.
Future generations will ask - “why does every packet header have this 2 byte reserved field with a fixed value of 01BB?”
It would truly have been elite if you'd have to pull out Kermit and use that.
"line is ~300 baud but only transmitting 7 bit but we need to send this critical file.. which is in EBCDIC!"
"line is ~300 baud but only transmitting 7 bit but we need to send this critical file.. which is in EBCDIC!"
I'm very glad that TCP is so robust.
I'd take a solid 300 baud connection over a spotty cellular connection during most emergencies.
Having worked and played on flaky high-latency and low-throughput networks much of my life, I mostly visualize things in my head—as you likely mean by 'command-line-and-editor-when-you-feel-every-byte-transmitted'. Open a connection and queue your commands; wait for output. It works if you don't make any typos.
Preferably, when the connection is too slow or flaky (bad cellular), I make a local script and echo the script to be executed remotely to a file on the remote server, and then execute it with nohup - with the input to create the script and execute it coming from a pre-made file on my local machine redirected to SSH.
Bad cellular often works in bursts, in my experience. Also, redirect output to a file if needed.
This works nicely in situations where your connection may drop frequently for periods exceeding timeouts. On that note, keep ssh timeouts high. With really spotty cellular you might have the network drop for 5-15 minutes between reliable transmissions. SSH connections can stay alive nearly indefinitely if the timeouts allow for it and IP address don't change.
I'd take a solid 300 baud connection over a spotty cellular connection during most emergencies.
Having worked and played on flaky high-latency and low-throughput networks much of my life, I mostly visualize things in my head—as you likely mean by 'command-line-and-editor-when-you-feel-every-byte-transmitted'. Open a connection and queue your commands; wait for output. It works if you don't make any typos.
Preferably, when the connection is too slow or flaky (bad cellular), I make a local script and echo the script to be executed remotely to a file on the remote server, and then execute it with nohup - with the input to create the script and execute it coming from a pre-made file on my local machine redirected to SSH.
Bad cellular often works in bursts, in my experience. Also, redirect output to a file if needed.
This works nicely in situations where your connection may drop frequently for periods exceeding timeouts. On that note, keep ssh timeouts high. With really spotty cellular you might have the network drop for 5-15 minutes between reliable transmissions. SSH connections can stay alive nearly indefinitely if the timeouts allow for it and IP address don't change.
> local script [...] nohup [...] redirect output to a file
> It works if you don't make any typos
mosh helps a bit with that too: you get local predictive echo of your keystrokes and you can't "recall" keystrokes but you can queue up backspaces to cover up your typos. Doesn't help where a single typo-ed keystroke is a hotkey that does something you didn't want, though.
mosh hostname -- screen -S philsnow
> It works if you don't make any typos
mosh helps a bit with that too: you get local predictive echo of your keystrokes and you can't "recall" keystrokes but you can queue up backspaces to cover up your typos. Doesn't help where a single typo-ed keystroke is a hotkey that does something you didn't want, though.
If you ever find yourself needing to tunnel via DNS, try iodine: https://github.com/yarrick/iodine
Mosh looks handy. Thanks for sharing!
Nothing like typing in an ssh prompt and each time you press a button on the keyboard you have to wait a few seconds for the char to appear on the screen, because it has to go to the server and back first... that't the true "blind typing" :)))
TERM=dumb seems like a good idea in a situation like that.
I actually am getting a VT320 soon that I hope to be able to use for my terminal at work. I'll run these over it if I remember.
It won't work. It assumes 24-bit colour support, even if you have `TERM=vt320` or something else without it.
Damn, just a programming oversight? You don't need colors to get a lot of these effects. Maybe I'll fork it.
There’s a —no-color argument.
Example: ls | tte —no-color slide
I’ll add environment variable checks to the todo list.
Example: ls | tte —no-color slide
I’ll add environment variable checks to the todo list.
It can work we just need brave soul to make it client side.
Agreed. It's not nearly as battle-tested as key operations tooling like `sl` and `gti`.
Uh, we accidentally shipped it as our fintech startup screen.
Please do use it in demoscene productions. We need more textmode demos.
It would be great for the startup screens of terminal games.
Challenge accepted.
It'd be good if it recognised https://no-color.org/ and just didn't do anything. Or maybe replaced with <cool effect removed here>
Maybe it does, I didn't check.
Maybe it does, I didn't check.
But if you do, include emoji animations
I'd love to use it while teaching.
[deleted]
> ./myfancytool -nofx -doingbusiness -pwn "the_ops"
These effects remind me of some of the first programming I ever did: animated ASCII art for local BBS’s.
I remember dumping an entire day into something resembling Spider-Man. Was very exciting when a sysop put my work into their login sequence.
I remember dumping an entire day into something resembling Spider-Man. Was very exciting when a sysop put my work into their login sequence.
Reminds me of the drip.com TSR program that I put on some of the school computers circa 1990.
Yeah in 1991 our college lab's MSDOS PC's were unsecured (unsecurable!?), so our prof quickly learned to regret teaching us how to write TSR's in ASM.
Ours had PS-2s on a token ring network with a TUI to get to the word processor etc but it also had a “drop down to DOS” option that the teachers didn’t know about.
oh how fun this must have been to implement these effects. absolutely love it!
So much energy going into the command line/terminal at the moment. Reminds me a lot of BBS art of my youth. Where are my TheDraw crew?
Kind of tools I wish I had a use case for.
Wow, this is astonishing!
All gorgeous, but I'd like to see more quick/simple ones like 'Expand' because the slower ones would probably become tedious real quick after the initial novelty wears off.
Dev here: I agree, it's actually a line item in my todo list. That being said, many of them can be made to be very quick via command line arguments without losing the spirit of the effect.
That's a delightful thing you've made.
Have you added a command-line switch for the direction of gravity?
Some of the animations (eg Pour), could fall up the screen instead of down it. That way, the user can start reading the text immediately.
Have you added a command-line switch for the direction of gravity?
Some of the animations (eg Pour), could fall up the screen instead of down it. That way, the user can start reading the text immediately.
ls -latr | tte pour --pour-direction up
I have not implemented gravity, haha. I have actually worked on a custom terminal game engine in the past and realized with TTE I am very small amount of scope creep away from landing in that territory again. I promised myself I will not implement physics or collision. Keeping it simple. That being said, as with the example pour syntax above, all of the effects have a ton of config options to allow for most obvious variations.
I have not implemented gravity, haha. I have actually worked on a custom terminal game engine in the past and realized with TTE I am very small amount of scope creep away from landing in that territory again. I promised myself I will not implement physics or collision. Keeping it simple. That being said, as with the example pour syntax above, all of the effects have a ton of config options to allow for most obvious variations.
I thought there might be one :)
3d... 3d... 3d... you know you want to.
3d... 3d... 3d... you know you want to.
Chalk maintainer here. These are incredible. Some of the best I've ever seen. Kudos.
What magic sorcery are you using here!?!
Bravo!
Bravo!
brings the magic of an ANSI BBS to your terminal and more
Exactly what I was thinking. Used to make ANSI animation with THEDRAW back in the day
This is so cool. Thanks for this.
The descriptions are fun. So it needs the "Bounty Bob Stikes Back!" effect: birds deliver each letter, then stand proudly on top of the sign:
https://www.youtube.com/watch?v=18n-MBlVIvw
https://www.youtube.com/watch?v=18n-MBlVIvw
Oh, I like this. It’s going on the list of ideas. Thanks.
truly l337
This is awesome. I'm like 99% sure I saw some of these effects in some of my late-80's CRPG type games :)
It looks like the color gradient is per-pixel, not per-character. Would anyone have any idea how the package does that?
It looks like the color gradient is per-pixel, not per-character. Would anyone have any idea how the package does that?
Barring a zoomed screenshot that shows otherwise, I'm quite certain it's per-character. Operating in true color mode is what makes the color transitions smooth enough to make the optical illusion work.
Dev here: You are correct. It's using 24-bit color ANSI escape codes.
https://en.wikipedia.org/wiki/ANSI_escape_code#24-bit
https://en.wikipedia.org/wiki/ANSI_escape_code#24-bit
fucking amazing
[deleted]
Rather reminds me of Nick Black's Notcurses library.
https://nick-black.com/dankwiki/index.php/Notcurses
https://github.com/dankamongmen/notcurses
https://nick-black.com/dankwiki/index.php/Notcurses
https://github.com/dankamongmen/notcurses
Amazing, does this type of thing exist for like my website that i can use in a css or something i can import? What a cool style... or if it doesn't exist how might we make something like that?
Wow - this is very cool and gives me strong nostalgia for Commodore-64/128 demos and old-school BBS's. I remember spending hours on my Commodore 64 doing this sort of thing by hand for the little BBS that I ran out of my bedroom.
If ascii art animation brings joy to you, you might enjoy “BB: the portable demo”. On Debian, it's `sudo apt install bb` I think.
No "The Matrix" effect? That was one of the earliest programs I wrote back in 2000, and I was so proud of myself.
I can tell I'm too old now because I expected the Matrix projection to be in the first four examples and it's not even on the page.
It's not me that's too old, it's the world that's too young.
I was hoping for the "no more secrets" effect.
https://www.youtube.com/watch?v=F5bAa6gFvLs
https://www.youtube.com/watch?v=F5bAa6gFvLs
Peace on Earth, and goodwill toward men.
I'll see what I can do.
I'll see what I can do.
The decrypt effect is a faithful recreation of that exact scene at the 45 second mark. Just different colors, which can be set.
Here it is with adjusted colors:
ls -latr | tte decrypt --ciphertext-colors 808080 --final-gradient-stops 1e90ff
Here it is with adjusted colors:
ls -latr | tte decrypt --ciphertext-colors 808080 --final-gradient-stops 1e90ff
TTE dev here:
Haha, a matrix effect is actually in progress. I want it to be as close to the original as possible. Most implementations actually miss some subtle details. I've watched the original effect in a clip repeatedly and it has surprised me with its complexity beyond what I originally thought. Sometimes the characters shift in place but other times the entire column drops. The top characters in a given column change brightness in interesting ways, too. It'll be in a future release, for sure.
Haha, a matrix effect is actually in progress. I want it to be as close to the original as possible. Most implementations actually miss some subtle details. I've watched the original effect in a clip repeatedly and it has surprised me with its complexity beyond what I originally thought. Sometimes the characters shift in place but other times the entire column drops. The top characters in a given column change brightness in interesting ways, too. It'll be in a future release, for sure.
Looks amazing!
Does anyone know why the "ColorShift" style doesn't animate as shown? When I run this each row cycles through colors from top to bottom, but there is no left to right / right to left color change at all. That's the only style not rendering correctly among 10 different ones I tried.
I tried with iTerm2 and Terminal app.
Does anyone know why the "ColorShift" style doesn't animate as shown? When I run this each row cycles through colors from top to bottom, but there is no left to right / right to left color change at all. That's the only style not rendering correctly among 10 different ones I tried.
I tried with iTerm2 and Terminal app.
Now this is the kind of stuff I want to see more of on HN. Really cool!
I'm imagining several genres of text based adventures that could make very good use of this library. Cyberpunk, fantasy, and horror.
Very subtle uses of this could go a long way.
Very subtle uses of this could go a long way.
Would love to see a falling sand simulator- many of the effects look like great candidates for making it feel satisfying.
I integrated this[1] with my MOTD on ssh login.. :) With random effect each time.
1: https://keeb.dev/static/login.mp4
1: https://keeb.dev/static/login.mp4
looks both cool and frustrating :)
It would be if I logged in a lot! and you can always ctrl+c if you're in a hurry.
Cool use case! How do you make it choose a random effect?
I wrote a simple shell script which does it for me
This is super cool
getting this into my production system now ...
I also integrated on my ssh server. try sshing to funky.nondeterministic.computer
Well played…
I enjoyed that!
Wonderful.
Kudos to you.
you beautiful bastard... i knew what was going to happen, had multiple chances to not do it, but i just had to see it through...
How do you do that? If possible share the script please..
You can do something like:
printssh() {
tte --input-file YOUR_FILE --frame-rate=500 $(echo "beams binarypath blackhole bouncyballs bubbles burn colorshift crumble decrypt errorcorrect expand fireworks middleout orbittingvolley overflow pour print rain randomsequence rings scattered slice slide spotlights spray swarm synthgrid unstable vhstape waves wipe" | tr ' ' '\n' | shuf -n 1)
ssh "$@"
}
alias ssh="printssh"Anything in your ~/.bashrc or ~/.zshrc gets executed in sequence, so at the bottom of it I have
/home/keeb/code/projects/login/motd.sh
#!/usr/bin/env zsh
values=("bubbles" "slide" "beams" "rain" "pour" "synthgrid" "unstable" "poop")
len=${#values[@]}
index=$(( (RANDOM % (len - 1)) + 1 ))
selected=${values[$index]}
cat /home/keeb/code/projects/login/motd | tte $selectedCan't wait to find these in TV shows!
Yeah, I can see some "hacker" using Decrypt effect.
It's straight out of Sneakers (1992).
https://www.youtube.com/watch?v=GS3npSv8iuM
Anyone want to shut down the Federal Reserve?
https://www.youtube.com/watch?v=GS3npSv8iuM
Anyone want to shut down the Federal Reserve?
Anybody want to crash a couple of passenger jets?
"Why's everyone upvoting some article about text? ... OMG I LOVE THIS."
That's brilliant. I love it. This is the kind of whimsical thing done purely for the love of it that makes my day.
That's brilliant. I love it. This is the kind of whimsical thing done purely for the love of it that makes my day.
One of the most pleasing things I've seen in a long, long while.
Part of me hopes this reignites a new era of scareware. The other part says wow this would be really cool for a SSH banner
nickstinemates already beat you to it [1]
[1] https://keeb.dev/static/login.mp4
[1] https://keeb.dev/static/login.mp4
I want this in charm.sh
Reminds me of my old geocities site when I was a kid. Copy and pasted HTML from many websites to get that "hax0r" feel.
Now I can get that nostalgia in my terminal
Now I can get that nostalgia in my terminal
Very cool! But I’m just a bit sad that this is “just” a set of effects implemented on top of the same old standard ANSI escape codes as primitives.
I’ve been waiting for one or more terminal emulators to get together and add some ridiculous new escape codes, such that animated effects (or things like collapsible sections, font size, “form-input-ness” and “form-button-ness” ala 3270, etc) all get treated as part of the state of a given character cell / run of character cells.
Heck, it’s 2024; an application should be able to use an escape code to set a soft-word-wrap mode for longer-than-viewport-width text, and have the TTY render text accordingly, rather than everything being hard-wrapped (baked mode) or not wrapped at all (raw mode) and only being able to get soft-wrapping using a pager!
(There’s precisely one thing like this I’m aware of terminal emulators adding in recent memory: clickable links, ca. six years ago.)
I’ve been waiting for one or more terminal emulators to get together and add some ridiculous new escape codes, such that animated effects (or things like collapsible sections, font size, “form-input-ness” and “form-button-ness” ala 3270, etc) all get treated as part of the state of a given character cell / run of character cells.
Heck, it’s 2024; an application should be able to use an escape code to set a soft-word-wrap mode for longer-than-viewport-width text, and have the TTY render text accordingly, rather than everything being hard-wrapped (baked mode) or not wrapped at all (raw mode) and only being able to get soft-wrapping using a pager!
(There’s precisely one thing like this I’m aware of terminal emulators adding in recent memory: clickable links, ca. six years ago.)
"Ask HN: Recommendations for Good TUI Libraries (Text User Interface)?"
93 points by andrewstuart on Sept 8, 2020 | hide | past | favorite | 63 comments
https://news.ycombinator.com/item?id=24412687
93 points by andrewstuart on Sept 8, 2020 | hide | past | favorite | 63 comments
https://news.ycombinator.com/item?id=24412687
> (There’s precisely one thing like this I’m aware of terminal emulators adding in recent memory: clickable links, ca. six years ago.)
And they are often disabled by default, as a potential security risk. We don't get to have fun things, do we? (also worth read: CVE-2003-0063, abusing escape seq is unfortunately a valid concern against adding more stuff).
On the other hand, more and more emulators are adding support for various graphic protocols (sixel, iTerm2 format, kitty format).
> I’ve been waiting for one or more terminal emulators to get together and add some ridiculous new escape codes[...]
Well, it's not much, but mintty apparently has some interesting stuff like audio support[0], and codes for font size and font family[1][2].
iTerm2 also has a bunch of custom escape sequences of varying level of usefulness starting from displaying fireworks animation on cursor position to sending system notifications[3] (although sadly I could not get the last one to work for me).
For some semblance of forms, you can check bubbles[4] and gum[5] (binary to easily incorporate the components into shell scripts).
[0]: https://github.com/mintty/mintty/wiki/CtrlSeqs#audio-support
[1]: https://github.com/mintty/mintty/wiki/CtrlSeqs#font-size
[2]: https://github.com/mintty/mintty/wiki/Tips#alternative-fonts
[3]: https://iterm2.com/documentation-escape-codes.html
[4]: https://github.com/charmbracelet/bubbles
[5]: https://github.com/charmbracelet/gum
And they are often disabled by default, as a potential security risk. We don't get to have fun things, do we? (also worth read: CVE-2003-0063, abusing escape seq is unfortunately a valid concern against adding more stuff).
On the other hand, more and more emulators are adding support for various graphic protocols (sixel, iTerm2 format, kitty format).
> I’ve been waiting for one or more terminal emulators to get together and add some ridiculous new escape codes[...]
Well, it's not much, but mintty apparently has some interesting stuff like audio support[0], and codes for font size and font family[1][2].
iTerm2 also has a bunch of custom escape sequences of varying level of usefulness starting from displaying fireworks animation on cursor position to sending system notifications[3] (although sadly I could not get the last one to work for me).
For some semblance of forms, you can check bubbles[4] and gum[5] (binary to easily incorporate the components into shell scripts).
[0]: https://github.com/mintty/mintty/wiki/CtrlSeqs#audio-support
[1]: https://github.com/mintty/mintty/wiki/CtrlSeqs#font-size
[2]: https://github.com/mintty/mintty/wiki/Tips#alternative-fonts
[3]: https://iterm2.com/documentation-escape-codes.html
[4]: https://github.com/charmbracelet/bubbles
[5]: https://github.com/charmbracelet/gum
> And they are often disabled by default, as a potential security risk.
Well, that and a clickable link would conflict with mouse reporting if both were active at once.
Given that mouse reporting exists, and "has precedence" due to its age, I think iTerm's choice — to style the anchor-SGR text either way, but to only make them actually act like links rather than text if you hold a modifier key — is the only "correct" behavior for rendering anchor-SGR text, regardless of security concerns.
But that really wouldn't be true for most other potential novel graphical-rendition "styles." Anything that's non-interactive could certainly be on by default.
Well, that and a clickable link would conflict with mouse reporting if both were active at once.
Given that mouse reporting exists, and "has precedence" due to its age, I think iTerm's choice — to style the anchor-SGR text either way, but to only make them actually act like links rather than text if you hold a modifier key — is the only "correct" behavior for rendering anchor-SGR text, regardless of security concerns.
But that really wouldn't be true for most other potential novel graphical-rendition "styles." Anything that's non-interactive could certainly be on by default.
> [...] waiting for one or more terminal emulators to get together and add some ridiculous new escape codes [...]
I'm definitely of the opinion[0] that we haven't yet reached the limits of the "terminal emulator" UX paradigm.
The past few years do seem to have seen a resurgence in terminal emulator innovation due in part to a combination of new languages, the prevalence of GPUs, and a realisation that many of the existing terminal emulators weren't interested in any innovation in certain directions.
I've particularly been interested in the possibilities provided by the Terminal Graphics Protocol (which I discuss more in the linked comment).
A couple of years ago I switched to WezTerm[2] due to a combination of its graphics support, implementation language (Rust) and that its main developer seems to be interested in a combination of both solid support for existing standards & opportunities for innovation.
WezTerm also provides opportunities for customisation both in terms of shell integrations and of the application itself[3].
> [...] new escape codes [...]
Also, on this aspect, it may not even be necessary to create new escape codes--recently I discovered the `terminfo(5)` man page actually makes a pretty interesting read[7], in part because it lists some existing escape codes that seem like they have potential for re-use/re-implementation in the current day's more graphic-based systems.
---- footnotes ----
[0] As I mentioned in a recent comment on a thread[1] here:
"Motivated by the thought that at the current point in time perhaps the 'essence' of a 'terminal' is its linear 'chronological' presentation of input/interaction/output history rather than its use of 'text'."
[1] https://news.ycombinator.com/item?id=40475538
[2] https://wezfurlong.org/wezterm/
[3] While I'm definitely not a fan of the choice of Lua as the extension language, I have now at least hit my head against the wall[4] with it enough that I can actually get more complex custom functionality working.
[4] I've started to write up some of my Lua-related[5] notes & more general WezTerm[6] notes so hopefully it'll eventually be an easier road for others. :)
[5] https://gitlab.com/RancidBacon/floss-various-contribs/-/blob...
[6] https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...
[7] As one does. :) It was a fascinating/amusing time capsule in terms(!) of mentions of weird hardware terminal quirks that at one time ("before my time") needed to be worked around; interesting escape code discoveries; and, the mention of a term I had not thought of for decades but was at one time of importance: NLQ! :D
I'm definitely of the opinion[0] that we haven't yet reached the limits of the "terminal emulator" UX paradigm.
The past few years do seem to have seen a resurgence in terminal emulator innovation due in part to a combination of new languages, the prevalence of GPUs, and a realisation that many of the existing terminal emulators weren't interested in any innovation in certain directions.
I've particularly been interested in the possibilities provided by the Terminal Graphics Protocol (which I discuss more in the linked comment).
A couple of years ago I switched to WezTerm[2] due to a combination of its graphics support, implementation language (Rust) and that its main developer seems to be interested in a combination of both solid support for existing standards & opportunities for innovation.
WezTerm also provides opportunities for customisation both in terms of shell integrations and of the application itself[3].
> [...] new escape codes [...]
Also, on this aspect, it may not even be necessary to create new escape codes--recently I discovered the `terminfo(5)` man page actually makes a pretty interesting read[7], in part because it lists some existing escape codes that seem like they have potential for re-use/re-implementation in the current day's more graphic-based systems.
---- footnotes ----
[0] As I mentioned in a recent comment on a thread[1] here:
"Motivated by the thought that at the current point in time perhaps the 'essence' of a 'terminal' is its linear 'chronological' presentation of input/interaction/output history rather than its use of 'text'."
[1] https://news.ycombinator.com/item?id=40475538
[2] https://wezfurlong.org/wezterm/
[3] While I'm definitely not a fan of the choice of Lua as the extension language, I have now at least hit my head against the wall[4] with it enough that I can actually get more complex custom functionality working.
[4] I've started to write up some of my Lua-related[5] notes & more general WezTerm[6] notes so hopefully it'll eventually be an easier road for others. :)
[5] https://gitlab.com/RancidBacon/floss-various-contribs/-/blob...
[6] https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...
[7] As one does. :) It was a fascinating/amusing time capsule in terms(!) of mentions of weird hardware terminal quirks that at one time ("before my time") needed to be worked around; interesting escape code discoveries; and, the mention of a term I had not thought of for decades but was at one time of importance: NLQ! :D
> [0] As I mentioned in a recent comment on a thread[1] here:
> "Motivated by the thought that at the current point in time perhaps the 'essence' of a 'terminal' is its linear 'chronological' presentation of input/interaction/output history rather than its use of 'text'."
I somewhat object to this.
If you think of a TTY/PTY as an Abstract Data Type, it's a very specific (and clever) one. It's not just a transcript of bytes that flowed through the wire.
Rather, a TTY/PTY is five distinct but inter-related things:
1. a (passive) character-cell viewport grid, of (at any given time) a fixed size, where each cell holds not only a character as data, but also a set of metadata/annotations attached to it (the particular metadata being dependent on the implementation)
2. an active "brush" state for the viewport grid — this includes things like a cursor position, an active foreground and background color, etc.
3. a byte pipe "but better" — in that it's actually a multi-subscriber byte message-queue, plus (only in baked mode) message persistence into an expandable ring buffer, with logical line-oriented consumer-group cursoring to trigger forward-truncation of said buffer
4. a rendering agent with a rendering ruleset (or, in old-school TTY terms, a "line discipline") that sits as one consumer of the byte pipe; reacts to characters in the byte pipe by writing them to the cursor position in the viewport grid; and reacts to in-band messages by manipulating the "brush", making big changes to the viewport grid (e.g. clearing it entirely), and/or swapping out the rendering ruleset itself
5. (the part everyone forgets about) a replay stream-conversion function, that can convert the current state of the viewport grid + its brush, into a stream of characters + in-band messages, such that the rendering agent would parse that stream back into the current viewport + brush state
The clever function you get from this set of components, can be seen in the case of attaching a "client" TTY/PTY to an existing persistent "server" TTY/PTY, such as is created by something like tmux or docker — or even by /bin/login on an old-school terminal server that you've dialed into.
When a client like telnet, ssh, docker-exec, tmux-attach, etc. attaches to an existing backing PTY (either locally or remotely), the client either establishes its own "replica PTY" or reuses the one it's running attached to, and then wants to establish replication from the backing PTY into this replica PTY.
To get a coherent replica, that doesn't just paint garbage at a random position with a random brush, several things need to happen:
• the client needs to reset its own local PTY a known-neutral brush state;
• the client needs to set an ACK position in the byte-stream, and a memorized brush state, for the remote PTY (usually both of these are done implicitly by the syscall on the remote end that opens the PTY for reading);
• the client needs to fetch from the backing PTY, an implementation-neutral byte stream representing the current contents of the character viewport grid of the PTY — and replay that (i.e. it needs to trigger the replay stream-conversion function) — this also happens implicitly, such that when the remote end open(2)s its its PTY, the current state is serialized and dumped into a buffer for read(2)s on the PTY to read;
• the client needs to set up its local terminal's brush to match the memorized one that was set as of its ACK position on the remote.
Once these four things happen, the client can in theory simply shunt the remote PTY's byte-pipe into the local PTY's byte-pipe, select(2)ing and write(2)ing in a loop on a thread; whereupon the local PTY's rendering agent will handle reducing that stream to the visual grid.
In practice, though, the rendering rules / line disciplines / syntaxes of local vs remote PTY aren't guaranteed to match (especially if the local PTY is actually a real physical TTY); and so in practice, clients doing PTY replication like this actually have their own translation function — logic that acts as a hybrid of a rendering agent and a replay stream-conversion function, taking the byte-stream from the remote, reducing it into a model of immediate state-change effects, and then re-serializing those immediate state-change effects as a byte-stream that the local PTY/TTY will understand. (With the first half of this usually being app-specific code, and the second half of this usually being done using some version of libcurses, to know exactly what rendering-rule syntax the local PTY/TTY claims to understand.)
---
Given all that, you could generalize a TTY/PTY to something other than "text". I've often myself considered a PTY where the "lines" are each (a binary, minimal encoding of) HTML body markup; or even where the "lines" are JSON-encoded log events with parent-node-IDs, and the "rendering" is of a default-collapsed hierarchical event history.
But you'd be losing a lot if you didn't bring across the concept of there being a message-stream + a "canvas" + a brush-state for that "canvas" + rules for two-way conversion between the message-stream and "canvas." Without the stateful canvas, you would need an unlimited-size transcript — and potentially hours of replay — to be able to "attach" a client to an existing backing PTY.
> "Motivated by the thought that at the current point in time perhaps the 'essence' of a 'terminal' is its linear 'chronological' presentation of input/interaction/output history rather than its use of 'text'."
I somewhat object to this.
If you think of a TTY/PTY as an Abstract Data Type, it's a very specific (and clever) one. It's not just a transcript of bytes that flowed through the wire.
Rather, a TTY/PTY is five distinct but inter-related things:
1. a (passive) character-cell viewport grid, of (at any given time) a fixed size, where each cell holds not only a character as data, but also a set of metadata/annotations attached to it (the particular metadata being dependent on the implementation)
2. an active "brush" state for the viewport grid — this includes things like a cursor position, an active foreground and background color, etc.
3. a byte pipe "but better" — in that it's actually a multi-subscriber byte message-queue, plus (only in baked mode) message persistence into an expandable ring buffer, with logical line-oriented consumer-group cursoring to trigger forward-truncation of said buffer
4. a rendering agent with a rendering ruleset (or, in old-school TTY terms, a "line discipline") that sits as one consumer of the byte pipe; reacts to characters in the byte pipe by writing them to the cursor position in the viewport grid; and reacts to in-band messages by manipulating the "brush", making big changes to the viewport grid (e.g. clearing it entirely), and/or swapping out the rendering ruleset itself
5. (the part everyone forgets about) a replay stream-conversion function, that can convert the current state of the viewport grid + its brush, into a stream of characters + in-band messages, such that the rendering agent would parse that stream back into the current viewport + brush state
The clever function you get from this set of components, can be seen in the case of attaching a "client" TTY/PTY to an existing persistent "server" TTY/PTY, such as is created by something like tmux or docker — or even by /bin/login on an old-school terminal server that you've dialed into.
When a client like telnet, ssh, docker-exec, tmux-attach, etc. attaches to an existing backing PTY (either locally or remotely), the client either establishes its own "replica PTY" or reuses the one it's running attached to, and then wants to establish replication from the backing PTY into this replica PTY.
To get a coherent replica, that doesn't just paint garbage at a random position with a random brush, several things need to happen:
• the client needs to reset its own local PTY a known-neutral brush state;
• the client needs to set an ACK position in the byte-stream, and a memorized brush state, for the remote PTY (usually both of these are done implicitly by the syscall on the remote end that opens the PTY for reading);
• the client needs to fetch from the backing PTY, an implementation-neutral byte stream representing the current contents of the character viewport grid of the PTY — and replay that (i.e. it needs to trigger the replay stream-conversion function) — this also happens implicitly, such that when the remote end open(2)s its its PTY, the current state is serialized and dumped into a buffer for read(2)s on the PTY to read;
• the client needs to set up its local terminal's brush to match the memorized one that was set as of its ACK position on the remote.
Once these four things happen, the client can in theory simply shunt the remote PTY's byte-pipe into the local PTY's byte-pipe, select(2)ing and write(2)ing in a loop on a thread; whereupon the local PTY's rendering agent will handle reducing that stream to the visual grid.
In practice, though, the rendering rules / line disciplines / syntaxes of local vs remote PTY aren't guaranteed to match (especially if the local PTY is actually a real physical TTY); and so in practice, clients doing PTY replication like this actually have their own translation function — logic that acts as a hybrid of a rendering agent and a replay stream-conversion function, taking the byte-stream from the remote, reducing it into a model of immediate state-change effects, and then re-serializing those immediate state-change effects as a byte-stream that the local PTY/TTY will understand. (With the first half of this usually being app-specific code, and the second half of this usually being done using some version of libcurses, to know exactly what rendering-rule syntax the local PTY/TTY claims to understand.)
---
Given all that, you could generalize a TTY/PTY to something other than "text". I've often myself considered a PTY where the "lines" are each (a binary, minimal encoding of) HTML body markup; or even where the "lines" are JSON-encoded log events with parent-node-IDs, and the "rendering" is of a default-collapsed hierarchical event history.
But you'd be losing a lot if you didn't bring across the concept of there being a message-stream + a "canvas" + a brush-state for that "canvas" + rules for two-way conversion between the message-stream and "canvas." Without the stateful canvas, you would need an unlimited-size transcript — and potentially hours of replay — to be able to "attach" a client to an existing backing PTY.
is it just me, or is the Spotlights effect in a league of its own here?
Kudos to the author!
Kudos to the author!
Does this have some overlap with libcaca? cacademo and cacafire are especially impressive. Also has Python bindings.
https://github.com/cacalabs/libcaca/tree/main
[edit, also https://en.wikipedia.org/wiki/AAlib]
https://github.com/cacalabs/libcaca/tree/main
[edit, also https://en.wikipedia.org/wiki/AAlib]
That's so cool, I wonder if this can be pulled off on web pages? Non fixed width font would fail all over the places with quirks of css.
I'm dying for a menu system like this that lets me select items old school BBS "light bar" style.
I did not expect this much variety and sophistication.
Absolutely awesome, I've gotta figure out a use for this!
As a former ASCII / ANSI artist, I wish this thing existed like 20 years ago and could make exportable animations for all my BBS needs. Can't wait to tinker!
Would be cute to integrate this with streaming output, so I could tail a log file and have it appear like this (or stream an LLM output, maybe).
Gorgeous and brilliant. Hats off to the developer.
I had a broad smile on my face while going through the effects. This is so playful and fantastic!
The fact that it comes with a command line tool makes it a lot more useful to play with. I can imagine this being used for short pieces of text and to make “hacker” scenes for others.
Now I want an ASCII Art generator built into this! :)
The fact that it comes with a command line tool makes it a lot more useful to play with. I can imagine this being used for short pieces of text and to make “hacker” scenes for others.
Now I want an ASCII Art generator built into this! :)
Incredible. Is there site that collects different ascii art techniques?
Movie material!
I would love to have these effects as an option when viewing man pages.
I feel like a good use case for this would be on an oldskool roguelike.
Cogmind is a newer roguelike that uses lots of effects like this. It looks amazing
Also brogue tends to have very fancy ASCII art animation. Cogmind is not strictly ASCII per se.
It also has one of the best user-interfaces of a text-based roguelike ever. And when I say "interface" I don't just mean the graphic design, although that's amazing too.
Can't think of a more HackerNews worthy project.
Wow!
I did that Matrix-effect once in C#/mono. It turned out to be way more complicated than I initially thought. Well done!
One of the killer features of terminal for me is that it's always clean and polished without fancy animations. You can possibly use transparency but that's more than a visual effect, it can actually be useful to let you see what's happening in a background window.
So while technically amazing, I do hope these text effects will never land in real world application, unless it's related to video gaming.
So while technically amazing, I do hope these text effects will never land in real world application, unless it's related to video gaming.
Oh dear, why would any terminal user want that?
That was my first thought seeing the headline, but they are really clever. My first thought looking through the examples was that I wouldn't mind a progress bar that uses the swarm effect.
https://chrisbuilds.github.io/terminaltexteffects/img/effect...
https://chrisbuilds.github.io/terminaltexteffects/img/effect...
Im really impressed how snappy it is, i played with it localy a bit cause you never know how the screencast was made etc;
I can confirm this looks just as good as the video, well done
I'll be looking for this in Hollywood movies
Wonderful !
Reminds me a lot of Cogmind's[1] level entry visuals, love it!
[1]: https://www.gridsagegames.com/cogmind/
[1]: https://www.gridsagegames.com/cogmind/
Reminds me of notcurses:
https://www.youtube.com/watch?v=b4lmMADP1lA
Mind you, this rendered entirely in a terminal. You can try it yourself on most systems by installing notcurses and then running `notcurses-demo`.
https://www.youtube.com/watch?v=b4lmMADP1lA
Mind you, this rendered entirely in a terminal. You can try it yourself on most systems by installing notcurses and then running `notcurses-demo`.
Reminds me of Caves of Qud.
I love terminals, but I have to say, I kind of hate this sort of thing? Where you need at least 256 colors, GPU acceleration, and 240 columns x 80 lines? At that point it's just a curiosity, anywhere you could do that in a terminal you could do it easier and better in a graphical window. I want my terminal apps to actually still work in an 80x24 monochrome VT220 at 19200 baud. I want them to use termcap instead of hardcoding xterm's extensions to ANSI.
I wonder if there is a similar, more lightweight library that has cool effects that work with the minimum specs you've specified?
AAlib can probably be used for that, although it doesn't have those text effects coded.
The demo, BB, should be more like it. https://www.youtube.com/watch?v=9ukhOAUseKY
AAlib, as far as I know, works in VT220.
The demo, BB, should be more like it. https://www.youtube.com/watch?v=9ukhOAUseKY
AAlib, as far as I know, works in VT220.
omg I'll finally look as cool as my parents think I am when I'm pinging google.com to know how bad the wifi is.
These are really cool, and I wish I could have used them when I ran a dial-up BBS. (Although I don't know if 14.4k or 28.8k were fast enough to handle these.)
But, if you're going to go through the trouble to use these in a command-line program, why not make a GUI?
But, if you're going to go through the trouble to use these in a command-line program, why not make a GUI?
> But, if you're going to go through the trouble to use these in a command-line program, why not make a GUI?
Because this is more fun.
Because this is more fun.
I look forward to seeing this in future movies and forensic procedurals. "The hacker left a virus in the mainframe!"
That's nice, but can we add a feature to terminals that actually understands what it shows and can post-process/augment the data? E.g. when `curl -v` dumped 10k json, the terminal would be able to prettify it right in the terminal. When there's an output with seemingly table data, it would be able to show it as a table with sorting, aggregations and export functionality. If it's code, do some syntax. Logs? - collapse long lines and highlight the parts of them.
I believe what you're looking for is Jq for the json prettifying/manipulation, and nushell for tabular text (not sure about that one, I've only seen it mentioned occasionally).
I strongly believe this should not become the job of the terminal, as it makes it all the more complicated and would possibly deter people from writing the kind of specialized, portable tools that are Jq and nushell for instance.
At most, I think it should be a job for an ncurses application
Everyone is free to not use this feature when it eventually implemented in terminals. Just like syntax highlighting, code completion and AI copilots.
The thing is that as a heavy user I do use jq, terminal triggers and my own stdout colouring/parsing apps that e.g. highlight and parse timestamps or numbers. It all kinda works via endless Cmd+C, "pbpaste | jq" etc but it feels wasteful.
I want to interact with what terminal shows me, not just look at it and copy/paste with broken formatting to somewhere else.
The thing is that as a heavy user I do use jq, terminal triggers and my own stdout colouring/parsing apps that e.g. highlight and parse timestamps or numbers. It all kinda works via endless Cmd+C, "pbpaste | jq" etc but it feels wasteful.
I want to interact with what terminal shows me, not just look at it and copy/paste with broken formatting to somewhere else.
I’ve no idea what I would really use this for, and yet it’s one of the coolest things I’ve ever seen. My eyes are forever improved from having seen this.
As soon as the VHS effect goes out of fashion in PS1 style indie horror games, the community will move on to C64 style cassette loading sequences… on steroids.
Maybe you would use if you were filming a hacker movie? Or something like that
Just applied to /etc/profile.d/ to all SSH servers in my team. I also added some conditionals so that it only runs on interactive shells, doesn't run in sudo -i or tmux/screen, and it only runs once per day per server.
I miss when the internet was full of whimsical stuff like this. Great library, thanks for sharing!
[deleted]
This is so darn cool. Better than 99% of modern computer art. Really says something about good graphic design.
Amazing. I’ve seen similar effects used in production on https://musicforprogramming.net/ which looks like the RandomSequence effect.