--- Christopher Faylor <[EMAIL PROTECTED]> wrote:
> There's no need for a loop. There really shouldn't be any need to
> accommodate the missing colon but it doesn't hurt too much to add a test
> case.
>
> I've checked in a modified version of your patch. I cleaned up some of
> the non-GNU form
On Tue, Feb 26, 2002 at 08:59:45PM -0800, Joshua Daniel Franklin wrote:
>Well, except that that loop does away with the whole point--eating the
>trailing '$'. Here's another go. I tested it with "$Revision$",
>"$Revision:$", "$Revision: $ ", "$Revision: 1.22 $ ", and "$Revision: 1.2 2 $ "
>(in th
On Wed, Feb 27, 2002 at 02:11:11PM +0100, Jan Nieuwenhuizen wrote:
>"Chris January" <[EMAIL PROTECTED]> writes:
>
>> Since when have common sense and the law gone together.
>
>Hmm, that's a good point. I think there was some logic to what I
>said, but that may well be irrelevant.
>
>> I would poi
"Chris January" <[EMAIL PROTECTED]> writes:
> Since when have common sense and the law gone together.
Hmm, that's a good point. I think there was some logic to what I
said, but that may well be irrelevant.
> I would point out that the GCC team have recently changed all their
> copyrights from
> >> - Copyright 1998, 1999, 2000, 2001 Red Hat, Inc.
> >> + Copyright 1998-2002 Red Hat, Inc.
> > A quick note about changing Copyright years like this... don't do it!
The
> > two are *not* equivalent.
>
> No, but need they be? The silly comma separated list will get out of
> hand, at some p
"Chris January" <[EMAIL PROTECTED]> writes:
>> - Copyright 1998, 1999, 2000, 2001 Red Hat, Inc.
>> + Copyright 1998-2002 Red Hat, Inc.
> A quick note about changing Copyright years like this... don't do it! The
> two are *not* equivalent.
No, but need they be? The silly comma separated list
> - Copyright 1998, 1999, 2000, 2001 Red Hat, Inc.
> + Copyright 1998-2002 Red Hat, Inc.
A quick note about changing Copyright years like this... don't do it! The
two are *not* equivalent.
See http://www.gnu.org/prep/maintain_8.html on the GNU website for more
information, but basically if a n
--- Robert Collins <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Joshua Daniel Franklin [mailto:[EMAIL PROTECTED]]
>
> +const char *revision="$Revision: 1.22 $";
>
> This is suspect: The revision string can look like $Revision:$ in some
> circumstances - see man co
> -Original Message-
> From: Joshua Daniel Franklin [mailto:[EMAIL PROTECTED]]
It's not - strace is manually entered version info.
> Anyway here is a patch for cygcheck that I think does the
> right thing. Somebody want to take a look?
+const char *revision="$Revision: 1.22 $";
T
On Mon, Feb 25, 2002 at 01:23:51PM -0500, Christopher Faylor wrote:
>Well, cygpath is wrong. cygcheck is wrong too, under this scenario, but
strace
>not quite as wrong since it at leasts puts the version in its own
>string. I believe,
> > I'm not sure I understand. Hard-code the revision in a const char
>
> man co might enlighten you.
>
I'm afraid I've never used CVS/RCS before. :(
Am I reading this right? If I just put $Revision$ in the code, once
it's checked in/out that'll be replaced with the correct version number?
I s
===
- Original Message -
From: "Joshua Daniel Franklin" <[EMAIL PROTECTED]>
> I'm not sure I understand. Hard-code the revision in a const char
man co might enlighten you.
Rob
On Mon, Feb 25, 2002 at 01:23:51PM -0500, Christopher Faylor wrote:
>Well, cygpath is wrong. cygcheck is wrong too, under this scenario,
>but not quite as wrong since it at leasts puts the version in its own
>string. I believe, it used to do something similar to cygpath but I
>changed it, intend
On Mon, Feb 25, 2002 at 10:15:06AM -0800, Joshua Daniel Franklin wrote:
>>Adding version numbers is not a bad idea (although, I can't honestly
>>think of a time when it would have helped to have this information).
>>Adding version numbers in the middle of the program, in the middle of a
>>text str
> Adding version numbers is not a bad idea (although, I can't honestly
> think of a time when it would have helped to have this information).
> Adding version numbers in the middle of the program, in the middle of a
> text string is, IMO, a bad idea. The version number should be at
> the top of t
> Adding version numbers is not a bad idea (although, I can't honestly
> think of a time when it would have helped to have this information).
> Adding version numbers in the middle of the program, in the middle of a
> text string is, IMO, a bad idea. The version number should be at
> the top of t
> Adding version numbers is not a bad idea (although, I can't honestly
> think of a time when it would have helped to have this information).
> Adding version numbers in the middle of the program, in the middle of a
> text string is, IMO, a bad idea. The version number should be at
> the top of t
> Adding version numbers is not a bad idea (although, I can't honestly
> think of a time when it would have helped to have this information).
> Adding version numbers in the middle of the program, in the middle of a
> text string is, IMO, a bad idea. The version number should be at
> the top of t
--- Robert Collins <[EMAIL PROTECTED]> wrote:
> Some confusion here: I was meaning that having something like:
> const char *revision="$Revision: $ ";
> in the file allows you to then use:
> const char *version = revision[11];
> to obtain the correct version number.
>
> Rob
I'm not sure I unders
> -Original Message-
> From: Joshua Daniel Franklin [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 25, 2002 4:22 PM
> To: [EMAIL PROTECTED]
> Subject: help/version patches
>
>
> I've got patches for each of the utils to add/correct the help and
> v
On Sun, Feb 24, 2002 at 09:21:43PM -0800, Joshua Daniel Franklin wrote:
>I've got patches for each of the utils to add/correct the help and
>version output options. There are 13 in all. I incremented the
>version number 0.01 from the ones in CVS/Entries with the
>exception of cygpath. I also added
I've got patches for each of the utils to add/correct the help and
version output options. There are 13 in all. I incremented the
version number 0.01 from the ones in CVS/Entries with the
exception of cygpath. I also added a line based on one found in
strace that imbeds the compile date into the v
22 matches
Mail list logo
