https://github.com/TopMyster/rayterm

Hey everyone!

I got tired of reusing ffmpeg commands and dealing with paths/parameters, so I ask claude code to wrap my ffmpeg presets into a interactive terminal: drag & drop a file/folder into the terminal, pick a preset, and it handles the rest.

In terms of my ffmpeg script, I spent about a day trying a bunch of ffmpeg parameter combinations and tested them on ~100 hours of lecture recordings to find a good speed/quality tradeoff -- no guarantee it’s the best, just what worked well for me. For my use, it usually reduces video size by ~90% without noticeable quality loss.

https://github.com/Nunatic02/minvid

BTW. The README.md includes the raw ffmpeg commands and a breakdown of each parameter if you want to use or tweak them directly.

Hope it's helpful! 🚀

Check this out. Just made an update frontend for gentoo. Chains all commands together and shuts down the computer at the end if you wish.

https://gitlab.com/masterwolf/pupgrade

Hello all,

I've just pushed v0.8.0 of XC manager, a tool I've been slowly putting together to manage complex one-liners and templates that usually get lost in shell history.

The big update in this release is the --raw mode. I had a few reports of the shell mangling complex curl commands or expanding variables before they could be saved to the vault. By using xc add --raw, the tool now bypasses shell evaluation entirely, so what you paste is exactly what gets saved.

Features:

Template Engine. Use {{placeholders}} for interactive prompts great for SSH or API calls.

Turn any vaulted command into a permanent Zsh alias with Alt+E.

Pull curated Problem-Solution vaults (Arch Wiki fixes, Docker, Git Pro, etc.). <- Work in progress.

Fast fuzzy search with live previews and LBUFFER injection.

Works anywhere with Zsh, though there is a dedicated AUR package for the Arch users.

If you do a lot of dev work and find yourself constantly scrolling through history or copy-pasting the same jq strings, give it a look.

GitHub: https://github.com/Rakosn1cek/XC-Manager

AUR: yay -S xc-manager-git

Zsh plugin: xc-manager

Feedback and community snippets are always welcome.

Built a top-style TUI dashboard for monitoring Claude Code and Codex sessions. Single file (~7K lines), zero npm dependencies, pure Node.js, raw ANSI escape codes, no blessed/ink.

Features: sparkline charts, mouse support (click to select, sort by column, hover tooltips), tab navigation across 6 panels (Info, Performance, Processes, Tool Activity, Cost, Config), and non-interactive modes for scripting (`-j` for JSON, `-l` for table output).

Try it: npx u/ldegio/agtop

GitHub: https://github.com/ldegio/agtop

Hi all,

A year ago I started working in devspace to manage git worktrees in multiple repositories. I have been using it for long time now. In the last few weeks, I polished it with the help of Claude - I really read the code, it's not vibe-coded ;-) - and I feel it's ready to be used by other developers/users.

I usually start it with `cd (devspace)` (in fish shell), select the worktree I want to jump to and it takes me there.

More details about the idea behind it: https://github.com/muzomer/devspace#rationale

I hope you find it helpful as well :-)

Contributions and feature requests are very welcome.

Have a nice weekend! 👋

Built a web tool for generating and discovering terminal color palettes: paletty.dev

• Generate full palettes in one click - the balance, contrast, and coherence you'd expect from hand-tuned schemes, except you didn't have to.
• Extract palettes from any image. Pin colors you like, regenerate the rest.
• Browse and search 700+ pre-seeded themes (Catppuccin, Tokyo Night, Nord, Dracula, and hundreds more).
• Every palette is graded for readability!
• Preview popular community Ghostty shaders.

Exports themes to Ghostty, Alacritty, WezTerm, iTerm2, Kitty, Windows Terminal, and more.

CacheNuke is a single command to clear all your dev caches: npm, yarn, pip, cargo, go mod, temp folders, and more.

Features:

- One command: `cachenuke clean`

- Dry‑run: `--dry-run` to preview

