r/CLI

Dripfetch is a customizable terminal dashboard with animated rain, system info, clocks, and YAML themes. I’d love to hear what you think or what you’d improve!

Hi r/cli 👋🏽

sdrtop is a terminal-based application designed for low-cost SDRs. It features a spectrum and measurement display and warns the user when the radio is being clipped or when samples are being dropped rather than providing false readings.

It can also detect Bluetooth and FM/RDS signals (without audio) from the air, such as clock drift, packet quality, and more, on HackRF, RTL-SDR, tinySA.

Repo: https://github.com/musithang/sdrtop

I've been building and maintaining multiple web projects, and I kept running into the same problem: every new project required repeating a lot of setup work before I could focus on building the actual product.

So I built create-clubedge-app, a CLI that generates a Next.js monorepo from a versioned starter.

It includes a foundation for:

• Next.js App Router and TypeScript
• pnpm and Turborepo
• PostgreSQL and Drizzle ORM
• Supabase Auth
• Testing, linting, and CI
• Optional Redis-compatible caching and object storage integrations

One feature I particularly wanted was traceability. The generated project records the CLI version and starter reference, including the starter commit, so you can identify where it originated.

I've tested the published CLI by generating a project and running its type checks, tests, and production build.

I originally built this for my own development workflow, but I think it could be useful to other developers too.

I'd love honest feedback:

• Would you use a starter like this for your own projects?
• Is the included stack a useful starting point, or would you remove anything?
• What would make you choose this over maintaining your own template?

Website: https://starter.clubedge.live

CLI source: https://github.com/Clubedge/create-clubedge-app

Starter source: https://github.com/Clubedge/clubedge-starter

I'm happy to answer questions about the architecture and implementation.

Hey all, a few months ago I got curious and wrote an S3 client in Rust. To my own surprise it ended up faster than mc, s5cmd and aws-cli at uploading to the self-hosted backends I tested (MinIO, SeaweedFS and Garage), and about level with mc on downloads. I have written a technical blog here, I am still a newbie when it comes to this stuff so bear with me: https://jaeaeich.com/writing/s3z. Please read or listen to it, the benchmarks were only run locally, so I'm sure there's plenty to poke at, and I'd really value hearing what I got wrong or could have done better.

Hey,

