Show HN: Zli – A Batteries-Included CLI Framework for Zig

54 caeser 21 5/25/2025, 4:52:14 PM github.com ↗

I built zli, a batteries-included CLI framework for Zig with a focus on DX and composability.

Key features:

- Typed flags with default values and help output - Rich formatting, and layout support - Command trees with isolated execution logic - It’s designed to feel good to use, not just to work. - Built for real-world CLI apps, not toy examples.

Would love feedback, feature ideas, or thoughts from other Zig devs.

repo here: https://github.com/xcaeser/zli

Comments (21)

kingo55 · 35m ago

Cool name - I bet it sounds great with an American/Canadian accent. Using the UK/Australia/NZ accent, it's pronounced "zed-ell-aye", so I didn't grok it instantly like most of the audience here would.

folkrav · 21m ago

“Zee” is getting more popular especially with gen Z (unintended) who were raised with more widespread access to American media, social or otherwise. Like many Commonwealth countries, most of Canada uses “zed”, however.

90s_dev · 4h ago

Looks like a good zig argparse lib.

How do you like Zig compared to TypeScript? What would you like to see improved?

caeser · 3h ago

zig is amazing. i am legit more productive in zig.

as Andrew (zig creator) said, zig makes you understand how computers work.

revskill · 2h ago

Will zig include a rustimport similar to cimport ?

Cloudef · 1h ago

Haven't tried it but there's build.crab https://github.com/akarpovskii/build.crab

throwawaymaths · 32m ago

probably never since even cimport is going to eventually move to an internal c compiler written in zig.

quotemstr · 4h ago

No terminfo support? I'm probably tilting at windmills here, but I wish people wouldn't hardcode terminal escape codes. Considering zig's good interop with C, wiring up a call to tigetstr().

It's also important not to emit escape codes at all when TERM=dumb. (You'll get this behavior automatically if you implement color support by asking terminfo to the escape codes.)

    const c = @cImport({
        @cInclude("ncurses.h");
        @cInclude("term.h");
    });

    pub fn main() !void {
        // Initialize terminfo
        _ = c.setupterm(null, 1, null);

        // Get capability strings
        const setaf = c.tigetstr("setaf");  // set foreground
        const setab = c.tigetstr("setab");  // set background
        const sgr0 = c.tigetstr("sgr0");    // reset

        // Parameterize for red foreground
        const red = c.tparm(setaf, c.COLOR_RED, 0, 0, 0, 0, 0, 0, 0, 0);

        // Use it
        _ = c.printf("%sThis is red%s\n", red, sgr0);
    }

arp242 · 3h ago

> I wish people wouldn't hardcode terminal escape codes.

A bunch of commonly used escape codes are pretty much universally identical. I wrote about this before: https://www.arp242.net/safeterm.html

By and large I think terminfo/$TERM is outdated, or at least partly. It's a 1970s/80s thing when terminals all did radically different things. But that hasn't been the case for decades now. You still need it for some things (kind of), but basic support like colours? Not so much.

quotemstr · 3h ago

Except all those times you don't want color at all.

> By and large I think terminfo/$TERM is outdated, or at least partly.

It's not outdated. It's a Chesterton's fence. Disregard for interoperability and feature discovery is why the terminal ecosystem has such immense difficulty getting traction on advanced features.

arp242 · 2h ago

NO_COLOR exists, and is fairly widely supported. TERM=dumb to disable colour was always a hack at best because this also disables other things like "clear line" and generally leads to weird output.

> It's a Chesterton's fence.

It's not. The world has changed. Everyone uses \x1b[1m to make text bold today but in the past there were a few dozen ways from different vendors of (hardware) terminals to make text bold. But this situation no longer exists. Like I already said: you still need it for some things – there's a reason I compiled a "safe terminal escape code" list. But for many things you don't.

quotemstr · 2h ago

