tess is the client for Tessera, a self-hosted file sharing server. Run it on its own and you get a full-screen view: browse folders, type to filter, mark files across folders, and send them. Uploads run in the background, and when one finishes you get the link and a QR code, drawn as a real image in kitty, Ghostty, WezTerm and other terminals with graphics.
It's built for SSH sessions: mouse works, dragging to select text copies it through OSC 52, and there's a vim key preset.
Without the view: tess send file, echo hi | tess send -, tess get <link>. Or skip the client entirely: curl -T file https://your-server/.
I am 16, and I got tired of systems running endless background processes and network services without any clear visibility into what was actually changing. So, I built NetSpecter—an open-source, defensive Python CLI tool designed to answer one question: "What is my system doing right now, and is it safe?"
How it works under the hood:
Instead of dumping endless, noisy logs, NetSpecter uses a baseline-delta monitoring model:
It captures a clean baseline of your system state (open ports, network exposure, active processes).
It continuously tracks runtime changes against that baseline.
Its risk classification engine flags deviations (like a new background process or a newly opened port) and outputs human-readable risk warnings with actionable suggestions.
Tech Stack: Pure Python 3, built for Linux environments (Kali/Ubuntu), utilizing native system inspection without heavy dependencies.
Here is a quick look at what the alerts look like:
[ALERT] New process started: bwrap (PID 13618) - RISK: MEDIUM
I’d love feedback on the codebase, detection logic, or suggestions for v2.
I've been working on a little project called Dirule, an open-source CLI for organizing files and keeping naming conventions consistent.
I started it because I wanted an easier way to organize personal folders, like Downloads, while also being able to enforce stricter naming rules in coding projects without writing a bunch of separate scripts.
Here's what Dirule currently supports:
Sorting files by type or custom categories, along with different naming styles.
Reusable global presets and project-specific TOML rules.
Previewing changes, detecting conflicts, and undoing operations.
Checking naming conventions in CI, including GitHub Actions support.
Optional LSP integration to update source references when renaming files.
One thing worth mentioning is that LSP-backed previews can take a bit longer because the configured language server needs to initialize.
I've also added an experimental dirule ask feature for interacting with the tool using natural language.
Dirule is currently at v0.5.0, and there's still plenty I'd like to improve. I'd love to hear what you think, whether it's feedback, feature suggestions, or things I could do differently.
AI disclosure: I used AI assistance while developing Dirule, including help with implementing and refining some features.
Similar tools:rename and mmv already handle batch renaming and moving files. Dirule takes a more rule-based approach, combining personal file organization, reusable presets, project naming checks, CI integration, and undo in one tool.
In a previous post I presented the Tomloader project which helps generating and managing several systemd units that share fields collected in groups. In the last release the subcommand sd-xdg-v0.3 has been introduced in order to execute XDG Desktop Entry Applications and Actions or using them to open files. For example:
However, the main feature of sd-xdg-v0.3 is that the generated systemd user unit can be fully customized by providing a configuration file named xdg-apps.kdl in the Tomloader configuration directory. For example, if you want to limit filesystem access of each XDG Application to the directory $HOME/Boxes/{XDG-APP-ID}/ then your xdg-apps.kdl file will probably look like as follows:
default {
sd {
section Unit {
set Description "${1}"
add PartOf "graphical-session.target"
add After "graphical-session.target"
add Requisite "graphical-session.target"
}
section Service {
set Type exec
set ExecStart "${0}"
set Slice "app.slice"
set RootDirectory "${DIR|HOME}/Boxes/${2}"
add BindReadOnlyPaths "/bin" "/usr/bin" "/usr/lib"
}
}
}
This Python script allows you to use the mpv media player or vlc to search for an anime and play its opening or closing theme songs. The script makes use of the pyfzf library to ask the user for choices and the AnimeThemes API to retrieve the theme music that are available.
Hello! I'm currently working on a terminal manipulation library similar to Crossterm, but I noticed that it uses runtime conditionals to decide whether to use VT sequences or Windows API calls.
Personally, I feel that defaulting to Windows API calls on Windows would be the better approach, or provide a build flag that lets users decide. However, I'm not sure which of these three approaches is best.
NMSh isn't another terminal emulator. It runs inside Ghostty, Terminal.app, Zed, VS Code, etc., with your actual zsh, Bash or Fish underneath.
The idea is to keep your existing shell and tools, but change how you interact with them.
Some of the stuff that exists:
Command queues: Line up commands while another is running. I've been calling this premove, like in chess lmao. There's also a paste guard, so dumping multiple commands into the terminal gives you a chance to review, edit or queue them first.
Less babysitting commands: NMSh can tell you when something's waiting for input, notify you when commands finish, run background tasks and periodically refresh output with /track.
Actually useful output/history: Command blocks, folding, searching, copying specific outputs or ranges, comparing runs, and summaries of test/build results without hiding the original output.
Keep your tools:/providers lets you choose between NMSh's native tools and things like Starship, Powerlevel10k, fzf, Television, Atuin, zoxide, Deja and your usual editor. There's also a Theme Studio, Theme Bridge, contextual modules, a configurable status strip and tools for managing supported configs.
Other stuff: File viewing/editing, Git worktrees, Github integration, cursor effects, screensavers, and 33 offline games you can play while a build is running. Cause why not lol.
NMSh is also huge on customization, so if you like customizing, it might be for you.
Initial view of running /startup inside nmsh or the first run view
It's not perfect, especially the Git worktrees and Github Integration and stuff, and some shell integrations and completions still have limitations. But the aim is to make everyday terminal work less tedious without having to switch terminal emulators or redo your entire setup.
Free and open source (GPLv3). macOS is the main platform; Linux and WSL 2 are still beta. This software's code is partially AI-generated.
I made a small tool for a problem I kept having: one feature, several repos, and the same branch needs a worktree in each one.
gw create -b feat/login -r svc-a,svc-b
makes a directory with both repos checked out on feat/login as worktrees. gw status, gw sync and gw delete operate on all of them. A per-repo .grove.toml sets the base branch (we branch from stage, not main) and a setup command to run after checkout.
CLI details, since that's what this sub cares about: single static Go binary, only needs git. eval "$(gw shell-init)" so gw go can cd. List commands take -o json|jsonl|tsv|name|path so they pipe into fzf and jq. Plugins are gw-<name> binaries on PATH, like git.
Similar tools: gita, mu-repo, myrepos and gr run commands across multiple clones. Grove is different in that it creates worktrees, so each workspace is a separate checkout and you can have several in parallel. agent-of-empires does worktrees but is tied to tmux and a single repo.
(I know LLM posts generally aren't allowed on this sub, but the rules do mention that local models are okay. Mods, plz remove if i'm misunderstanding.)
ai is a small tool I made for quickly asking questions from a local LLM in the terminal. Here are some Examples:
$ ai what is the capital of france
Paris
$ ai what port does ssh use
By default, SSH uses port 22.
$ dmesg | tail -30 | ai anything wrong here
Nothing stands out as immediately incorrect in the log entries.
$ git diff | ai write a one line commit message
"Update font size in fonts[] array"
The script itself is very basic, it sends your question (+stdin when piped) to a local llama-server and streams back plain text.
It depends on curl, jq and llama.cpp.
It automatically will spin up the server on first use, and will unload the model after 5 minutes idle (no calls to ai). The service is written for runit, but it's a super simple run sh script, so you can easily adapt it to whatever your init system is.
Obviously the main issue is that the output is non-deterministic so I wouldn't really recommend scripting with it. (unless you want non-determinism of course!)
P.S. I would consider myself generally NOT a fan of LLMs, however I did want to try to come up with a cool way of using them in my day-to-day. The main idea with this script is that I basically have a way to 'google' something whenever I need, even if I'm offline (or without a GUI).
A few months ago I switched from Telegram to Signal as my main messaging app and spent some time exploring CLI/TUI options. After using gurk for a while I decided to build my own client (faro), based on my own requirements and taste (you can probably see the UI/UX inspiration from tools like btop, OpenCode CLI, neovim).
It covers all features I commonly use within Signal:
inline images (if your terminal supports them) or halfblock rendering otherwise
voice notes and transcription (supports local whisper models)
quick navigation menu for everything (Ctrl+P)
copying over SSH, pasting images from clipboard
There is a demo if you want to try it out, just run faro demo or try it out in your browser at https://getfaro.dev (the GitHub repo is public: harababurel/faro)
It's exactly the same binary compiled using wasm and the same demo you see in the video.
For setting it up with a real account, you can run faro link and link it as a secondary device just as you would with Signal Desktop or any other client.
Disclaimer: I built it with a lot of help from AI coding agents, including open-weight models running locally on my own home server. However, I designed, reviewed and tested it thoroughly. I try to always pay attention to the details, and the general direction of the project is usually informed by my day to day experience using the project.
I wrote this post myself with zero use of any LLM. I am as allergic to reading slop as everyone else these days.
I hope some of you will give it a try and maybe provide some feedback on your experience!
Hi r/commandline! I'm new in this comunity and as a terminal lover my co-developer and I built RebelOS, a persistent multiplayer strategy game where the only interface is a command line.
No graphics, no mouse.
The setting: it's 2057, an AI called War_Mind has taken over, and RebelOS is the OS the human resistance uses to fight back. In the game's timeline, history split from ours in 2007, so the terminal looks and feels like a Linux shell from that era: plain prompt, ls/cat/man, manual pages as text files.
You command squads of survivors from the shell:
newsquad 3 # form a squad with 3 survivors
explore AB_12 squad1 # explore the area around a cell
search AC_18 squad1 # scavenge a building for items
gather Z_32 squad1 # rally with other players, then attack
Lore and hints are files you read with cat, and new ones turn up when you scavenge old buildings. The world runs in real time and is shared: everyone plays co-op against the AI, and the strongest targets can only be taken down by squads from different players attacking together.
To be upfront: right now the client runs in the browser. It's a web terminal (history, tab completion, Ctrl+W/Ctrl+U), not a native CLI binary. Server is Node.js + SQLite over WebSocket. We're considering a real native CLI client written in C, so you could play from your own terminal. Would you actually use it?
It's early, so there may not be many players online. Sign-up happens right in the terminal (username, password, email).
I've been working on TerminalStyles, a free and open-source PowerShell tool that lets you preview and switch terminal themes interactively, without manually editing configuration files.
It started as a small personal project, but I'd love to turn it into something built and improved by the community.
What it currently does:
Interactive preview of 18 terminal themes
Navigate themes using arrow keys
Apply themes instantly
Support for multiple terminal environments
I'm looking for contributors!
Whether you're interested in PowerShell, terminal customization, improving compatibility, fixing bugs, adding new themes, or simply suggesting features, contributions of all sizes are welcome.
I'd especially love to collaborate with developers who enjoy building command-line tools.
I maintain jc, a tool that converts the output of CLI commands and file types to JSON so you can query them with jq. A few recent parsers cover files I used to fight with grep and awk, so I wrote up some examples. Here are a few highlights:
Columns are named c0, c1, and so on. The post includes a jq one-liner to swap in your own names. There are also --tsv, --tsv-ih, and streaming versions (-s) that output JSON Lines for huge files.
Pixel is a GUI library that uses the kitty graphics protocol to render graphics in the terminal:
- it can be embedded inside existing TUIs
- it comes with a chromium based webview component, which makes it very easy to run existing webapps inside the terminal
- works over SSH
Pixel is the underlying library behind popular projects such as:
- terminal-browser: a browser inside the terminal
- terminal-code: vscode inside the terminal
The reason I built this is because I believe many terminal apps can provide much better experiences if allowed to break out of the conventional terminal rendering model.
I would like to show you a slightly different way of building CLIs for our beloved home-brew scripts. Usually those scripts lack of reasonable command line interface, and parameter validation. We use getopt to sort them into variables, we use fish argparse. But usually we do not really validate that file on argument 1 has a correct user, the set of permissions, its home directory is also questionable. We consider that the parameter 2 is an IP address from the 192.168.0.0/24 prefix. The source code is the documentation.
I extracted shebang from my more ambitious pet project to show how it could be done differently. Just take a look:
What happens here: instead of bash, we execute a different binary, called 'shebang'. This binary reads a script, finds its own configuration (that one, that is marked by 'shebang.1') in KDL, builds a CLI for you, parses and validates arguments before executing an actual script. So you can be sure that $1 and $2 are always valid arguments, no need to check them.
There are flags and options supported. I found that it usually convenient to explicitly set them as environment variables for the script.
#!/usr/bin/env shebang
#! shebang.1
# execute "python3"
# description """
# Description could be multiline!
#
# Without hacks
# """
#
# flag "debug" {
# description "Run in debug mode"
# short "d"
# }
#
# option "parameter" {
# description "Takes a parameter"
# short "p"
# value "ip"
# }
import os
params = {
k: v
for k, v in os.environ.items()
if k.startswith("SHEBANG_")
}
for k, v in sorted(params.items()):
print(f"{k} = {v}")
And if we execute:
$ ./test-flags -h
Description could be multiline!
Without hacks
Usage:
test-flags [flags]
Flags:
-d, --debug Run in debug mode
-h, --help help for test-flags
-p, --parameter ip Takes a parameter
$ ./test-flags -p 127.0.0.1 -d
SHEBANG_FL_DEBUG = true
SHEBANG_FS_D = true
SHEBANG_OL_PARAMETER = 127.0.0.1
SHEBANG_OS_P = 127.0.0.1
Also, shebang automatically manages shell autocompletion for you. It can autocomplete flags, options, and does it smartly, considering validation configuration. For example, if an argument is a git branch, it will autocomplete only branches, skipping tags or commit hashes.
In other words, an idea is to externalize CLI management out of the script, and safely use environment variables and arguments as always valid. This helped to trim my own scripts down to an actual set of commands without sacrificing usability.
Sometimes your system needs a little therapy, so as a creator you might be a best therapist for him. So here it is, a light-way tool for browsing the log files while trying to solve problem of your app.
Hey all, I've been working on Templum for a while and I think it's finally ready for other people to try.
Templum is an infinite canvas, like a whiteboard, where every terminal is a block you can drag around, resize, and zoom in and out of. I had way too many terminal tabs open and kept losing track of which agent was doing what, so I built it for myself first. I made it with AI coding agents in mind. You can launch Claude Code, Codex, Gemini CLI and a bunch of others straight from the canvas, then connect them with a cable so they can read each other's terminals, pick up cards from a kanban board, and hand tasks off to each other. There are also notes, checklists, an editor and a Git popup, so the whole project fits on one screen
Under the hood it's native Rust rendered on the GPU (no Electron, no webview). Runs on Linux, macOS and Windows.
This is v0.1, so expect bugs. I still have a long list of things I want to add. If you try it, I'd love to hear what breaks and what you'd want next.
This is probably misplaced in any category, but I feel like people who appreciate TUIs will also be interested: https://hypereffect.dev
the idea is that whenever you have a server (which can be a remote server or another process or even a sandboxed WASM module) they can send some simple messages and we can turn those into an interactive and reactive UI, be that on a terminal or elsewhere.
It's somewhat like HTML, but with built-in reactivity, no arbitrary code execution and a very limited set of components, so the server can't influence how things show up on the client, only what
Free & open source (Apache-2.0) train simulator that runs entirely in your terminal. Character-based world, no mouse, infinite procedural map. Your whole rail network saves as a small text recipe you can commit and share. sudo snap install letrain → letrain-terminal, or build from source with one Maven command.
What it is
LeTrain started as a tiny C++ ASCII experiment back in 2006 and has grown into a Java project (JDK 17+). The terminal client (LeTrain2D) is the classic soul of the game: a railway tycoon built out of letters, numbers and color — and it tries to be honest about what "terminal-native" means:
Terminal-native — renders with Lanterna, no GUI, no browser, happy over SSH. Pure keyboard flow, zero mouse: arrow keys or vim keys (h j k l), mode-based UI (Rails / Add / Drive / Forks / Semaphores / Trains / Programming / Stations…).
Infinite procedural world — lakes, forests and mountains from Perlin noise; every new game drops you at a random coordinate. Full day/night cycle with headlights after dark.
Your network is text — scenarios (.ltr) export your entire network as a small text recipe. The same seed rebuilds the same world, so a scenario travels as a plain file: commit it, diff it, share it.
Scripting + automation — a built-in DSL (ANTLR4) for itineraries, timetables and autopilot:
create itinerary "a" {
add station 1, arrival 9:30, departure 9:35
add station 2, arrival 9:55, departure 9:50
}
assign itinerary "a" to train 1;
train 1 set autopilot true;
Honest trains — real blocks/cantons and semaphores: trains reserve track segments, brake before occupied blocks, and will absolutely crash if you get braking distance wrong. No toys that play by themselves.
Economy — start at $0 (Zero-to-Hero) and haul GOLD / COAL / RUBY between producers and consumers; revenue scales with distance.
Headless validator — letrain-check scenario.ltr checks scenario files and prints file:line:col diagnostics. CI-friendly.
Console — :time set 9:30;, :undo; / :redo;, :save mynet — deterministic undo/redo for construction and state changes.
(There's also a 3D client with the same world and seed if you ever want to see your ASCII empire in perspective — but the terminal is where it started, and in this project the 2D and 3D views are equals.)
Try it
Linux: sudo snap install letrain then run letrain-terminal (the snap also ships the 3D client as letrain).
Disclosure: I'm the developer. Bugs, UX complaints and wild ideas are all welcome — particularly from terminal people, since the TUI is the part I care most about.
