nx_txtscan_lib.nx

nx_txtscan_lib.nx -- BYTE-ORIENTED text search. The unit of a match is an OFFSET, never a line. u2605u2605u2605u2605u2605u2605WE DID NOT ONLY AVOID THE UNIX TOOLS, WE INHERITED THEIR UNIT OF MEANING. Every sovereign search organ in this estate -- nx_codegrep, nx_shelltool grep -- scans for a substring and then prints "the line that contains it". That is grep's worldview, reimplemented in NishiLang: it assumes text is a sequence of newline-delimited records. MEASURED 2026-08-05, and this is the bug that motivated the organ: the ruler corpus knowledge/library/write_nsfwbot_flowgpt_2601_14324.txt is 112,755 bytes on ONE line (scraped HTML, as most fetched text is). Asking the sovereign grep for "greeting" returned the ENTIRE FILE as a single match. A search that echoes 112KB for a 8-byte pattern has not searched, it has copied -- and it reports "1 match" while telling you nothing about WHERE. u2605A TOOL THAT DEGRADES TO THE IDENTITY FUNCTION ON ITS HARDEST INPUT STILL REPORTS SUCCESS. So the fix is not a faster grep, it is a different RECORD: the offset. Offsets exist in every byte stream -- minified JSON, scraped HTML, a firmware image, a file with no newline at all -- whereas lines are a property some text happens to have. This organ imposes its own record structure on the input instead of borrowing the input's. PURE: no syscalls, no allocation, caller owns every buffer -- so the gate can prove the search hermetically with in-memory fixtures and no filesystem at all. The CLI (nx_txtscan.nx) adds I/O. license_tier: ORIGINAL module: nishi-core.text.scan capability: TEXT_SCAN_BYTE_ORIENTED