NO_COLOR is far from universally supported (even people who bother to check TERM don't know about it) and typically isn't configured to pass through sudo or ssh.

arp242 · 1h ago

> NO_COLOR is far from universally supported

I never claimed that. The sudo or ssh configuration is up to you. Or else there's |cat, which often works when NO_COLOR doesn't.

Either way, terminfo was never intended to allow users to disable colours. Certainly not via TERM=dumb – that was always a hack. If you want to disable colours then there are better ways.

caeser · 3h ago

open a pull request or at least an issue,

im always open to improvement, but i wanna keep it 100% zig.

quotemstr · 3h ago

You're using libc already. There is no such thing as a pure zig program. Please, be a good citizen of the ecosystem.

If I were trying a program and saw that it disrespected me by ignoring a clear preference in my environment not to use colors, I wouldn't use that program again.

AndyKelley · 2h ago

This is factually incorrect. While some operating systems use libc as the syscall ABI, this is not the case for Windows or Linux. On those systems, by default, Zig programs do not link libc; they make DLL calls or syscalls directly.

The project in question, however, does seem to link libc in the build script for no reason, as well as create a static library for no reason (it doesn't export any functions). As Loris pointed out to me today, this is likely caused by the `zig init` template highlighting static linking rather than modules, which is unfortunate since modules are the preferred way for Zig code to import other Zig code. We'll be adjusting that accordingly.

caeser · 1h ago

i do link libc because i just copied build.zig from another project i made zig-dotenv and forgot to remove the line

seems like i created a bit of a fuss there, my bad

quotemstr · 2h ago

> On those systems, by default, Zig programs do not link libc; they make DLL calls or syscalls directly.

Well, that makes me think a lot less of Zig. Bypassing libc makes programs less cooperative members of the broader ecosystem. There's value in libc being able to act as a userspace intermediary between programs and the kernel. (That's why Windows doesn't provide a way to make direct system calls: you're going to go through kernel32/user32/etc. -> ntdll.dll and _then_ the kernel.)

Go bypassing libc causes all sorts of annoying havoc, e.g. fakeroot stuff not working. This is not behavior to be encouraged.

And for what benefit? Being able to say you're libc-free, as if that were a feature not a bug? You don't even have split stacks. Is it just that libc has "c" in the name and you want to make sure nobody thinks you're C? libc being called lib-c is an historical artifact. It's not even about C itself. It's more like Windows ntdll.

Bypassing libc is fundamentally selfish behavior. It breaks a longstanding ecosystem coordination mechanism for zero actual benefit.

But hey, I can still use "zig cc" as a convenient cross-compiler when I'm writing in a better-behaved language -- so thanks, I guess.

Cloudef · 25m ago

libc's been poisoning software long enough. Glad it's optional in Zig on platforms that provide stable system ABI.

Graziano_M · 1h ago

On windows you make system calls through the DLLs because the system calls can change on you. On linux you're pretty much guaranteed that the API to the kernel will not change. It will get extended, but the semantics of old calls will not change).

bsder · 1h ago

> I'm probably tilting at windmills here, but I wish people wouldn't hardcode terminal escape codes.

Please, no. There is no reason for this to be querying a hack from 1978 in 2025 when there are effectively two output terminal protocols--Windows and ANSI. And there is only a single terminal input protocol (kitty) that isn't brain damaged and allows you to do something super complex like "detect when Shift Key is pressed and released".

Ghostty actually does something like you ask, and I really wish it wouldn't. It's a pain in the ass with virtualization. I have Ghostty on my host, but I have to install Ghostty in all my guest instances to pick up some stupid termcap/terminfo entry, or I get garbage all over my terminal.

Ask HN: What are you working on? (May 2025)

Ask HN: Career Change Confusion

Ask HN: Selling software to company I work for as an employee

Ask HN: Go deep into AI/LLMs or just use them as tools?

Ask HN: Can you give tips on writing a README for project?

Ask HN: What HN posts inspired or changed your perspective the most?

Ask HN: How do you promote your personal projects with a limited budget?

Ask HN: What's your favorite architect/editor pair with Aider?

It's 2025, AI is everywhere, why can't something summarize podcasts for me?

ESP32 MCP Server

Ask HN: Do you have a side project you're getting tired of?

Ask HN: Senior SaaS developer wanting to pivot

Ask HN: How to Make Friendster Great?

Ask HN: AI Reading List

Ask HN: What projects do you donate to?

Ask HN: How do you keep on top of all of the AI tools and new changes?

We sold our first AI agent to a legacy industry–now we're stuck. Help us Advice?

I spent 15 years developing a tool to make sense of software version numbers

Ask HN: Places in the UK / Europe Related to computers

Ask HN: Pros and cons of offering a self-hosted version of your SaaS?

Modern Python Boilerplate – good package basic structure

Ask HN: Where to find UX design resources?

Ask HN: Fakespot is shutting down July 1. Alternatives?

Ask HN: Engineering Statics and Dynamics book recommendation

What If Every Picture You've Ever Seen Already Exists?

Tell HN: The Hetzner Experience - Invisible Outages

Ask HN: Don't You Mind That LLMs Are Mostly Proprietary?

AskHN: Best, simplest platform to run a Technical Interview on?

Ask HN: How are you using LLMs for research on a library of journal articles?

Ask HN: Agent / workflow frameworks or roll your own?

Ask HN: What makes a programming language great for code generation?

Ask HN: Does the languages we speak affect the way we think?

Show HN: Zli – A Batteries-Included CLI Framework for Zig

Comments (21)