starred/opentui

Fork 0

mirror of https://github.com/anomalyco/opentui.git synced 2026-04-25 04:55:58 +03:00

[GH-ISSUE #671] createCliRenderer should pass process.env to Zig opts.env_map #179

New issue

Closed

opened 2026-03-02 23:45:06 +03:00 by kerem · 4 comments

kerem commented

2026-03-02 23:45:06 +03:00

Owner

Originally created by @JackCA on GitHub (Feb 11, 2026).
Original GitHub issue: https://github.com/anomalyco/opentui/issues/671

Full disclosure, I have no experience with Zig and this issue is written with LLM assistance:

checkEnvironmentOverrides can't read environment variables when running as a Bun FFI shared library on Linux.
std.process.getEnvMap() fails and the catch return silently exits the function — no env-based detection runs
at all.

env_map_storage = std.process.getEnvMap(std.heap.page_allocator) catch return;

process.env in JS has the correct values (COLORTERM=truecolor, TERM_PROGRAM=iTerm.app, etc.), but the Zig side
sees none of them. Initial capabilities report rgb=false, hyperlinks=false, empty terminal name.

The opts.env_map injection mechanism from #623 would fix this if the JS binding wired process.env through it.
Currently createRenderer only passes testing and remote — no env map.

Repro: Run any OpenTUI app via Bun on Linux where libopentui.so is loaded via FFI (ldd libopentui.so → statically
linked). Set COLORTERM=truecolor and observe that rgb stays false.

Impact: COLORTERM, TERM, TERM_PROGRAM, TMUX, and all OPENTUI_FORCE_* overrides are invisible to the Zig layer.

OpenTUI 0.1.78, Bun 1.2.x, Linux aarch64

Originally created by @JackCA on GitHub (Feb 11, 2026). Original GitHub issue: https://github.com/anomalyco/opentui/issues/671 _Full disclosure, I have no experience with Zig and this issue is written with LLM assistance:_ `checkEnvironmentOverrides` can't read environment variables when running as a Bun FFI shared library on Linux. `std.process.getEnvMap()` fails and the `catch return` silently exits the function — no env-based detection runs at all. ```zig env_map_storage = std.process.getEnvMap(std.heap.page_allocator) catch return; ``` process.env in JS has the correct values (COLORTERM=truecolor, TERM_PROGRAM=iTerm.app, etc.), but the Zig side sees none of them. Initial capabilities report rgb=false, hyperlinks=false, empty terminal name. The opts.env_map injection mechanism from #623 would fix this if the JS binding wired process.env through it. Currently createRenderer only passes testing and remote — no env map. Repro: Run any OpenTUI app via Bun on Linux where libopentui.so is loaded via FFI (ldd libopentui.so → statically linked). Set COLORTERM=truecolor and observe that rgb stays false. Impact: COLORTERM, TERM, TERM_PROGRAM, TMUX, and all OPENTUI_FORCE_* overrides are invisible to the Zig layer. - OpenTUI 0.1.78, Bun 1.2.x, Linux aarch64

kerem closed this issue

2026-03-02 23:45:06 +03:00

kerem commented

2026-03-02 23:45:07 +03:00

Author

Owner

@kommander commented on GitHub (Feb 11, 2026):

Thanks for the disclosure.

Zig should see the same env as the bun process, when it succeeds, so there is no need to pass through the env from the bun/js process.

@simonklee we probably should log the error instead of silently failing, with logger.zig to make it visible in the console, so we can see why it fails.

@kommander commented on GitHub (Feb 11, 2026): Thanks for the disclosure. Zig should see the same env as the bun process, when it succeeds, so there is no need to pass through the env from the bun/js process. @simonklee we probably should log the error instead of silently failing, with `logger.zig` to make it visible in the console, so we can see why it fails.

kerem commented

2026-03-02 23:45:07 +03:00

Author

Owner

@simonklee commented on GitHub (Feb 11, 2026):

@simonklee we probably should log the error instead of silently failing, with logger.zig to make it visible in the console, so we can see why it fails.

Agree

@simonklee commented on GitHub (Feb 11, 2026): > @simonklee we probably should log the error instead of silently failing, with logger.zig to make it visible in the console, so we can see why it fails. Agree

kerem commented

2026-03-02 23:45:07 +03:00

Author

Owner

@JackCA commented on GitHub (Feb 12, 2026):

FWIW, the original driver for this was to debug why hyperlinks weren't being enabled in a linux-based docker container run inside of iTerm. Just wanted to share that context in case it is relevant.

@JackCA commented on GitHub (Feb 12, 2026): FWIW, the original driver for this was to debug why hyperlinks weren't being enabled in a linux-based docker container run inside of iTerm. Just wanted to share that context in case it is relevant.

kerem commented

2026-03-02 23:45:07 +03:00

Author

Owner

@simonklee commented on GitHub (Feb 24, 2026):

Fixed by github.com/anomalyco/opentui@ba8822eec7

@simonklee commented on GitHub (Feb 24, 2026): Fixed by https://github.com/anomalyco/opentui/commit/ba8822eec79278d8a1188e03a5c10b647c5efbb5

kerem referenced this issue

2026-03-02 23:46:06 +03:00

[PR #179] [MERGED] chore(core): rework shutdown sequence #353

kerem referenced this issue

2026-03-02 23:47:10 +03:00

[PR #488] [CLOSED] chore: remove unmaintained vue and go packages #575

kerem referenced this issue

2026-03-14 09:20:14 +03:00

[PR #179] [MERGED] chore(core): rework shutdown sequence #1133

kerem referenced this issue

2026-03-14 09:32:15 +03:00

[PR #488] [CLOSED] chore: remove unmaintained vue and go packages #1356