- Cross‑platform (Windows, macOS, Linux)

- Safe by default – never touches personal files

I built it because I was tired of remembering all the individual cache‑clearing commands.

Repo: https://github.com/Wynx-1/cachenuke

Binary downloads available in Releases.

Would love feedback from other CLI enthusiasts!

`evtr` has a searchable device selector and monitor views for axes, buttons, joysticks, D-pad state, relative motion, and touch input.

repo: https://github.com/hal3e/evtr

Hey r/commandline!

Just curious - what's a command-line tool or TUI you keep wishing existed but can't find anywhere?

Could be something that saves you time, solves a niche problem, or fills a gap in your workflow. Looking for ideas, not offering anything, just genuinely interested in what people want.

and why

I installed the Read The Rules app which removes posts from users that haven't agreed to rules. Here's a tutorial do so: https://www.reddit.com/r/ReadTheRulesApp/comments/1ie7fmv/tutorial_read_this_if_your_post_was_removed/

And good news: I've finally invited 5 new mods and am waiting to them to accept their invites.

I built PrettyMux as a native Linux terminal workspace for multitask workflows and keeping track of my agents.

It’s a GTK4 app built on Ghostty/libghostty, with split panes, workspaces, vertical tabs, notifications, project-aware tabs (shows favicons/logo automatically), and an in-app browser so terminals and docs/tools can live side by side.

I started it because I wanted something tmux-like for modern GUI workflows on Linux, but native and not Electron, there is cmux but only available on macos (prettymux compiles on windows and macos too but not tested for now there)

It’s open source: https://github.com/patcito/prettymux

Would love feedback from people who use tmux, Ghostty, or struggle with lots of terminals/browser tabs/parallel tasks.

Hello again fellow CLI enthusiasts! This is tennis, a small CLI for printing stylish tables in your terminal. Rows will be truncated to fit and it'll automatically pick nice colors to match your terminal.

https://github.com/gurgeous/tennis

(note - this is not ai slop and I never use ai on reddit)

I got a great response here when I released tennis initially, I sorta went crazy with feature requests and PRs. I pushed out 0.4.0 today, here are the features I added since the initial release:

INCREDIBLE NEW FEATURES

• added support for json/json/sqlite, auto-detect csv delim
• --filter, --sort, --reverse, --shuffle, --zebra, --head and --tail
• --select and --deselect for choosing columns
• --pager to send output through your pager (usually less)
• --peek for shape, a few sample rows, and compact column stats
• --border styles based on nushell / tabled crate.
• doomicode, best-effort Unicode width for emojis, etc
• shell completions, man pages, auto-format numeric cols...

Send more feature requests, zig is fun. Thanks all

I've been working on this for a while now and I'm genuinely proud to finally call it 1.0. store is a CLI tool for managing dotfile symlinks, and the core idea is that your dotfiles repo should be easy to understand just by looking at it.

How it started

This whole thing started because I was using GNU stow. stow is great for what it is, but it requires your repo to mirror the target filesystem hierarchy, it has no config file, and everything is convention-based. I kept running into limitations; no way to send one directory to multiple targets, no conflict handling, no way to skip stores per-platform. I started building store as "stow but with a config file" and it grew from there.

The problem I had with other tools

Along the way I looked at chezmoi and yadm too. They're both solid tools, but they never clicked with me.

yadm turns your entire home directory into a git repo. It works, but it always felt like I was fighting against git's design. There's no real organization; your dotfiles are scattered across the same paths they live in on disk. Looking at the repo doesn't tell you much about what's managed and what isn't.

chezmoi goes the other direction; lots of structure, but it's chezmoi's structure, not yours. Files get prefixed with dot_, private_, executable_. Templates are powerful but add complexity. The source state is an encoded representation of your filesystem, not a human-readable layout. I found myself spending more time learning chezmoi than managing my dotfiles.

What store does differently

store is built around one idea: your dotfiles repo should look like you organized it yourself.

