Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–40 of 41 posts

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

#31

Post by quotemstr »

bsder wrote: post #30
quotemstr wrote: post #27

Earlier quoted context omitted.

> 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 K…

> 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 fo…

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

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

#32

Post by stratts »

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;

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

#33

Post by sothatsit »

hotpocket777 wrote: post #29

What is a “CLI framework”?

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.

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

#34

Post by AndyKelley »

caeser wrote: post #15
AndyKelley wrote: post #9

Earlier quoted context omitted.

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 po…

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

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 :-)

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

#35

Post by throwA29B »

quotemstr wrote: post #23
Cloudef wrote: post #21

Earlier quoted context omitted.

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

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

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.

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

#36

Post by kingo55 »

folkrav wrote: post #22
kingo55 wrote: post #19

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.

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

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

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

#37

Post by alexrp »

quotemstr wrote: post #12
AndyKelley wrote: post #9

Earlier quoted context omitted.

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 po…

> 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 g…

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

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

#38

Post by Cloudef »

quotemstr wrote: post #23
Cloudef wrote: post #21

Earlier quoted context omitted.

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

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

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.

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

#39

Post by quotemstr »

Cloudef wrote: post #38
quotemstr wrote: post #23

Earlier quoted context omitted.

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

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.

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.

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

#40

Post by otabdeveloper4 »

quotemstr wrote: post #2

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"); @cIn…

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

Post reply on HN