[HN Gopher] Show HN: Zli - A Batteries-Included CLI Framework fo...
___________________________________________________________________
Show HN: Zli - A Batteries-Included CLI Framework for Zig
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
Author : caeser
Score : 51 points
Date : 2025-05-25 16:52 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| quotemstr wrote:
| 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 wrote:
| open a pull request or at least an issue,
|
| im always open to improvement, but i wanna keep it 100% zig.
| quotemstr wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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).
| caeser wrote:
| 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
| arp242 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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.
| 90s_dev wrote:
| Looks like a good zig argparse lib.
|
| How do you like Zig compared to TypeScript? What would you like
| to see improved?
| caeser wrote:
| zig is amazing. i am legit more productive in zig.
|
| as Andrew (zig creator) said, zig makes you understand how
| computers work.
| revskill wrote:
| Will zig include a rustimport similar to cimport ?
| Cloudef wrote:
| Haven't tried it but there's build.crab
| https://github.com/akarpovskii/build.crab
| kingo55 wrote:
| 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.
___________________________________________________________________
(page generated 2025-05-25 23:00 UTC)