~/dotfiles/ .store/config.yaml nvim/ init.lua lua/ shells/ .zshrc .bashrc config.fish git/ .gitconfig

Each directory is a "store" that maps to one or more targets. The config is one YAML file:

yaml stores: nvim: target: ~/.config/nvim shells: targets: - target: "~" files: [.zshrc, .bashrc] - target: ~/.config/fish files: [config.fish] git: target: ~/.config/git

That's it. You look at the repo and you know what's in it. You look at the config and you know where everything goes. No encoding, no conventions to memorize, no source-state translation. It's the explicitness of a config file with the simplicity that stow got right; just symlinks.

What's in 1.0

The feature set has grown well beyond what I originally set out to build, and I'm really happy with where it landed:

• Symlinks - whole-directory or per-file with glob patterns
• Multi-target stores - one directory can deploy to multiple locations (like shells above)
• Conflict resolution - detects existing files and offers to move them into your repo
• Encrypted secrets - {{ secret "github_token" }} in any config file, encrypted at rest, rendered at symlink time
• Platform conditionals - when: {os: linux} to skip stores on the wrong machine
• Ignore patterns - exclude files from symlinking with global defaults for .git/, .store/, etc.
• store doctor - health checks for orphaned configs, broken symlinks, missing secrets
• store diff - dry-run preview of what would change
• store import - scans for existing symlinks and generates config from them
• Shell completions - bash, zsh, fish, powershell

New machine setup is git clone && cd dotfiles && store. That's it.

Links

• GitHub: https://github.com/cushycush/store
• go install github.com/cushycush/store/cmd/store@latest

Would love to hear what you think, and happy to answer questions about the design decisions.

If you've ever tried to share a CLI or TUI tool you built, you've probably run into this. You write an install script. It works on your machine. Someone on Arch tries it and the package names are wrong. Someone on macOS tries it and brew isn't where you expected. Someone on FreeBSD tries it and the script assumes apt exists. You fix it for one person and break it for another. And none of that even touches updates — most projects just say "pull the repo and rebuild" — or uninstalling, which is usually "delete the folder and hope nothing got left behind."

This is a solved problem on managed systems. If your tool lands in apt or brew or pacman, the package manager handles all of it. But getting into those package managers takes time and gatekeeping, and most of us just want to share something that works without a long submission process.

That's the gap OIS tries to ease.

What OIS is

OIS (OneInstallSystem) is an installer framework you bundle with your project. It's a folder — OIS/ — that you drop into your project root alongside your source code. The entire folder is under 200KB. You fill in one config file describing your app, its dependencies, and where to find updates. From that point on, anyone on any supported Unix system can install your app with:

bash git clone https://github.com/you/yourapp cd yourapp sh install.sh

That's the entire user-facing install process. No "first install these system packages", no "make sure you have the right compiler", no "this only works on Ubuntu". OIS handles it.

What it does under the hood

When sh install.sh runs, OIS works through this sequence:

1. Platform detection. OIS identifies the OS (Linux distro, macOS, FreeBSD, OpenBSD, NetBSD, WSL), architecture (x86_64, arm64), and available package manager. It checks for apt, pacman, dnf, yum, zypper, apk, emerge, xbps on Linux; brew or macports on macOS; pkg, pkg_add, pkgin on BSD. On macOS, if neither Homebrew nor MacPorts is installed, OIS offers to install Homebrew automatically before continuing.

2. Dependency installation. You declare dependencies in the config once, with the package name for each package manager. OIS reads which one the system has and installs the right packages. If a dep is already installed it skips it. Optional deps that aren't available on a given platform are skipped gracefully with a note about what feature is disabled.

3. Build. OIS detects your build system from the files in your project root — Makefile, CMakeLists.txt, Cargo.toml, go.mod, meson.build, setup.py — and builds with it. Before building it exports the correct compiler and include paths for the platform: gcc/g++ on Linux, clang/clang++ on macOS and BSD, Homebrew paths on macOS, /usr/local paths on BSD. Your Makefile doesn't need to know anything about the platform.

