Skip to content(if available)orjump to list(if available)

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

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

9 comments

·May 25, 2025

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

revskill

Will zig include a rustimport similar to cimport ?

90s_dev

Looks like a good zig argparse lib.

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

caeser

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

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

quotemstr

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

> 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

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.

caeser

open a pull request or at least an issue,

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

quotemstr

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

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.