morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4488] [Feature] execute_rizin_command: disable ANSI colour in the one-shot profile (`-e scr.color=0`) #1779

New issue

Closed

opened 2026-10-16 21:10:10 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:10:10 +00:00

Owner

Originally created by @Rinkia on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4488

Before submitting

I searched the open and closed issues for a related report (rizin color, rizin ANSI, scr.color, rizin escape). Nearby open rizin PRs (#4044, #4459, #4464) concern frame and whitespace handling, not colour.
I understand the contribution scope.
This report contains no credentials or private target samples.

Area

Native analysis or decompilation

Current limitation

The one-shot profile runs rizin -N -q -c <command> <path>. -N drops user settings, but rizin still defaults to scr.color=1 when stdout isn't a terminal (rizin -N -q -c "e scr.color" … prints 1). So disassembly in the Evidence carries ANSI escapes on every line. For example, rea execute-rizin-command busybox "pd 13 @ 0x103a0" returns 1,412 bytes of stdout with escapes on all 14 lines:

            \x1b[36m;-- entry0:\x1b[0m
            \x1b[32m0x000103a0\x1b[0m      \x1b[1;92mjal\x1b[0m\x1b[37m   \x1b[0m\x1b[33m0x103c6\x1b[0m…

Agents and tools reading normalized_result.stdout then have to strip terminal control sequences, or they carry them into their reasoning and into token counts. The bytes are faithful to rizin, and REA's raw-output contract is right: they are byte-identical to a direct rizin -N -q -c run, as are iI, iSj and the same command on a DOS COM. But colour is a presentation setting of the session, not analysis output.

Desired outcome and success criteria

Add -e scr.color=0 to the one-shot profile (and probably the persistent session's startup), recorded in command_arguments like the existing flags. Output stays raw apart from that setting. With it, the same command prints 0x000103a0 jal 0x103c6.
A caller who explicitly runs e scr.color=1 in their command still gets colour.

Expected interaction with targets

None beyond the current command execution.

Verification available so far

rea-agents@6.5.0, REA_RIZIN_COMMAND set to the official rizin-v0.9.1-static-x86_64.tar.xz (sha256 9102249a…e8cf, matching the GitHub asset digest). Target: Debian trixie riscv64 busybox-static 1:1.37.0-6+b9, usr/bin/busybox sha256 659d3048…309b.

Originally created by @Rinkia on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4488 ### Before submitting - [x] I searched the open and closed issues for a related report (rizin color, rizin ANSI, scr.color, rizin escape). Nearby open rizin PRs (#4044, #4459, #4464) concern frame and whitespace handling, not colour. - [x] I understand the contribution scope. - [x] This report contains no credentials or private target samples. ### Area Native analysis or decompilation ### Current limitation The one-shot profile runs `rizin -N -q -c <command> <path>`. `-N` drops user settings, but rizin still defaults to `scr.color=1` when stdout isn't a terminal (`rizin -N -q -c "e scr.color" …` prints `1`). So disassembly in the Evidence carries ANSI escapes on every line. For example, `rea execute-rizin-command busybox "pd 13 @ 0x103a0"` returns 1,412 bytes of stdout with escapes on all 14 lines: ```text \x1b[36m;-- entry0:\x1b[0m \x1b[32m0x000103a0\x1b[0m \x1b[1;92mjal\x1b[0m\x1b[37m \x1b[0m\x1b[33m0x103c6\x1b[0m… ``` Agents and tools reading `normalized_result.stdout` then have to strip terminal control sequences, or they carry them into their reasoning and into token counts. The bytes are faithful to rizin, and REA's raw-output contract is right: they are byte-identical to a direct `rizin -N -q -c` run, as are `iI`, `iSj` and the same command on a DOS COM. But colour is a presentation setting of the session, not analysis output. ### Desired outcome and success criteria - Add `-e scr.color=0` to the one-shot profile (and probably the persistent session's startup), recorded in `command_arguments` like the existing flags. Output stays raw apart from that setting. With it, the same command prints `0x000103a0 jal 0x103c6`. - A caller who explicitly runs `e scr.color=1` in their command still gets colour. ### Expected interaction with targets None beyond the current command execution. ### Verification available so far `rea-agents@6.5.0`, `REA_RIZIN_COMMAND` set to the official `rizin-v0.9.1-static-x86_64.tar.xz` (sha256 `9102249a…e8cf`, matching the GitHub asset digest). Target: Debian trixie riscv64 `busybox-static 1:1.37.0-6+b9`, `usr/bin/busybox` sha256 `659d3048…309b`.

bsakaguchi closed this issue

2026-10-31 00:32:45 +00:00

bsakaguchi commented

2026-10-31 00:32:46 +00:00

Author

Owner

@gensokyo-dev commented on GitHub (Oct 19, 2026):

I am taking the one-shot portion of this issue through the Linux analysis-efficiency audit on fresh main aacf740a0.

Independent native verification with official Rizin 0.9.1 (release archive SHA-256 9102249a9f0b6319c5334a2e5cf8d9cc3f2035e1d3def027c41f6a90f647e8cf) confirms default scr.color=1 under pipes. Adding -e scr.color=0 before the caller command changes the same zlib disassembly-plus-byte read from 291 to 170 stdout bytes and libcurl's selected 96-byte read from 2,998 to 1,468 bytes. Deleting only ANSI presentation controls from native baseline output yields the exact plain output.

Native checks also confirm unchanged JSON metadata, caller e scr.color=1 overrides, and literal ANSI bytes returned by pr. These are engine observations, not yet CLI/MCP verification, token savings or end-to-end timing claims. I will keep raw capture at the shared command boundary and measure the public workflows before proposing integration. Persistent debugger startup is outside this one-shot change.

@gensokyo-dev commented on GitHub (Oct 19, 2026): I am taking the one-shot portion of this issue through the Linux analysis-efficiency audit on fresh main `aacf740a0`. Independent native verification with official Rizin 0.9.1 (release archive SHA-256 `9102249a9f0b6319c5334a2e5cf8d9cc3f2035e1d3def027c41f6a90f647e8cf`) confirms default `scr.color=1` under pipes. Adding `-e scr.color=0` before the caller command changes the same zlib disassembly-plus-byte read from 291 to 170 stdout bytes and libcurl's selected 96-byte read from 2,998 to 1,468 bytes. Deleting only ANSI presentation controls from native baseline output yields the exact plain output. Native checks also confirm unchanged JSON metadata, caller `e scr.color=1` overrides, and literal ANSI bytes returned by `pr`. These are engine observations, not yet CLI/MCP verification, token savings or end-to-end timing claims. I will keep raw capture at the shared command boundary and measure the public workflows before proposing integration. Persistent debugger startup is outside this one-shot change.

bsakaguchi referenced this issue

2026-10-31 00:55:19 +00:00

[PR #1779] [MERGED] feat(website): add maintained multilingual editions #4813

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1779

No description provided.

Rows
Columns

[GH-ISSUE #4488] [Feature] execute_rizin_command: disable ANSI colour in the one-shot profile (-e scr.color=0) #1779