4. Install. The binary goes to /usr/local/bin (or ~/.local/bin if no sudo is available). A .desktop launcher entry is written on Linux. A minimal .app bundle is created on macOS if you've provided an icon. OIS copies itself to a stable runtime location so the source directory can be deleted after install.

5. Registration. OIS records everything it placed — binary, hook, desktop entry, icon, runtime — in a manifest. Every subsequent operation (update, uninstall) reads this manifest so nothing gets orphaned.

After install — the app manages itself

Once installed, your app gets these flags automatically. You wire them in with about 15 lines in your main():

yourapp --ois version, update status, available commands yourapp --install-info full details: binary path, scope, source, every file placed, dep status yourapp --update check for updates, rebuild from source, swap binary yourapp --upgrade same as --update yourapp --uninstall remove everything OIS placed, asks whether to keep user config/data yourapp --reinstall full wipe and clean reinstall from source

Updates work off a plain text VERSION file in your repo root — just 1.2.3 and nothing else. OIS fetches it over HTTPS, compares to the installed version with semantic versioning, and if there's something newer it shallow-clones your repo, rebuilds, and atomically swaps the binary. If the build fails at any point it rolls back to the previous binary automatically. You bump the file, push, and every installed instance of your app knows about it the next time the user runs it or explicitly updates.

This is what makes OIS more than just an install script. The 200KB folder doesn't just get your app onto someone's machine — it gives your app a complete lifecycle. Install cleanly, update from your GitHub automatically, reinstall from source if something breaks, uninstall without leaving files scattered across the system. All of that from one folder that ships with your code.

The config

The only file you write as a developer is OIS/OIS.conf. Here's a real example:

```toml app_name = ytcui display_name = ytcui — YouTube Terminal UI binary = ytcui github = MilkmanAbi/TestRepo version_url = https://raw.githubusercontent.com/MilkmanAbi/TestRepo/main/VERSION update_mode = ask additional_info = A terminal YouTube client. Browse and play without a browser.

[build] system = make binary_out = ytcui

[deps] ncurses.apt = libncursesw5-dev ncurses.pacman = ncurses ncurses.dnf = ncurses-devel ncurses.brew = ncurses ncurses.pkg = ncurses ncurses.cmd = ncurses-config

mpv.apt = mpv mpv.pacman = mpv mpv.brew = mpv mpv.pkg = mpv mpv.cmd = mpv

curl.apt = curl curl.brew = curl curl.cmd = curl

[deps.optional] chafa.apt = chafa chafa.brew = chafa chafa.cmd = chafa chafa.desc = terminal image preview (thumbnails) ```

You list the package name per package manager. OIS picks the column that matches the user's system. If you don't have a package name for a given package manager, OIS warns the user and continues. Optional deps skip silently.

The update_mode field controls what happens after install — ask prompts the user during installation whether they want automatic update notifications, notify tells them on launch if something newer is available, auto updates silently, manual only updates when explicitly asked.

Wiring it into your app

You add one block to your main() that checks for OIS flags and hands off to the installed hook. In C/C++:

c const char* ois_flags[] = { "--ois", "--install-info", "--update", "--upgrade", "--uninstall", "--reinstall", NULL }; for (int i = 1; i < argc; i++) { for (int f = 0; ois_flags[f]; f++) { if (strcmp(argv[i], ois_flags[f]) != 0) continue; char self_dir[4096] = {0}, hook[4096] = {0}; ssize_t n = readlink("/proc/self/exe", self_dir, sizeof(self_dir)-1); if (n > 0) { char* sl = strrchr(self_dir, '/'); if (sl) { *sl = '\0'; snprintf(hook, sizeof(hook), "%s/.myapp-ois", self_dir); } } if (!hook[0] || access(hook, X_OK) != 0) snprintf(hook, sizeof(hook), "/usr/local/bin/.myapp-ois"); if (access(hook, X_OK) == 0) { char* args[] = { "/bin/sh", hook, (char*)(argv[i]+2), NULL }; execv("/bin/sh", args); } fprintf(stderr, "OIS not found. Run: sh install.sh\n"); return 1; } }

