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
quotemstr•2h ago
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.)
caeser•1h ago
im always open to improvement, but i wanna keep it 100% zig.
quotemstr•1h ago
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•37m ago
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•8m ago
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.
Bypassing libc is fundamentally selfish behavior. It breaks a longstanding ecosystem coordination mechanism for zero actual benefit.
arp242•1h ago
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•1h ago
> 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•28m ago
> 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•2m ago