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

95•caeser•6mo ago

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

quotemstr•6mo 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);
    }

caeser•6mo ago

open a pull request or at least an issue,

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

quotemstr•6mo 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•6mo 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.

quotemstr•6mo 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.

Graziano_M•6mo 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).

quotemstr•6mo ago

So? That you can do something doesn't mean you should. Bypassing libc breaks workflows. Zig and Go aren't worse off on non-Linux platforms because those platforms enforce talking to the kernel through a library. Nobody, in either the Zig or the Go worlds, has justified bypassing libc in terms of concrete and specific user benefit.

Cloudef•6mo ago

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

quotemstr•6mo ago

"[P]oisoning"? Do you have a technical objection, or do you just not like the letter "c"?

throwA29B•6mo ago

libc, starting with errno, continuing with fopen/printf/str* functions, locales, etc is a pile of quick hacks; set of useful abstractions at the time, no doubt! But that time is long gone, for decade(s) it is nothing but a drag.

Cloudef•6mo ago

libc carries lots of global state and implicit ABI that complicates software stacks. While I don't like dynamic libraries in general, dynamic libraries wouldn't be such a mess as they are if libc did not exist. I dream of day we can actually do GPU rendering on linux without libc, and have actual static binaries for graphical apps that work everywhere.

quotemstr•6mo ago

That global state is the coordination problem it's solving. Who owns the thread list? The current process wide setreuid identity? The loaded library list? Debug info registrations? Shared dynamic memory allocations? TLS slots? Someone has to, and that someone is libc. Avoiding it because it has state is to be confused about the whole concept of an OS.

Yeah, it's mixed up with the same library that provides sscanf and strcat. So what? You don't have to call them.

alexrp•6mo ago

If you need libc, just link libc? It's bizarre to me that you think less of Zig for giving you the choice.

caeser•6mo 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

AndyKelley•6mo ago

You don't have anything to apologize for, you just are partway through your journey of learning about static libraries, dynamic libraries, and compilation units :-)

arp242•6mo 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•6mo 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•6mo 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•6mo 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•6mo 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.

bsder•6mo 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.

codethief•6mo ago

> 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.

That's a bummer to hear, I've been wanting to use Ghostty for a while but that'd be a showstopper for me. Is there a GitHub issue tracking this?

bsder•6mo ago

> That's a bummer to hear, I've been wanting to use Ghostty for a while but that'd be a showstopper for me. Is there a GitHub issue tracking this?

You should try it out for yourself first. It could be something weird in my setup since I'm running an immutable distro.

And, no, it doesn't have a Github issue because I didn't feel like tracking down all the moving pieces to replicate it when I can just resolve it with a package install.

quotemstr•6mo ago

> Ghostty

I bet it has a setting to set TERM. I mean, TERM is hardly a panacea, but it's better than blindly spewing terminal control control codes without configuration or control or feature discovery.

> 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".

And what, every terminal application should have its own special knob for you to tell it what kind of terminal you have?

This whole discussion is a great example of why Chesterton's fence is a thing. The terminal world is already pretty fragmented. Suggestions to ignore the only even halfway decent widely-supported app-agnostic config knob without replacing it with something better are short-sighted. In any multi-party ecosystem, you need some way for different programs, written by different people at different times, to discover each other's capabilities.

bsder•6mo ago

> And what, every terminal application should have its own special knob for you to tell it what kind of terminal you have?

No, they should default to the only sane thing left, ignore TERM/termcap/terminfo, and leave the people who still want to run a VT-52 or Tek4014 in the dustbin.

There is a single combination for terminal usage which isn't broken in 2025--ANSI escape codes for output with the Kitty escape codes for input.

