[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: null-terminated separators for rlog

From: Jonathan Noack
Subject: Re: RFC: null-terminated separators for rlog
Date: Fri, 21 Apr 2006 01:37:58 -0400
User-agent: Thunderbird 1.5 (X11/20060331)

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... :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]