A few weeks ago I released vibez (https://github.com/simonepelosi/vibez), an open-source, keyboard-first TUI music player built with Go and Bubble Tea. It lets you stream full-track Apple Music and local audio files directly from your terminal, without needing Cider, Electron wrappers, or official apps.

Today I am happy to announce vibez v1.1.0, introducing native Windows support, crisp dithered album art, and stability fixes.

---

### What is vibez?

For those discovering it for the first time:
- Full-track streaming: Apple Music streaming via a headless Chrome session and Widevine CDM (not 30-second preview clips).
- Local playback: Play your local MP3, FLAC, M4A/AAC, and OGG collection with a built-in 10-band parametric EQ.
- Vibe Mode (v): Type what you are doing or feeling in plain English ("late night lofi coding", "synthwave highway"), and vibez curates a tailored queue for you.
- Discovery and Radio Modes (d / R): Continuous smart auto-queue with dialable similarity from same-artist to pure exploration.
- Vim-style navigation: Jump with gg/G, scroll with j/k, and command line mode with : (:save, :vol, :mute).
- Animated mascot: A terminal bear that naps when idle and dances when music is playing.
- System integration: Discord Rich Presence (RPC), Last.fm scrobbling, and desktop notifications.

---

### What is New in v1.1.0?

#### 1. Native Windows Support (amd64, Pure Go, Zero CGO)
Until now, Windows users had to rely on WSL2. v1.1.0 brings first-class native Windows builds:
- Automated Google Chrome discovery across registry App Paths, per-user paths, and PATH.
- Local audio playback served over an authenticated, loopback HTTP session.
- Native Discord Rich Presence over Windows named pipes (\\.\pipe\discord-ipc-*).
- Windows self-updating with automatic rollback if binary replacement fails.
- Thanks to @hiKareeem for implementing native Windows support (#148).

#### 2. Dithered Album Art (:art) with Unicode Sextants
The :art view has been completely overhauled:
- Downsamples album covers to a 16-color palette and applies Atkinson error-diffusion dithering.
- Renders using Unicode sextants (U+1FB00) (2x3 sub-pixels per terminal cell). On modern terminals that render sextants natively (kitty, Ghostty, WezTerm, Alacritty, foot), covers look sharp and gap-free.
- Automatically falls back to half-blocks on terminals without sextant support (such as Apple Terminal).
- Thanks to @chriopter for implementing this renderer (#146).

#### 3. Linux In-Place Auto-Update Fix
- Fixed an issue where the self-updater on Linux silently failed with ETXTBSY ("Text file busy") when verifying file writability on the executing binary. The updater now probes directory permissions properly.
- Thanks to @ianswope for uncovering and fixing this bug (#160).

#### 4. Concurrency and Stability Polish
- MusicKit Debouncing: Prevented duplicated m.play() calls and race conditions when rapidly changing queues or resuming tracks (thanks to @Wang-Yang-source, #153).
- Data Race Fix: Synchronized request logging across goroutines with a mutex in Apple Music search tests (thanks to @ianswope, #159).

---

### Installation and Getting Started

#### Linux / macOS (One-liner):
curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/simonepelosi/vibez/main/scripts/install.sh | sh

#### Windows:
Download the pre-compiled vibez_windows_amd64.zip archive from the GitHub Releases page, or build from source:
go build -o vibez.exe .

#### Already installed?
Run:
vibez update

#### Test-drive without an Apple Music subscription:
You can test the full TUI with simulated playback using demo mode, or point it to your local music directory:
```sh
vibez --demo
# Or local library:
vibez --local --music-dir ~/Music
```

---

### Links

- GitHub Repository: https://github.com/simonepelosi/vibez
- Release Notes: https://github.com/simonepelosi/vibez/releases/tag/v1.1.0

Feedback, bug reports, and terminal setup impressions are welcome!

From checking disk space to finding what’s using a port, these commands can save you hours of debugging.

📌 Save this reel for the next time your server acts weird.

Which command do you use the most?
#DeveloperFriday #Linux #DevOps #WebDevelopment #Programming #SoftwareEngineering #PieHost

I'm extremely fascinated by maps and by terminal graphics. terrahour is both: a world map in the terminal that shows where it's day, where it's night, and what time it is in your city.

pipx install terrahour

https://github.com/ACoci86/terrahour

Only tested by hand on Linux, so if you try it on a Mac, tell me how it goes.

Hace mas de un mes que me encuentro desarrollando un explorador de archivos desarrollado en JavaFX 21. El github es https://github.com/FranciscoRatti/FileFX

Todo empieza cuando descubri Yazi (Un explorador de archivos en terminal super rapido) y lo pude instalar en mi LinuxMint. Me encanto, y siempre me pasaba que al usar Nemo (El explorador de Mint) siempre tenia que usar el mouse, entonces abria una terminal para usar Yazi con el teclado, lo cual me parecia un poco incomodo el tener que abrir una terminal cada vez que quiera navegar en mi sistema de archivos.

Para resolver este problema decidi lanzarme a hacer un explorador de archivos.

Esta programado DESDE CERO y por mi, no por la IA. Esta 100% desarrollado en JavaFX y compilado a imagen nativa con Liberica NIK (Basicamente es GraalVM con soporte a muchos frameworks) lo cual hace que arranque muy rapido y consuma poco. Todo se puede hacer con atajos de teclado y es sssssssssuper configurable. Mi idea es que sea ligero y que no tenga funciones inutiles que nunca vas a usar.

El tema de la aplicacion esta definidio por UN archivo .css, me gustaria que en un futuro la comunidad desarrolle sus temas y los comparta, osea que simplemente comparta su archivo theme.css y listo.

Me haria mucha ilusion que mas gente se sume al proyecto porque hacer esto yo solo me lleva mucho tiempo.

Las caracteristicas que pienso implementar en el futuro son:

• Pestañas
• Un comando GOTO (Como en Yazi)
• Vista en arbol
• Que se puedan modificar permisos de archivos
• Que se pueda abrir con permisos elevados
• Soporte a la nube

Pronto pienso hacer un .md hablando de la estructura del codigo para la ayudar a la gente que se quiera sumar al desarrollo

Upfront: I wrote it with substantial AI assistance and review the code by hand (progress). The mere Size of the project is not easy to backup as a solo dev in this short amount of time.

It's beta and unofficial, and it writes to Steam's files directly, so back up first.

Hi,

Aurelia is a command-line Steam launcher I've been building since June 2026. It has no CEF or WebView and uses under 50 MB of RAM when idle, so it works well over SSH or on a low-RAM machine.

The Idea behind it was to build a backend system for 3rd party Steam-Launchers or the integration into single source of truth library managers like Heroic and allowing shared drives between Windows & Linux dualboot on exFAT, since Steam refuses to launch there on linux.

Features:

• Install, update, verify and move games, with Steam's library files kept in sync
• A Proton manager (Valve, GE and CachyOS builds) with per-game version pinning, plus optional umu-launcher and luxtorpeda launching
• Downgrading to older game builds, Cloud saves, DLC, Workshop, and friends and chat
• --json output on every command

I'd appreciate bug reports, especially for Proton edge cases, and I'm happy to answer questions about how it works or how the AI was used.

>And about the guy constantly hating my post because of Steamcmd and the authentication:
Steamcmd's usability is below anything that should be used today. It also is not what a backend system needs to provide valuable data like the users full profile, current workshop items or even launching the game with the correct proton version.
Aswell as: The login is being directly passed to the Steam-Endpoint and the session token is stored in the System Keyring. So that's safe. I hope you can understand that web-login token do not provide enough permissions to handle the things Aurelia does.

Note: Half life 1 and some other very old games do not work due to some native compat issues... Try only using the proton launch option and look into the Wiki!
Open an Issue if you encounter something :)

Feel free to test: https://github.com/Drackrath/Aurelia

I kept bouncing between Compass, mongosh, and log files when something felt slow.

So I built MongoScope — a keyboard-driven TUI that:

- Aggregates slow-query patterns from MongoDB logs (or live profiler)

- Shows currentOp with COLLSCAN highlights

- Surfaces replica lag / topology

- Lists indexes and lets you jump from a slow query

Install (Linux/macOS):

curl -fsSL https://raw.githubusercontent.com/prodioslabs/mongoscope/main/install.sh | bash

Repo: https://github.com/prodioslabs/mongoscope

Would love feedback from anyone running Mongo in prod — especially what you’d want next.

Note: GIF is a concept mockup of the flow (welcome → slow queries → live ops → replication), not an exact recording of the current UI.

Think about how many apps you use that have no CLI. Photoshop. Figma. Slack. Notion. Hundreds of tools that only work if a human is clicking buttons.

CLI-Anything is trying to change that. The idea is simple: wrap any software in a CLI layer so that agents (or scripts, or automation pipelines) can drive it the same way a person would.

https://github.com/HKUDS/CLI-Anything

The project comes out of HKUDS, and what they built is a framework that sits between your AI agent and whatever application you point it at. The agent describes what it wants to do in natural language, and CLI-Anything translates that into the actual interactions needed to make it happen. Click this button. Fill that field. Read the output.

It works across desktop apps, web apps, and native system tools. The framework handles the translation layer so you don't have to write custom integrations for every piece of software in your stack.

The vision is compelling. Instead of waiting for every SaaS company to build an API, you just wrap the existing UI and expose it as a programmable interface. That is a genuinely useful idea for anyone doing automation work.

The caveat: it launched at v0.4.0 back in June and hasn't had a major release since. 51,000 stars says people are interested, but the project is still early. Worth watching, maybe not worth building production workflows around just yet.

Metric	Value
Stars	51,159
Forks	4,700
Last release	v0.4.0 (2026-06-25)
Contributors	60+
Languages	Python 97.0%, C# 1.6%

I posted Kranz here as a TUI for local development services and logs. Since then, I've added CLI commands and MCP access to the running services.

The setup I had in mind when I started Kranz is now working. You can start services in the dashboard, detach and manage them from the shell, or give a coding agent access through MCP. All three use the same running services.

The GIF shows this with a small demo project:

kranz status
kranz plan api --operation restart
kranz restart api
kranz runs api --limit 2
kranz logs api --run -1 --tail 3
kranz actions run api/test --param suite=smoke

Here, restarting api also restarts web and worker. plan shows that before you do it. Each service run has separate saved logs, so you can check what happened before a restart. --run -1 selects the latest run.

The last command runs a test action configured in this demo. It accepts a suite parameter, which Kranz checks against the allowed values.

At the end of the GIF, an MCP client reads the service status, API logs, and test result. A coding agent can access those too. These are just a few of the CLI commands. You can also check configs, inspect dependency graphs and ports, get JSON output for scripts, and more.

Recorded on v0.16.4 with demo services.

If you try it on your dev stack, I'd like to know which commands or output feel awkward. If it looks useful to you, I'd also appreciate a star on GitHub.

As in the first post: coding agents wrote most of the Go code. I designed the behavior and UI and tested the result.

GitHub
Docs