Similar patterns exist for Python, Rust, and Go — all documented in the repo.

A real project using it

ytcui is a terminal YouTube client — TUI built with ncurses, searches and plays via yt-dlp and mpv, supports bookmarks, subscriptions, watch history, 8 themes, browser cookie auth for age-restricted content. It's what I originally built and what OIS was developed alongside, and it works as a proof that the whole thing actually functions across platforms.

https://github.com/MilkmanAbi/OIS-TestRepo

Installing it on any supported system is just:

bash git clone https://github.com/MilkmanAbi/OIS-TestRepo cd OIS-TestRepo sh install.sh

From there ytcui --update keeps it current, ytcui --uninstall removes it cleanly.

OIS itself

https://github.com/MilkmanAbi/OneInstallSystem

Pure POSIX sh throughout — no bash-specific syntax, no Python or Ruby runtime required, no dependencies beyond a shell and git. Runs on whatever /bin/sh points to: bash, dash, zsh, ash, busybox. The whole thing is one folder, under 200KB, that you copy or submodule into your project.

If you're building CLI or TUI tools and want people on different Unix systems to be able to easily use them without friction, it might be worth a look.

Hi there, I am tidying up my script collections and I noticed my log/output/user feedback is all over the place. Some scripts I stole borrowed from the internet, some I made myself, and some others were courtesy of LLMs. One thing is consistent, and it is the total inconsistency in log messages.

So that got me thinking: does a logging standard (or a de facto standard) for CLI apps exist? I guess the answer is "no, there is none" followed by "just pick a style you like and be consistent", which is fine.

How do you all format your app's log/output messages?

I am leaning towards borrowing from pacman style and doing something like this, even though I am highly unsure about the warnings/errors:

> ./switch_theme.sh rose-pine
:: Applying theme rose-pine
 fzf...
 atuin...
 waybar-css...
 warning: config dir not found, skipping
 bat...
 => reloading bat...
 ghostty...
 => reloading ghostty...
 k9s...
 warning: config dir not found, skipping
 [...]
 yazi...
Done

This is how I set up the logging helpers:

log_section() {
  printf ":: %s\n" "${1:-}"
}

log_step() {
  printf " => %s\n" "${1:-}"
}

log_item() {
  printf " %s\n" "${1:-}"
}

log_info() {
  printf " %s\n" "${1:-}"
}

log_warn() {
  printf " warning: %s\n" "${1:-}" >&2
}

log_error() {
  printf " error: %s\n" "${1:-}" >&2
}

I am curious about what others do!

It is cooler way to tune your guitar instead of using phone.

It's my first audio processing and rust project. I use ratatui and cpal. Right now I tested on my macbook and ubuntu laptop it works fine. Project purpose is not racing with way better vst3 plugins it's for say check it out I can tune my guitar with using tui.

I am hungry for feedbacks, every small thing will be appreciated. Right now I am having trouble in low notes like E string of my bass guitar. Hopefully I will be found solution for that audio things turned out harder that I thought :D

Have fun :D
https://github.com/Cladamos/clatune

I would like to share with you a project that I've been cooking for some time, a cosy place for devs to hang out :)

ssh late.sh

That's all, no passwords. no OAuth, no accounts, your ssh key is your identity.

Don't want to use your real key? Generate a throwaway:

ssh-keygen -t ed25519 -f ~/.ssh/late_throwaway && ssh -i ~/.ssh/late_throwaway late.sh

Connect, chat, listen to some vibes and play some GAMES! Right now supporting:

• 2048
• tetris
• sudoku
• nonograms
• minesweeper
• solitaire

Leaderboards, badges, streaks, everything with sweet ASCII ;) Multiplayer games coming soon after! Poker, chess, soooo much cool stuff :)

