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