Patrick Steinhardt <ps@xxxxxx> writes: >> True. >> >> I also wonder who it helps to use <LF> as a field separator. Once >> we require consumers to properly handle <NUL>, it does not make it >> easier to write such a consumer script if the format uses <LF> >> there, does it? Besides, wouldn't it possible that field may have >> to contain any end-user specified key, including <LF>? If so, we'd >> need to have some quoting/unquoting mechanism in the syntax anyway, >> so the behefit of using <NUL> to simplify the parser would already >> be lost. > > Scripts should always use NUL, true. But sometimes a user may want to > inspect these key-value pairs, as well, just to double check a certain > property of the repository, or to figure out how a certain property > looks like while writing a script that parses the same key-value but > NUL-separated pairs. Using NUL bytes would be a bit of a pain in that > situation. True. I do not think the discussion so far had much focus on helping human users doing ad-hoc inspection, and NUL can be annoying for such use cases (even though tr is your friend). > I'm not really too sure whether we need to bother with quoting. The > LF-separated output shouldn't ever be used in a script, so I don't mind > too much whether it always works. But I guess it wouldn't be hard either > to just have something like: > > if (uses_newline) > quote_c_style(...); > > So with that in mind it's probably better to just do the right thing. The right thing being...? Use <LF> as a record separator to avoid forcing <NUL> on possible human readers, and adopt quoting in a rare case where <LF>s or <NUL>s need to be in the payload? Or something else? Thanks.
