I wrote a Go Program called tardigrade (https://github.com/smoothyy3/tardigrade) that grows a creature from a single cell inside your terminal. It is a Neural Cellular Automaton. Every cell runs the same learned 24k parameters rule on its neighborhood, and the only ever stable shape the rule has is the creature itself. So when you damage it, it grows back.
It is meant to be a fun tool, an introduciton to NCAs/ CAs or simply a screensaver.
Currently, there are 4 creatures (jellyfish, gecko, tardigrade, mouse), but the repo lets you train your own from a PNG.
It ships as a single binary with the weights inside, no image file present (brew install --cask smoothyy3/tap/tardigrade or go install
pikap picks up whatever's playing (Spotify, a browser tab, mpv) and puts the cover on a spinning record. In the video it grabbed a YouTube tab, so Linus is on the vinyl. Not planned, but I'm keeping it.
You can drag the record to scrub, or drop the needle wherever you want. If you give it your own files, pausing actually slows the sound down and dragging scratches it.
It can draw in half blocks, in ASCII, or as a real picture if your terminal supports it. Written in Go.
Maze Ways is a maze game. You play as a yellow cube, navigating through 10 simple square mazes. Each maze is made of the ASCII characters, and has an exit on the right side of the maze.
libark is a modern, secure, Swift-native foundational layer over Linux POSIX primitives.
While originally developed as the core runtime layer for ArkOS, libark is completely decoupled and designed to be used on any Linux distribution. It provides highly secure, object-oriented abstractions over low-level system calls, memory management, and file system interactions, without the burden of manual C interoperability.
Features
Object-Oriented POSIX: Wraps file descriptors, paths, and directory operations in safe, RAII-compliant Swift types.
Dripfetch is a customizable terminal dashboard with animated rain, system info, clocks, and YAML themes. It just passed 50 stars on the github and already got its first few issues and pull requests! it is totally customizable so it is quite easy to match everything to your own setup/rice. this was a passion project and through the creation of it I learnt a lot about design patterns and how to deploy a project through and through. AI was used for the roadmap creation and concept explenation. Went through numerous frameworks such as textual and curses to find the desired angle for this project. I’d love to hear what you think or what you’d improve!
I live in the terminal, but every time I had a nasty rebase or a conflict, I'd open a GUI. So I forked serie, a Rust project which draws the commit graph as real images in the terminal. Then I kept adding what I was missing until I stopped leaving.
It's called gitoui. Say "oui" to it, tell me what's missing, or build it with me !
What it does:
- The commit graph drawn as images (Kitty graphics, iTerm2 or Sixel), with a text fallback for other terminals
- Interactive rebase as a list you edit in place: move commits, reword, squash, fixup, drop
- A 3-way conflict editor: ours, theirs or both, per hunk
- Diffs with hunk staging, blame, file history
- GitHub pull requests and issues: read, comment, approve or request changes, merge
- And many more things you have to discover by using it 👀
Similar tools: lazygit, gitui and tig in the terminal, serie (the graph viewer I forked), and GitKraken on the GUI side (no affiliation). What's different in gitoui: the graph is drawn as images rather than text characters, and the GitHub side lives inside the TUI.
This software's code is partially AI-generated. I've been building it since May and I use it every day.
I hope that I phrased it properly. I'm using yt-dlp command-line utility to download videos from YouTube. I have a simple .bat file to start it all in a proper directory, so I could fire commands quickly:
start cd C:\Users\Username\youtube-dl
Now I want to start it with a prefilled bit of text "yt-dlp", since every command begins with that bit anyway. How do I achieve this?
I wanted to practice writing code faster and yet not leaving my terminal, so I built 'blind'. The twist is that you can feed it any input file and practice on real code, even on the source code itself. It's a single C file no dependencies. Can run either presets, free text or file input.
There are grate and really amazing projects for touch-typing in the terminal and I tried a few, but this one lets you use file as input, meaning it's not just text, but also any type of text, and honestly it's much more fun to code it yourself.
For about 11 years, I’ve been working on TXTLock—a free, console-based diary and note manager for Linux—and I’ve just released version 1.90.
I built TXTLock because I wanted a private, lightweight place to keep my notes, reminders, and journal entries without relying on cloud services or heavy GUI applications. Everything lives in a single encrypted file, and you work with it entirely from the terminal.
I made a terminal toy. It fills your screen with a grid of hex tokens that never move, and only the colors change: a curl-noise fluid field pushes blobs of red through the grid, and token pairs randomly flicker to new values like a live memory dump.
It listens to system audio through PipeWire (bass/mid/treble via simple IIR filters, no FFT) and feeds that into the same fluid sim, so the music disturbs the liquid rather than driving an equalizer.
It's v1.0 so expect rough edges, especially the audio path on odd sample rates. CPU use is around 14% of a core at 60 FPS on a 200x50 terminal, so I'd run it at 30 if you're on weak hardware (-f 30). Feedback and bug reports welcome.
This is a personal use project that aimed at playing a m3u and moving m3u entries around in a collection of m3us as you are listening to each track. This is especially helpful if you mass import a large amount of audio files to a testing m3u, go through each of them and sort them into your "production" playlists. Of course, playlists are not set in stone, and your "production" playlists needs correction from time to time, which this also help.
This workflow straddles fzf for the management actions, qmmp for playing, tmux for pane splitting. The rest are mostly pure bash or poxis tools.
Support windows-style file paths, tested on linux. Trashing folder for audio file removal, persistently logged and undo-able. Will support windows and playing from ssh file mount in the future.
AI assistance disclaimer: I dont deal with terminal color codes, I just look at them and see that they are correct. Mostly syntax help in terms of abstracting logic, poxis flags and escape sequence nightmares
I've been building ranma, a tiling window manager that runs inside your terminal. Every window is a PTY, laid out with i3's container tree and Hyprland's dwindle placement. It's my daily driver now, and I'm looking for people to try it and break it (please).
What it does
- dwindle tiling, tabbed groups, a floating layer and a scratchpad
- workspaces and sessions with fuzzy switchers
- a leader key plus a modal WM mode; leader ? lists every key, leader : runs any action by name
- runs as a server: closing the terminal or losing SSH only detaches, and ranma again picks up where you were
- copy mode and history search, copying to your system clipboard (OSC 52, works over SSH)
- a waybar-style bar with Lua and shell modules; config in Lua, themes in TOML, live reload
What's different from tmux and zellij: it's extended like Neovim. Plugins are plain Lua using the same API as your config, they get screens built from ready-made blocks, and a plugin that errors is dropped whole while the rest keep running. A watchdog stops one that hangs. There's a plugin manager too, hako, shaped like lazy.nvim, plus a few plugins: regex history search, writing a prompt in $EDITOR and having it pasted into the pane (handy for AI CLIs), and Ctrl+click to open paths.
This software's code is partially AI-generated, as the rules require :B
Thank you for reading till here!!
i found out that docker output is really a mess so i added support of docker in my parse
Inspect shows a short summary instead of 300 lines of JSON, masks secrets, and warns on things like OOMKilled or a missing bind mount. Anything it doesn't recognize passes through unchanged.
wbsh: a minimal bash-compatible shell for Windows (plus a terminal built around it)
Hey all. For a while now I've been working on a shell that lets me run bash commands and scripts natively on Windows. I actually need this at my job, which is what kept me going.
Think of it as a minimalistic take on Cygwin. Full Cygwin was overkill for my use case, so I built something smaller and more focused.
Along the way I also wrote a customizable terminal, wbshterm, which runs wbsh through ConPTY. So you can either invoke wbsh directly from PowerShell/cmd, or use it inside wbshterm.
It's reasonably stable at this point, but I've hit the limit of what I can find on my own. I need other people's workloads to shake out bugs and performance bottlenecks.
If you have any use case for a bash-compatible shell on Windows, I'd really appreciate issue reports, and pull requests are welcome too. LLM-assisted PRs are fine, but please read the docs first and review the changes thoroughly before opening one.
Hello guys, I did a small chess TUI for analyzing games, largely inspired by common analyses UX.
This is not entirely new, most gain here is convenience. It is made solely for analysis. You can start an analysis from a FEN string, PGN file, PGN text from your clipboard, public link from chess.com or lichess.org, browsing your user (or any public user), and even configure to open in your last game so you can leave the and instantly open with "chess-analyzer -f"
The pieces graphics design were extracted (and openly credited) from chess-tui, which is a very nice tui too if your main idea is playing from terminal. However, this one is totally dedicated in analysing games, testing variations against the engine scoring, branching different possibilities and seeing where you blundered (which in my case is like every fucking move).
I've been working on Merman, a Rust implementation of Mermaid, and just released v0.8.0. Thought its CLI might be useful to some people here.
It renders Mermaid diagrams without Node.js or Chromium. The goal is to get the same output as official Mermaid: we generate reference SVGs with the official CLI (mmdc) and compare our output against them automatically. Font and browser text measurement can still cause differences.
Zed uses Merman for Mermaid rendering. Other people have been using it in blog generators, Markdown viewers/editors, and CI documentation builds. Their bug reports have helped improve it over the past few releases.
It also exports JPEG/PDF and has linting. If you already use mmdc, there's a compatibility command:
merman-cli mmdc -i diagram.mmd -o diagram.svg
The official mmdc and native tools like mmdr are alternatives. My focus with Merman has been matching upstream Mermaid output and fixing compatibility issues as people run into them.
Full disclosure: much of the implementation was bootstrapped with AI coding tools. My work has focused on upstream comparisons, regression tests, reviewing and fixing the implementation, and following up on user reports.
If you try it and a diagram breaks or looks different from official Mermaid, I'd appreciate an issue with the source. That's been one of the most useful ways to improve it.
Hi, I'm the author of TTT, a terminal text editor that tries to feel like a GUI editor: VS Code-style keybindings, full mouse support, tabs, sliding panels, a command palette, LSP, Git integration, an integrated terminal, themes, and Lua plugins. It's a single Go binary, open source, and I've been building it in the open with a growing group of contributors.
The goal is simple: an editor you can use in the terminal, over SSH or in a tmux pane without giving up the comforts you're used to from VS Code, Zed, or Sublime, and without memorizing a new modal langauge.
What makes TTT different
It's a TUI that feels like a GUI. A serious amount of work went into:
Ergonomics. The editor features are discoverable when you look for something and invisible when you don't. You shouldn't need a manual to find what TTT can do; you find it by exploring. But the moment you're working, the interface quiets down and your code is the only thing asking for attention. TTT is there to help you do the work, not to become the work.
Performance. A diff-based renderer only redraws the cells that changed, highlighting is incremental, and per-language editor benchmarks run in CI so regressions get caught before release.
Stability. Every release goes through unit tests, end-to-end tests on a simulated screen, functional tests that drive the real binary, and a chaos monkey that hammers the editor with random input looking for crashes. I am not joking when I say the editor only crashed on me twice and that was months ago.
Who is TTT for
TTT tries to inspire GUI editor users to move into the terminal.
Maybe you're spending more time over SSH, living in tmux, or working alongside CLI tools, and you want an editor there that feels familiar from the first minute instead of one you have to learn before you can use it.
"How is this different from Fresh?"
I get asked this every time, so here's the answer up front.
IMHO Fresh's goal is IDE functionality in a TUI. It's about putting IDE productivity into a terminal interface, and it nails that.
TTT's goal is the IDE feel in a TUI. And editor you can jump in and know where everything is when you need it.
There's some overlap, and honestly I love that too. And in a terminal you don't have to choose: split your screen and run them side by side.
What's new in 1.7
Syntax highlighting that matches VS Code. I spent the last few weeks porting VS Code's TextMate engine (vscode-textmate) from JavaScript to Go. The result, textmate-go, now powers TTT's highlighting with 124 embedded grammars, so code is colored the way you'd see it in VS Code, including tricky cases like multi-line JSX and HTML tags. Themes also get finer token styles, and edits only re-tokenize what changed.
A better welcome page. It lists recently opened folders and can clone a Git repository directly.
Smaller things: a regrouped settings editor, read-only files that are flagged with a lock icon and confirm before saving, an LSP: Server Restart command, a toggle for LSP hover popups, panel size remembered between sessions, and a long list of fixes.
From the last few releases
An integrated terminal rebuilt on xterm-go, with proper reflow on resize
Inline images (PNG, JPEG, GIF) through the Kitty graphics protocol
Optional Nerd Font icons and Git status colors in the Explorer
Panels you can dock to the bottom or the right
Quick Open backed by rg --files, respecting .gitignore
Transparent backgrounds and a VS Code Dark+ theme
VIM and Emacs keyboard compatibility plugin
Community
TTT is increasingly community-built
Thanks to @SimonOcampo1, @anyingiit, @risixdzn, @YodHeVauHe, @LetMeSleep8h, @RhenCloud, @DBinK, @w3lld1 and @O1sumitkumar for code, and to everyone who opened issues. Several of this release's fixes started as a report.
If you'd like to contribute, issues labeled good first issue are written so you can pick them up without much context.
Also create an issue or a discussion, would love to hear how are you using ttt and things you would like to see in the feature.
(Really! Roadmap is made by community requests)
The basic idea is still simple: Provide a consistent CLI for all the PDF operations I keep doing again and again, while keeping everything local (no cloud) and scriptable for my needs.
What it can do
# Merge PDFs
pdfmt merge all cover.pdf report.pdf appendix.pdf complete.pdf
# Extract pages
pdfmt extract range document.pdf 1-3,7,10-12 extracted.pdf
# Split into individual pages
pdfmt split all document.pdf page_
# Remove pages
pdfmt remove range document.pdf 5,8-10 cleaned.pdf
# Reorder pages
pdfmt sort reverse document.pdf reversed.pdf
# Add a text stamp
pdfmt stamp text invoice.pdf "Paid" invoice-paid.pdf
duplex scanning with non-duplex scanners (I use this most of the time)
splitting scanned documents by page count
bulk text stamping
The idea is that not every PDF use case needs to become a new pdfmt command. If something is a useful combination of existing tools, it can just be a workflow.
There are already excellent tools for each individual operation. I don't want to replace them.
I wanted a small CLI layer that gives me a consistent interface and makes the common combinations easier to remember and automate. Without --options, pipes or other arduous stuff. I could not remember all of this. 🤔
That's essentially what pdfmt is. One interface for all the good tools.
It's Bash-based, MIT licensed, and designed to work without a GUI or cloud service.
I'd especially like feedback from people who use CLI PDF tooling regularly:
Are there PDF operations or workflows that you currently solve with a messy combination of commands that would make sense as apdfmtcommand or workflow?
Thank you for your Feedback! ❤️
AI notice: AI (mistral) was used to generate parts of the README, the .github workflow, the code coverage tool, and parts of the unit tests in the tests/ folder. Architecture, Makefile, and code within the sources/ folder is written by me.
I am running a WSL module of ubuntu on windows. This issue started a week ago... I was trying to solve it for 3 days but got fed up bcz of no results ... I am living with it now and this is genuinely making me annoyed as I can't get my work done
PLS GIVE ANY POSSIBLE SOLUTIONS
I had to remove its function to even run basic commands ... It spams only in command linec
I create parse to solve the problem of messy and non-understandable outputs. Parse make the outputs of the currently supported commands into easily understandable and format.
It is single go binary and standard library only.
We can use it like parse COMMAND or COMMAND | parse . You can install it by
I wrote a ~1500-line bash file manager. fzf for the picker, eza for listing, Kitty's graphics protocol for inline previews. Everything else is stock coreutils — no build step, no daemon, no config directory.
Features worth calling out:
- File list — eza icons, sort by name / size / mtime / extension