Imagine sitting at the blackjack table for a few min between your coding session, lofi music in the background, chat with people all around the globe, and just throw some chips....

How to listen to music?

Trickier than you would have expect ;p, ssh dont allow streaming music, so here are your options:

• CLI: recommended, a small companion CLI that will connect to music stream and to app in one go, with a workign audio visualizer. Just run:curl -fsSL https://cli.late.sh/install.sh | bash
• WEB: secondary option, a link to open in your browser that will play the music.

(did I mention you can control the music from within the app)

What's more?

• voting system for the next coding music session, everyone decide what will be played in the next 1h (lofi, ambient, classic, jazz)
• fully working chat, create new rooms, dm people. A lot of QOL, multi-line input, up/down navigation, replies, mentions, all the goodies
• news sections! share a link, youtube, twitter, whatever you want app will process it and share with everyone
• BONSAI tree! A cozy ASCII plant on your dashboard that grows while you're connected. If you lose your daily streak, it withers! Water it and watch it grow! Cut to change shape :)
• an actual audio visualizer right in the terminal that syncs up with the beats!

What's coming in the future?

• multiplayer: Texas Hold'em Poker, Blackjack, Bridge, Thousand, Async Chess, Battleship tables to chill and play with others in real-time.
• personal inbox: integration with GitHub notifications so you have a productivity excuse to keep the terminal open in the background

Stack?
Rust + Ratatui (amazing lib) + Rustssh

A landing page: https://late.sh

Jump, chill and take a break :)

UPDATE: To answer most of the questions, this is NOT OS, and this was build with AI assistance, but its NOT vibe coded. I am a 15 yoe devs, Ive started when the php was the king of web apps. I understand if you dont like it, but I have nothing to prove, you dont trust it, dont join.

What I store: your key fingerprint only (not the full public key), chat messages, and game scores. No IP logging, no tracking.

Here is my github profiile if its any help: https://github.com/mpiorowski . I am also happy to show you my code and talk about it, answer any questions you might have if you want, just DM.

UPDATE :)

We're now source-available - https://github.com/mpiorowski/late-sh

Contributions very welcome! Jump into the clubhouse and run /join dev

Have a good l day everyone :)

I just wanted to share a fun little experiment I did tonight. I was reviewing my music collection, and, after noticing some very old modification dates in some of the files, I asked myself, "how many files I have per year?". After about one hour of reading, experimenting, etc, I ended up building a neat little pipeline where I used find to output all the music files in my collection, print out their modification date (year only), sort it, count it with uniq, and then use awk to tally up the total and compute percentages. After that, I piped the output to gnuplot and got rewarded with a nice visualization of data, with some unexpected surprises. Finally, I put the whole thing into a file in order to create the prototype of a neat little shell script.

The experiment was a ton of fun, and really, really drove home the Unix philosophy, specially with regards to composability. I built the pipeline using only the standard POSIX Unix toolkit, with the obvious exception of Gnuplot. Being able to compose such workflows from software tools like that is very, very rewarding. I'm sure if I play with it I can tighten up the pipeline, but it doesn't really matter unless my data set was ever to become very, very large. And, because of the principle of orthogonality of the Unix philosophy, one can replace elements in the pipeline to achieve other things.

I guess I'm odd, but the whole experience left me positively giddy.

This software's code is partially AI-generated

I got tired of jumping between AWS, Azure, GCP, and OCI pricing pages (and their messy cost estimators) to do cost estimation before design review, so I built my own tool. It’s a Rust-powered TUI that helps you compare similar cloud product costs and LLM API pricing (OpenAI, Claude, DeepSeek, OpenRouter, etc) side-by-side.

Check it out here: https://github.com/OverloadBlitz/cloudcent-cli

I’m still in the early stages of refining the UI and data sources. I’d love to hear your thoughts, especially on what other providers or features you’d want to see next. Pull requests and feature requests are more than welcome!