Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.unix.questions
Subject: Re: RCS problem
Message-ID: <6796@jpl-devvax.JPL.NASA.GOV>
Date: 15 Jan 90 21:41:50 GMT
References: <1000@whizz.uucp> <1990Jan15.043956.21644@athena.mit.edu>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Distribution: na
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 37

In article <1990Jan15.043956.21644@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
: 
: In article <1000@whizz.uucp>, bbh@whizz.uucp (Bud Hovell) asks why log
: comments are not preceded by "# " when he checks in the file
: Pnews.header and then checks it out again.
: 
: From the man page for rcs(1):
: 
:      -cstring   sets the comment leader to string. The comment
:                 leader is printed before every log message line
:                 generated by the keyword $Log$  during checkout
:                 (see co). This is useful for programming
:                 languages without multi-line comments. During rcs
:                                                        ^^^^^^^^^^
:                 -i or initial ci, the comment leader is guessed
:                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:                 from the suffix of the working file.
:                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: 
: It pretty much sucks that the man page does not elaborate on how the
: "guessing" is done.  The file rcsfnms.c in the sources contains the
: following table:
:
: [table deleted]

While rcs has a lot to be said in its favor, I've always thought it was
Really Silly that rcs doesn't just go out and look to see how $Log$ is
commented already, and use that for the default.  It's almost always
perfectly obvious from that line what the comment leader should be.
Of course, you don't necessarily have the file at rcs -i time, but you
certainly have it before you really need to know the comment leader.

This solution would be space efficient, more portable, more succinct,
more upwardly comptible with new filename conventions, and more often right.

Larry Wall
lwall@jpl-devvax.jpl.nasa.gov