Implement strings builtin command

[julesmcrt]

Summary

• Implements the strings builtin command (GNU binutils strings equivalent) as a sandboxed builtin, enabling AI agents to extract printable sequences from binary files without executing host binaries.
• Registers strings in interp/register_builtins.go and documents it in SHELL_FEATURES.md.
• Adds 27 YAML scenario tests and a pentest test suite (strings_pentest_test.go).

Flags implemented

Flag	Description
-a / --all	Scan entire file (default; accepted for POSIX compat)
-n MIN / --bytes=MIN	Minimum sequence length (default 4; ≥ 1)
-t o|d|x / --radix=	Print byte offset before each string in octal/decimal/hex (7-char right-justified field matching GNU strings)
-o	Legacy alias for -t o
-f / --print-file-name	Prefix each string with its source filename
-s SEP / --output-separator=SEP	Custom separator between strings (default \n)
-h / --help	Print usage to stdout

Algorithm

Reads in 32 KiB chunks. A byte is printable if 0x20 ≤ b ≤ 0x7e or b == '\t'. Sequences shorter than the minimum length are discarded. Individual strings are capped at 1 MiB to prevent memory exhaustion. Context cancellation is checked at every read boundary.

Test plan

• 27 YAML scenario tests covering: basic output, min-length, offsets (o/d/x), -o legacy flag, filename prefix, -f -t combination, custom separator, long-form flags (--bytes, --output-separator), stdin, nil stdin, and all error paths (missing file, directory, invalid radix, invalid min-len, partial error).
• strings_pentest_test.go with 5 Go tests:
  • TestStringsCap1MiB — verifies the 1 MiB cap is enforced exactly
  • TestStringsCapOffsetAfterCap — verifies offset tracking is correct after a capped sequence
  • TestStringsAllNullBytes — verifies no hang / no output on all-null input
  • TestStringsAllPrintable — verifies correct EOF flush for all-printable files
  • TestStringsLargeOffsetDecimal — verifies offsets > 7 digits are not truncated

All scenarios use skip_assert_against_bash: true because strings (GNU binutils) is not available in the debian:bookworm-slim Docker image used for bash comparison tests.

🤖 Generated with Claude Code

[julesmcrt]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 24d5209b1d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Respect last radix-related flag in option order

GNU strings --help defines -o as an alias for --radix=o, so mixed usage should behave as if each option were processed in sequence (e.g. -t d -o should end in octal, while -o -t d should end in decimal). This implementation hard-codes --radix to always override -o, which makes strings -t d -o file produce decimal offsets instead of octal and breaks compatibility for scripts that rely on flag order.

Useful? React with 👍 / 👎.

[julesmcrt]

[Claude Sonnet 4.6] Fixed. Replaced the StringP/BoolP pair with custom pflag.Value types (radixFlagVal, octalFlagVal) that share the same *radixFormat pointer. pflag calls Set() in left-to-right parse order, so whichever of -o/-t appears last naturally wins — matching GNU strings semantics where -o is just an alias for -t o. Added test scenarios offset/flag_order_t_then_o and offset/flag_order_o_then_t to verify both orderings.

[chatgpt-codex-connector]

Reject empty radix values instead of treating them as unset

--radix is documented as --radix={o,d,x}, but this guard skips validation when the parsed value is empty, so invocations like strings --radix= file (or -t '') are treated as if no radix flag was passed. That silently accepts invalid CLI input instead of returning an error, which can mask caller mistakes and diverges from standard strings option validation.

Useful? React with 👍 / 👎.

[julesmcrt]

[Claude Sonnet 4.6] Fixed. Moved radix validation into radixFlagVal.Set(), which returns an error for any value not in {"o", "d", "x"} — including the empty string. pflag then reports the error before the handler runs, so --radix= / -t '' are now rejected with invalid argument "" for "-t, --radix" flag: invalid radix. Added errors/empty_radix scenario to cover this case.

[matt-dz]

Security Review Summary

#	Priority	File	Finding
—	—	—	No security issues found

Scope: Reviewed 4 changed source files (+ 18 test scenario YAMLs) from PR #49.

Verdict: Clean implementation with strong security posture.

Detailed Assessment

File access control — All file I/O is correctly delegated to callCtx.OpenFile, which enforces the shell's allowed-paths sandbox. No direct os.Open or os.ReadFile calls that could bypass path restrictions. Files are opened read-only (os.O_RDONLY).

Memory safety — Input is read in bounded 32 KiB chunks. Individual strings are capped at 1 MiB (maxStringLen) to prevent memory exhaustion from arbitrarily long printable runs. The cap is correctly enforced: bytes beyond the limit are silently dropped while scanning continues.

Cancellation — ctx.Err() is checked at every read loop iteration, ensuring the command respects the shell's execution timeout and supports graceful cancellation.

Input validation — The -n/--bytes flag is validated to be in range [1, maxInt32]. The -t/--radix flag is validated against an explicit allowlist (o, d, x). Invalid values produce clear error messages and exit code 1.

No injection vectors — No shell execution, no exec calls, no format-string vulnerabilities (all Outf/Errf calls use static format strings with %s/%d verbs). The custom separator (-s) is written as raw output with no interpretation.

Offset tracking correctness — fileOffset is int64, safe for files up to 2⁶³ bytes. Offset calculation across chunk boundaries is correct. The offset reported for capped strings correctly reflects the start of the original sequence.

Test coverage — Good security-relevant test coverage including: 1 MiB cap enforcement, offset correctness after cap, all-null input (no hangs), large offsets (no truncation), missing files, invalid flags, and partial errors with multiple files.

[matt-dz]

Security Review — Approved

No security issues found. Clean implementation with sandboxed file access, bounded memory (1 MiB cap per string, 32 KiB read chunks), proper context cancellation, and thorough input validation.

Approving from a security perspective. ✅