Re: RFC: null-terminated separators for rlog

[Jonathan Noack]

On 04/20/06 18:34, Paul Eggert wrote:
> "Jonathan Noack" <address@hidden> writes:
>> The purpose of this option is not to present output for human
>> consumption; rather, it is to allow scripts/programs to parse the
>> output.
> 
> But you also mentioned that you wanted to be able to put rlog output into
> rlog entries, which means you need a general quoting mechanism.

I mentioned that others might do so; however, they should not be using
this option.  Even if they do, the NUL byte won't be visible on the
console/terminal and wouldn't get copied/pasted.  They would have to
redirect the rlog output to a file or directly into the commit log for
the NUL byte to make it.

> Let's put it another way.  There is nothing in the current spec that
> prevents NUL bytes from being in rlog output.  The current RCS
> commands let you put NUL bytes there.  So, merely outputting a single
> NUL byte at the end of each log entry will not suffice, in general, to
> let programs disambiguate the output.  You need a more-general way
> whereby rlog can represent arbitary data in the rlog entry, while
> still being parsable.

If you read the prototype patch you'll note that I'm APPENDING the NUL
byte to the existing separators, not replacing them with a NUL byte.
The separators are therefore on a line by themselves with lots of
dashes/equal signs followed by a NUL byte and ending in a newline.  It
is highly improbable this sequence would randomly appear in a commit
log.  I described above what it would take for a user to unwittingly
include it.

I'm looking for a workable solution.  Given that rlog's output may be
pasted into a commit log by well-meaning but misguided people, we need
an option for different separators.  I thought a NUL byte would be a
good choice because it provides some protection even if people use the
proposed option when they shouldn't.  This was the best solution I
found, but I welcome alternatives... :)

-Jonathan