(And don't get me started about resolving the dependencies around ncurses, terminfo, etc. because some program is welded to a 15 year old version of curses ...)

quotemstr•6mo ago

Most terminals are not kitty. Should my program not work with them? What happens when kitty adds a feature? How do I know whether it's supported?

What we really need is robust feature detection, not TERM. The terminal universe doesn't seem particularly receptive to the idea: https://github.com/alacritty/vte/issues/98

In the meantime, we have TERM. I'll stop advocating people use TERM when the terminal ecosystem learns what the web had to learn ages ago and embraces feature detection. It's pointless to break even UA detection.

(Unfortunately, as the thread shows, XTGETCAP is broken in too many places to use.)

otabdeveloper4•5mo ago

> I wish people wouldn't hardcode terminal escape codes

Why not? The ad-hoc standard set of terminal emulator escape codes is much more widely supported than whatever is in terminfo.

You're not getting any compatibility bonuses via terminfo, only extra pain.

90s_dev•6mo ago

Looks like a good zig argparse lib.

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

caeser•6mo ago

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

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

revskill•6mo ago

Will zig include a rustimport similar to cimport ?

Cloudef•6mo ago

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

throwawaymaths•6mo ago

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

kingo55•6mo 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•6mo 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.

kingo55•6mo ago

I stand corrected — Very unusual given how "similar" your accents are and your proximity to the states.

folkrav•5mo ago

Canada is unusual in many ways, I’d say hehe. We never separated from the British like the colonies did, so the languages (quebecois French, too!) have kept a lot of British influences. About 2/3 of its relatively small population of 41 million lives in the first 100km north of the US border - an individual in British-Columbia is 8000km+ and 5-6 time zones away from someone in the Atlantic provinces. We’re similar to the US in how different every province can be from one another, I think.

hotpocket777•6mo ago

What is a “CLI framework”?

sothatsit•6mo ago

It takes care of the CLI argument parsing, command routing, and help formatting.

I recently wrote a CLI manually, thinking, CLIs are so simple why would you need a framework? At the end of writing it, I had just ended up writing my own CLI framework anyway. It gets tedious without one, even though none of the things the framework does are particularly complicated.

stratts•6mo ago

Looks nice! Some thoughts:

  const now = ctx.flag("now", bool); // type-safe flag access

This is type-safe, but only at run time. Since your flags are (or could be) known at compile time, it would be nice to have this throw a compile error if the type is invalid.

Or even better - fully lean into comptime and generate a struct so you can use field access without specifying a type:

  const now = ctx.flag.now;

Superman copy found in mum's attic is most valuable comic ever at $9.12M

An Interview with Unity CEO Matthew Bromberg About Turnarounds

ADHD and Monotropism (2023)

Personal blogs are back, should niche blogs be next?

Kodak Ran a Secret Nuclear Device in Its Basement for Decades

Helping Valve to power up Steam devices

Agent Design Is Still Hard

Samsung's 60% DRAM price hike signals a new phase of global memory tightening

The Connectivity Standards Alliance Announces Zigbee 4.0 and Suzi

Weight-sparse transformers have interpretable circuits [pdf]

Show HN: Wealthfolio 2.0- Open source investment tracker. Now Mobile and Docker

Why DETRs are replacing YOLOs for real-time object detection

Single-Celled Marine Organisms Resulted in an Influential Illustrated Book

Moss Survives 9 Months in Space Vacuum

How I learned Vulkan and wrote a small game engine with it (2024)

Sharper MRI scans may be on horizon thanks to new physics-based model

We should all be using dependency cooldowns

Event Sourcing in Go: From Zero to Production

Discontinuation of ARM Notebook with Snapdragon X Elite SoC

Concrete Shipbuilding – Argentina

Childhood Friends, Not Moms, Shape Attachment Styles Most

LAPD helicopter tracker with real-time operating costs

You can make PS2 games in JavaScript

Self-hosting a NAT Gateway

Pixar: The Early Days A never-before-seen 1996 interview

My private information is worth $30

Make product worse, get money

Automating rootless Docker host updates with Ansible

Shop Sans is a typeface for curved text paths

Libpng 1.6.51: Four buffer overflow vulnerabilities fixed

Superman copy found in mum's attic is most valuable comic ever at $9.12M

An Interview with Unity CEO Matthew Bromberg About Turnarounds

ADHD and Monotropism (2023)

Personal blogs are back, should niche blogs be next?

Kodak Ran a Secret Nuclear Device in Its Basement for Decades

Helping Valve to power up Steam devices

Agent Design Is Still Hard

Samsung's 60% DRAM price hike signals a new phase of global memory tightening

The Connectivity Standards Alliance Announces Zigbee 4.0 and Suzi

Weight-sparse transformers have interpretable circuits [pdf]

Show HN: Wealthfolio 2.0- Open source investment tracker. Now Mobile and Docker

Why DETRs are replacing YOLOs for real-time object detection

Single-Celled Marine Organisms Resulted in an Influential Illustrated Book

Moss Survives 9 Months in Space Vacuum

How I learned Vulkan and wrote a small game engine with it (2024)

Sharper MRI scans may be on horizon thanks to new physics-based model

We should all be using dependency cooldowns

Event Sourcing in Go: From Zero to Production

Discontinuation of ARM Notebook with Snapdragon X Elite SoC

Concrete Shipbuilding – Argentina

Childhood Friends, Not Moms, Shape Attachment Styles Most

LAPD helicopter tracker with real-time operating costs

You can make PS2 games in JavaScript

Self-hosting a NAT Gateway

Pixar: The Early Days A never-before-seen 1996 interview

My private information is worth $30

Make product worse, get money

Automating rootless Docker host updates with Ansible

Shop Sans is a typeface for curved text paths

Libpng 1.6.51: Four buffer overflow vulnerabilities fixed

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

Comments