On Tue, Mar 12, 2024 at 2:58 PM Kaz Kylheku <k...@kylheku.com> wrote: > What if there existed an alternative delimiting mode: a format where > the character strings are delimited by the two byte sequence \0\n.
How long did it take for the major command-line utilities to initially implement handling null-terminated data? I submitted a feature request to the pcre2 maintainer to implement printing null-terminated filenames from pcre2grep, just back in July of 2022. To his credit, that got done quickly, but that version of the library still missed getting into RHEL 9, unless they've updated it since I've looked. Furthermore, there's little consistency from utility to utility in what the flag to specify null-delimited data is. Now you're asking for a whole lot more of that. > 1. It now works with line buffering. > > 2. Assuming \0 is just an invisible character consumed by terminals with no > effect, this format can be dumped to a TTY where it turns into > lines, as if the nulls were not there. "tr '\0' '\n'" at the end of a pipeline isn't the end of the world. > 3. Portability: doesn't require a new buffering mode that would only > be initially supported in Glibc, and likely never spread beyond > a handful of freeware C libraries. I've got a conversation going with the glibc people, that this list is cc'd on, but who knows if it goes anywhere. In any case, if it's a choice between unbuffered stdout and a whole new data delimiting sequence that now every utility has to support, unbuffered stdout is going to be the answer.
