Re: [patch]lock and unlock like GnuRCS
Fritjof, have you let the gnu rcs project know about the segfault?
Maybe see how they choose to fix things and then follow their lead?
On Mon, Oct 6, 2014 at 10:47 AM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
I think that GNU RCS segfaulting for -u -l is enough justification to do
what we like, so a message (and last flag wins) like -L/-U would be fine
with me.
But if we want to do what they probably meant to happen then better to
match -l -u like Fritjof's diff.
On Fri, Oct 03, 2014 at 12:55:35PM +0200, Otto Moerbeek wrote:
On Thu, Oct 02, 2014 at 12:56:10AM +0100, Nicholas Marriott wrote:
OTOH, check out what we do with rcs -L and -U...
I kinda like that, because it tells you exactly what it is doing.
-Otto
On Thu, Oct 02, 2014 at 12:54:13AM +0100, Nicholas Marriott wrote:
Matching GNU RCS seems preferable to me but I don't feel strongly about
it.
I wouldn't mention this in the man page, it hardly seems like behaviour
anyone should (or will need to) rely on.
On Wed, Oct 01, 2014 at 07:41:52PM -0400, Daniel Dickman wrote:
posix commands (like ls(1) for example) keep the last option when
mutually exclusive options are specified. does it make sense to keep
rcs consistent with that convention? also is a man page diff needed?
On Oct 1, 2014, at 7:17 PM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
The existing behaviour isn't wildly useful, makes sense to me, ok
nicm
On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch wrote:
Hi tech,
the OpenRCS rcs command produces the following output if -l and -u
is
used in the same command:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
I've looked at GnuRCS and it has another way to handle these
parameters
(it seems the other BSDs use GnuRCS, too).
Debian 7.5:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
rcs: foo.txt,v: no lock set on revision 1.1
1.1 locked
$ rcs -u1.1 -l1.1 foo.txt
Segmentation fault
Well, I think the Segmentation fault isn't that important :),
but GnuRCS
does not lock and unlock a file by using the same command like
OpenRCS.
I think the different implementations of RCS should share the same
behaviour:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
done
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 unlocked
done
fritjof
Index: rcsprog.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
retrieving revision 1.151
diff -u -p -r1.151 rcsprog.c
--- rcsprog.c12 Jul 2011 21:00:32 -1.151
+++ rcsprog.c3 Aug 2014 15:42:34 -
@@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
-/* XXX - Check with -u flag. */
-lrev = rcs_optarg;
-rcsflags |= RCSPROG_LFLAG;
+if (!(rcsflags RCSPROG_UFLAG)) {
+lrev = rcs_optarg;
+rcsflags |= RCSPROG_LFLAG;
+}
break;
case 'm':
if (logstr != NULL)
@@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
-/* XXX - Check with -l flag. */
-urev = rcs_optarg;
-rcsflags |= RCSPROG_UFLAG;
+if (!(rcsflags RCSPROG_LFLAG)) {
+urev = rcs_optarg;
+rcsflags |= RCSPROG_UFLAG;
+}
break;
case 'V':
printf(%s\n, rcs_version);
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote:
Fritjof, have you let the gnu rcs project know about the segfault?
Maybe see how they choose to fix things and then follow their lead?
That will only slow things down. Do what -L -U does is better, imo.
-Otto
On Mon, Oct 6, 2014 at 10:47 AM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
I think that GNU RCS segfaulting for -u -l is enough justification to do
what we like, so a message (and last flag wins) like -L/-U would be fine
with me.
But if we want to do what they probably meant to happen then better to
match -l -u like Fritjof's diff.
On Fri, Oct 03, 2014 at 12:55:35PM +0200, Otto Moerbeek wrote:
On Thu, Oct 02, 2014 at 12:56:10AM +0100, Nicholas Marriott wrote:
OTOH, check out what we do with rcs -L and -U...
I kinda like that, because it tells you exactly what it is doing.
-Otto
On Thu, Oct 02, 2014 at 12:54:13AM +0100, Nicholas Marriott wrote:
Matching GNU RCS seems preferable to me but I don't feel strongly
about
it.
I wouldn't mention this in the man page, it hardly seems like
behaviour
anyone should (or will need to) rely on.
On Wed, Oct 01, 2014 at 07:41:52PM -0400, Daniel Dickman wrote:
posix commands (like ls(1) for example) keep the last option when
mutually exclusive options are specified. does it make sense to
keep rcs consistent with that convention? also is a man page diff
needed?
On Oct 1, 2014, at 7:17 PM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
The existing behaviour isn't wildly useful, makes sense to me, ok
nicm
On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch
wrote:
Hi tech,
the OpenRCS rcs command produces the following output if -l and
-u is
used in the same command:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
I've looked at GnuRCS and it has another way to handle these
parameters
(it seems the other BSDs use GnuRCS, too).
Debian 7.5:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
rcs: foo.txt,v: no lock set on revision 1.1
1.1 locked
$ rcs -u1.1 -l1.1 foo.txt
Segmentation fault
Well, I think the Segmentation fault isn't that important :),
but GnuRCS
does not lock and unlock a file by using the same command like
OpenRCS.
I think the different implementations of RCS should share the
same
behaviour:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
done
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 unlocked
done
fritjof
Index: rcsprog.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
retrieving revision 1.151
diff -u -p -r1.151 rcsprog.c
--- rcsprog.c12 Jul 2011 21:00:32 -1.151
+++ rcsprog.c3 Aug 2014 15:42:34 -
@@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
-/* XXX - Check with -u flag. */
-lrev = rcs_optarg;
-rcsflags |= RCSPROG_LFLAG;
+if (!(rcsflags RCSPROG_UFLAG)) {
+lrev = rcs_optarg;
+rcsflags |= RCSPROG_LFLAG;
+}
break;
case 'm':
if (logstr != NULL)
@@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
-/* XXX - Check with -l flag. */
-urev = rcs_optarg;
-rcsflags |= RCSPROG_UFLAG;
+if (!(rcsflags RCSPROG_LFLAG)) {
+urev = rcs_optarg;
+rcsflags |= RCSPROG_UFLAG;
+}
break;
case 'V':
printf(%s\n, rcs_version);
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 7, 2014 at 3:34 AM, Otto Moerbeek o...@drijf.net wrote: On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote: Fritjof, have you let the gnu rcs project know about the segfault? Maybe see how they choose to fix things and then follow their lead? That will only slow things down. Do what -L -U does is better, imo. -Otto between the 2 choices this would be my choice too.
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote:
Fritjof, have you let the gnu rcs project know about the segfault?
Maybe see how they choose to fix things and then follow their lead?
No, I have not.
I hope they follow the tech@ mailing list. :)
On Mon, Oct 6, 2014 at 10:47 AM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
I think that GNU RCS segfaulting for -u -l is enough justification to do
what we like, so a message (and last flag wins) like -L/-U would be fine
with me.
But if we want to do what they probably meant to happen then better to
match -l -u like Fritjof's diff.
On Fri, Oct 03, 2014 at 12:55:35PM +0200, Otto Moerbeek wrote:
On Thu, Oct 02, 2014 at 12:56:10AM +0100, Nicholas Marriott wrote:
OTOH, check out what we do with rcs -L and -U...
I kinda like that, because it tells you exactly what it is doing.
-Otto
On Thu, Oct 02, 2014 at 12:54:13AM +0100, Nicholas Marriott wrote:
Matching GNU RCS seems preferable to me but I don't feel strongly
about
it.
I wouldn't mention this in the man page, it hardly seems like
behaviour
anyone should (or will need to) rely on.
On Wed, Oct 01, 2014 at 07:41:52PM -0400, Daniel Dickman wrote:
posix commands (like ls(1) for example) keep the last option when
mutually exclusive options are specified. does it make sense to
keep rcs consistent with that convention? also is a man page diff
needed?
On Oct 1, 2014, at 7:17 PM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
The existing behaviour isn't wildly useful, makes sense to me, ok
nicm
On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch
wrote:
Hi tech,
the OpenRCS rcs command produces the following output if -l and
-u is
used in the same command:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
I've looked at GnuRCS and it has another way to handle these
parameters
(it seems the other BSDs use GnuRCS, too).
Debian 7.5:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
rcs: foo.txt,v: no lock set on revision 1.1
1.1 locked
$ rcs -u1.1 -l1.1 foo.txt
Segmentation fault
Well, I think the Segmentation fault isn't that important :),
but GnuRCS
does not lock and unlock a file by using the same command like
OpenRCS.
I think the different implementations of RCS should share the
same
behaviour:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
done
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 unlocked
done
fritjof
Index: rcsprog.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
retrieving revision 1.151
diff -u -p -r1.151 rcsprog.c
--- rcsprog.c12 Jul 2011 21:00:32 -1.151
+++ rcsprog.c3 Aug 2014 15:42:34 -
@@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
-/* XXX - Check with -u flag. */
-lrev = rcs_optarg;
-rcsflags |= RCSPROG_LFLAG;
+if (!(rcsflags RCSPROG_UFLAG)) {
+lrev = rcs_optarg;
+rcsflags |= RCSPROG_LFLAG;
+}
break;
case 'm':
if (logstr != NULL)
@@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
-/* XXX - Check with -l flag. */
-urev = rcs_optarg;
-rcsflags |= RCSPROG_UFLAG;
+if (!(rcsflags RCSPROG_LFLAG)) {
+urev = rcs_optarg;
+rcsflags |= RCSPROG_UFLAG;
+}
break;
case 'V':
printf(%s\n, rcs_version);
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 07, 2014 at 09:34:33AM +0200, Otto Moerbeek wrote: On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote: Fritjof, have you let the gnu rcs project know about the segfault? Maybe see how they choose to fix things and then follow their lead? That will only slow things down. Do what -L -U does is better, imo. Otto, so you appreciate a diff more like this one? -Otto fritjof Index: rcsprog.c === RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v retrieving revision 1.152 diff -u -p -r1.152 rcsprog.c --- rcsprog.c 2 Oct 2014 06:23:15 - 1.152 +++ rcsprog.c 7 Oct 2014 12:53:10 - @@ -235,9 +235,10 @@ rcs_main(int argc, char **argv) lkmode = RCS_LOCK_STRICT; break; case 'l': - /* XXX - Check with -u flag. */ + if (rcsflags RCSPROG_UFLAG) + warnx(-u overridden by -l); lrev = rcs_optarg; - rcsflags |= RCSPROG_LFLAG; + rcsflags = RCSPROG_LFLAG; break; case 'm': if (logstr != NULL) @@ -273,9 +274,10 @@ rcs_main(int argc, char **argv) lkmode = RCS_LOCK_LOOSE; break; case 'u': - /* XXX - Check with -l flag. */ + if (rcsflags RCSPROG_LFLAG) + warnx(-l overridden by -u); urev = rcs_optarg; - rcsflags |= RCSPROG_UFLAG; + rcsflags = RCSPROG_UFLAG; break; case 'V': printf(%s\n, rcs_version);
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 07, 2014 at 02:56:07PM +0200, Fritjof Bornebusch wrote: On Tue, Oct 07, 2014 at 09:34:33AM +0200, Otto Moerbeek wrote: On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote: Fritjof, have you let the gnu rcs project know about the segfault? Maybe see how they choose to fix things and then follow their lead? That will only slow things down. Do what -L -U does is better, imo. Otto, so you appreciate a diff more like this one? well, almost. I think it should be clear one flag and set one, not clear all and set one. -Otto fritjof Index: rcsprog.c === RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v retrieving revision 1.152 diff -u -p -r1.152 rcsprog.c --- rcsprog.c 2 Oct 2014 06:23:15 - 1.152 +++ rcsprog.c 7 Oct 2014 12:53:10 - @@ -235,9 +235,10 @@ rcs_main(int argc, char **argv) lkmode = RCS_LOCK_STRICT; break; case 'l': - /* XXX - Check with -u flag. */ + if (rcsflags RCSPROG_UFLAG) + warnx(-u overridden by -l); lrev = rcs_optarg; - rcsflags |= RCSPROG_LFLAG; + rcsflags = RCSPROG_LFLAG; break; case 'm': if (logstr != NULL) @@ -273,9 +274,10 @@ rcs_main(int argc, char **argv) lkmode = RCS_LOCK_LOOSE; break; case 'u': - /* XXX - Check with -l flag. */ + if (rcsflags RCSPROG_LFLAG) + warnx(-l overridden by -u); urev = rcs_optarg; - rcsflags |= RCSPROG_UFLAG; + rcsflags = RCSPROG_UFLAG; break; case 'V': printf(%s\n, rcs_version);
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 07, 2014 at 03:11:28PM +0200, Otto Moerbeek wrote: On Tue, Oct 07, 2014 at 02:56:07PM +0200, Fritjof Bornebusch wrote: On Tue, Oct 07, 2014 at 09:34:33AM +0200, Otto Moerbeek wrote: On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote: Fritjof, have you let the gnu rcs project know about the segfault? Maybe see how they choose to fix things and then follow their lead? That will only slow things down. Do what -L -U does is better, imo. Otto, so you appreciate a diff more like this one? well, almost. I think it should be clear one flag and set one, not clear all and set one. Here is the new one. -Otto fritjof fritjof Index: rcsprog.c === RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v retrieving revision 1.152 diff -u -p -r1.152 rcsprog.c --- rcsprog.c 2 Oct 2014 06:23:15 - 1.152 +++ rcsprog.c 7 Oct 2014 15:08:39 - @@ -235,8 +235,10 @@ rcs_main(int argc, char **argv) lkmode = RCS_LOCK_STRICT; break; case 'l': - /* XXX - Check with -u flag. */ + if (rcsflags RCSPROG_UFLAG) + warnx(-u overridden by -l); lrev = rcs_optarg; + rcsflags = ~RCSPROG_UFLAG; rcsflags |= RCSPROG_LFLAG; break; case 'm': @@ -273,8 +275,10 @@ rcs_main(int argc, char **argv) lkmode = RCS_LOCK_LOOSE; break; case 'u': - /* XXX - Check with -l flag. */ + if (rcsflags RCSPROG_LFLAG) + warnx(-l overridden by -u); urev = rcs_optarg; + rcsflags = ~RCSPROG_LFLAG; rcsflags |= RCSPROG_UFLAG; break; case 'V':
Re: [patch]lock and unlock like GnuRCS
I think that GNU RCS segfaulting for -u -l is enough justification to do
what we like, so a message (and last flag wins) like -L/-U would be fine
with me.
But if we want to do what they probably meant to happen then better to
match -l -u like Fritjof's diff.
On Fri, Oct 03, 2014 at 12:55:35PM +0200, Otto Moerbeek wrote:
On Thu, Oct 02, 2014 at 12:56:10AM +0100, Nicholas Marriott wrote:
OTOH, check out what we do with rcs -L and -U...
I kinda like that, because it tells you exactly what it is doing.
-Otto
On Thu, Oct 02, 2014 at 12:54:13AM +0100, Nicholas Marriott wrote:
Matching GNU RCS seems preferable to me but I don't feel strongly about
it.
I wouldn't mention this in the man page, it hardly seems like behaviour
anyone should (or will need to) rely on.
On Wed, Oct 01, 2014 at 07:41:52PM -0400, Daniel Dickman wrote:
posix commands (like ls(1) for example) keep the last option when
mutually exclusive options are specified. does it make sense to keep
rcs consistent with that convention? also is a man page diff needed?
On Oct 1, 2014, at 7:17 PM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
The existing behaviour isn't wildly useful, makes sense to me, ok nicm
On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch wrote:
Hi tech,
the OpenRCS rcs command produces the following output if -l and -u
is
used in the same command:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
I've looked at GnuRCS and it has another way to handle these
parameters
(it seems the other BSDs use GnuRCS, too).
Debian 7.5:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
rcs: foo.txt,v: no lock set on revision 1.1
1.1 locked
$ rcs -u1.1 -l1.1 foo.txt
Segmentation fault
Well, I think the Segmentation fault isn't that important :), but
GnuRCS
does not lock and unlock a file by using the same command like
OpenRCS.
I think the different implementations of RCS should share the same
behaviour:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
done
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 unlocked
done
fritjof
Index: rcsprog.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
retrieving revision 1.151
diff -u -p -r1.151 rcsprog.c
--- rcsprog.c12 Jul 2011 21:00:32 -1.151
+++ rcsprog.c3 Aug 2014 15:42:34 -
@@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
-/* XXX - Check with -u flag. */
-lrev = rcs_optarg;
-rcsflags |= RCSPROG_LFLAG;
+if (!(rcsflags RCSPROG_UFLAG)) {
+lrev = rcs_optarg;
+rcsflags |= RCSPROG_LFLAG;
+}
break;
case 'm':
if (logstr != NULL)
@@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
-/* XXX - Check with -l flag. */
-urev = rcs_optarg;
-rcsflags |= RCSPROG_UFLAG;
+if (!(rcsflags RCSPROG_LFLAG)) {
+urev = rcs_optarg;
+rcsflags |= RCSPROG_UFLAG;
+}
break;
case 'V':
printf(%s\n, rcs_version);
[patch]lock and unlock like GnuRCS
Hi tech,
the OpenRCS rcs command produces the following output if -l and -u is
used in the same command:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
I've looked at GnuRCS and it has another way to handle these parameters
(it seems the other BSDs use GnuRCS, too).
Debian 7.5:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
rcs: foo.txt,v: no lock set on revision 1.1
1.1 locked
$ rcs -u1.1 -l1.1 foo.txt
Segmentation fault
Well, I think the Segmentation fault isn't that important :), but GnuRCS
does not lock and unlock a file by using the same command like OpenRCS.
I think the different implementations of RCS should share the same
behaviour:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
done
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 unlocked
done
fritjof
Index: rcsprog.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
retrieving revision 1.151
diff -u -p -r1.151 rcsprog.c
--- rcsprog.c 12 Jul 2011 21:00:32 - 1.151
+++ rcsprog.c 3 Aug 2014 15:42:34 -
@@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
- /* XXX - Check with -u flag. */
- lrev = rcs_optarg;
- rcsflags |= RCSPROG_LFLAG;
+ if (!(rcsflags RCSPROG_UFLAG)) {
+ lrev = rcs_optarg;
+ rcsflags |= RCSPROG_LFLAG;
+ }
break;
case 'm':
if (logstr != NULL)
@@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
- /* XXX - Check with -l flag. */
- urev = rcs_optarg;
- rcsflags |= RCSPROG_UFLAG;
+ if (!(rcsflags RCSPROG_LFLAG)) {
+ urev = rcs_optarg;
+ rcsflags |= RCSPROG_UFLAG;
+ }
break;
case 'V':
printf(%s\n, rcs_version);
Re: [patch]lock and unlock like GnuRCS
The existing behaviour isn't wildly useful, makes sense to me, ok nicm
On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch wrote:
Hi tech,
the OpenRCS rcs command produces the following output if -l and -u is
used in the same command:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
I've looked at GnuRCS and it has another way to handle these parameters
(it seems the other BSDs use GnuRCS, too).
Debian 7.5:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
rcs: foo.txt,v: no lock set on revision 1.1
1.1 locked
$ rcs -u1.1 -l1.1 foo.txt
Segmentation fault
Well, I think the Segmentation fault isn't that important :), but GnuRCS
does not lock and unlock a file by using the same command like OpenRCS.
I think the different implementations of RCS should share the same
behaviour:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
done
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 unlocked
done
fritjof
Index: rcsprog.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
retrieving revision 1.151
diff -u -p -r1.151 rcsprog.c
--- rcsprog.c 12 Jul 2011 21:00:32 - 1.151
+++ rcsprog.c 3 Aug 2014 15:42:34 -
@@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
- /* XXX - Check with -u flag. */
- lrev = rcs_optarg;
- rcsflags |= RCSPROG_LFLAG;
+ if (!(rcsflags RCSPROG_UFLAG)) {
+ lrev = rcs_optarg;
+ rcsflags |= RCSPROG_LFLAG;
+ }
break;
case 'm':
if (logstr != NULL)
@@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
- /* XXX - Check with -l flag. */
- urev = rcs_optarg;
- rcsflags |= RCSPROG_UFLAG;
+ if (!(rcsflags RCSPROG_LFLAG)) {
+ urev = rcs_optarg;
+ rcsflags |= RCSPROG_UFLAG;
+ }
break;
case 'V':
printf(%s\n, rcs_version);
Re: [patch]lock and unlock like GnuRCS
posix commands (like ls(1) for example) keep the last option when mutually
exclusive options are specified. does it make sense to keep rcs consistent with
that convention? also is a man page diff needed?
On Oct 1, 2014, at 7:17 PM, Nicholas Marriott nicholas.marri...@gmail.com
wrote:
The existing behaviour isn't wildly useful, makes sense to me, ok nicm
On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch wrote:
Hi tech,
the OpenRCS rcs command produces the following output if -l and -u is
used in the same command:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
I've looked at GnuRCS and it has another way to handle these parameters
(it seems the other BSDs use GnuRCS, too).
Debian 7.5:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
rcs: foo.txt,v: no lock set on revision 1.1
1.1 locked
$ rcs -u1.1 -l1.1 foo.txt
Segmentation fault
Well, I think the Segmentation fault isn't that important :), but GnuRCS
does not lock and unlock a file by using the same command like OpenRCS.
I think the different implementations of RCS should share the same
behaviour:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
done
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 unlocked
done
fritjof
Index: rcsprog.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
retrieving revision 1.151
diff -u -p -r1.151 rcsprog.c
--- rcsprog.c12 Jul 2011 21:00:32 -1.151
+++ rcsprog.c3 Aug 2014 15:42:34 -
@@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
-/* XXX - Check with -u flag. */
-lrev = rcs_optarg;
-rcsflags |= RCSPROG_LFLAG;
+if (!(rcsflags RCSPROG_UFLAG)) {
+lrev = rcs_optarg;
+rcsflags |= RCSPROG_LFLAG;
+}
break;
case 'm':
if (logstr != NULL)
@@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
-/* XXX - Check with -l flag. */
-urev = rcs_optarg;
-rcsflags |= RCSPROG_UFLAG;
+if (!(rcsflags RCSPROG_LFLAG)) {
+urev = rcs_optarg;
+rcsflags |= RCSPROG_UFLAG;
+}
break;
case 'V':
printf(%s\n, rcs_version);
Re: [patch]lock and unlock like GnuRCS
Matching GNU RCS seems preferable to me but I don't feel strongly about
it.
I wouldn't mention this in the man page, it hardly seems like behaviour
anyone should (or will need to) rely on.
On Wed, Oct 01, 2014 at 07:41:52PM -0400, Daniel Dickman wrote:
posix commands (like ls(1) for example) keep the last option when mutually
exclusive options are specified. does it make sense to keep rcs consistent
with that convention? also is a man page diff needed?
On Oct 1, 2014, at 7:17 PM, Nicholas Marriott nicholas.marri...@gmail.com
wrote:
The existing behaviour isn't wildly useful, makes sense to me, ok nicm
On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch wrote:
Hi tech,
the OpenRCS rcs command produces the following output if -l and -u is
used in the same command:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
I've looked at GnuRCS and it has another way to handle these parameters
(it seems the other BSDs use GnuRCS, too).
Debian 7.5:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
rcs: foo.txt,v: no lock set on revision 1.1
1.1 locked
$ rcs -u1.1 -l1.1 foo.txt
Segmentation fault
Well, I think the Segmentation fault isn't that important :), but GnuRCS
does not lock and unlock a file by using the same command like OpenRCS.
I think the different implementations of RCS should share the same
behaviour:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
done
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 unlocked
done
fritjof
Index: rcsprog.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
retrieving revision 1.151
diff -u -p -r1.151 rcsprog.c
--- rcsprog.c12 Jul 2011 21:00:32 -1.151
+++ rcsprog.c3 Aug 2014 15:42:34 -
@@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
-/* XXX - Check with -u flag. */
-lrev = rcs_optarg;
-rcsflags |= RCSPROG_LFLAG;
+if (!(rcsflags RCSPROG_UFLAG)) {
+lrev = rcs_optarg;
+rcsflags |= RCSPROG_LFLAG;
+}
break;
case 'm':
if (logstr != NULL)
@@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
-/* XXX - Check with -l flag. */
-urev = rcs_optarg;
-rcsflags |= RCSPROG_UFLAG;
+if (!(rcsflags RCSPROG_LFLAG)) {
+urev = rcs_optarg;
+rcsflags |= RCSPROG_UFLAG;
+}
break;
case 'V':
printf(%s\n, rcs_version);
Re: [patch]lock and unlock like GnuRCS
OTOH, check out what we do with rcs -L and -U...
On Thu, Oct 02, 2014 at 12:54:13AM +0100, Nicholas Marriott wrote:
Matching GNU RCS seems preferable to me but I don't feel strongly about
it.
I wouldn't mention this in the man page, it hardly seems like behaviour
anyone should (or will need to) rely on.
On Wed, Oct 01, 2014 at 07:41:52PM -0400, Daniel Dickman wrote:
posix commands (like ls(1) for example) keep the last option when mutually
exclusive options are specified. does it make sense to keep rcs consistent
with that convention? also is a man page diff needed?
On Oct 1, 2014, at 7:17 PM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
The existing behaviour isn't wildly useful, makes sense to me, ok nicm
On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch wrote:
Hi tech,
the OpenRCS rcs command produces the following output if -l and -u is
used in the same command:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
I've looked at GnuRCS and it has another way to handle these parameters
(it seems the other BSDs use GnuRCS, too).
Debian 7.5:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
rcs: foo.txt,v: no lock set on revision 1.1
1.1 locked
$ rcs -u1.1 -l1.1 foo.txt
Segmentation fault
Well, I think the Segmentation fault isn't that important :), but
GnuRCS
does not lock and unlock a file by using the same command like OpenRCS.
I think the different implementations of RCS should share the same
behaviour:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
done
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 unlocked
done
fritjof
Index: rcsprog.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
retrieving revision 1.151
diff -u -p -r1.151 rcsprog.c
--- rcsprog.c12 Jul 2011 21:00:32 -1.151
+++ rcsprog.c3 Aug 2014 15:42:34 -
@@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
-/* XXX - Check with -u flag. */
-lrev = rcs_optarg;
-rcsflags |= RCSPROG_LFLAG;
+if (!(rcsflags RCSPROG_UFLAG)) {
+lrev = rcs_optarg;
+rcsflags |= RCSPROG_LFLAG;
+}
break;
case 'm':
if (logstr != NULL)
@@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
-/* XXX - Check with -l flag. */
-urev = rcs_optarg;
-rcsflags |= RCSPROG_UFLAG;
+if (!(rcsflags RCSPROG_LFLAG)) {
+urev = rcs_optarg;
+rcsflags |= RCSPROG_UFLAG;
+}
break;
case 'V':
printf(%s\n, rcs_version);
Re: [patch]lock and unlock like GnuRCS
On Wed, Oct 1, 2014 at 4:41 PM, Daniel Dickman didick...@gmail.com wrote: posix commands (like ls(1) for example) keep the last option when mutually exclusive options are specified. does it make sense to keep rcs consistent with that convention? also is a man page diff needed? RCS predates POSIX and does not follow the POSIX utility argument guidelines multiple ways. Changing OpenRCS to follow those guidelines would make it incompatible with GNU RCS and the the deployed base of scripts...and fingers... Philip Guenther
Re: [patch]lock and unlock like GnuRCS
On Wed, Oct 01, 2014 at 07:58:16PM -0700, Philip Guenther wrote: On Wed, Oct 1, 2014 at 4:41 PM, Daniel Dickman didick...@gmail.com wrote: posix commands (like ls(1) for example) keep the last option when mutually exclusive options are specified. does it make sense to keep rcs consistent with that convention? also is a man page diff needed? RCS predates POSIX and does not follow the POSIX utility argument guidelines multiple ways. Changing OpenRCS to follow those guidelines would make it incompatible with GNU RCS and the the deployed base of scripts...and fingers... Philip Guenther Agreed, -Otto
