tom@ssd.csd.harris.com (Tom Horsley) (08/21/90)
I have been playing with the recently posted RCS for DOS programs and they
seem to work pretty well (using the also recently posted GNU diff). I
suspect I am going to find them very useful. I did notice one pretty
minor glitch last night. I tried out the $Header$ feature, using it
to initialize a character string, and it generated a string containing
a file name that looked like:
C:\PROGS\TESTING\RCS\fred.c
needless to say, the back slash characters in the file name did not
make it through to the actual string generated in the compiled program...
It would also be nice to have the man page that describes RCS file format,
not just the section 1 man pages for the commands.
Thanks for posting RCS, I suspect I will find it one of the most useful
utilities that ever showed up in this group.
--
======================================================================
domain: tahorsley@csd.harris.com USMail: Tom Horsley
uucp: ...!uunet!hcx1!tahorsley 511 Kingbird Circle
Delray Beach, FL 33444
+==== Censorship is the only form of Obscenity ======================+
| (Wait, I forgot government tobacco subsidies...) |
+====================================================================+weisen@eniac.seas.upenn.edu (Neil Weisenfeld) (08/22/90)
In article <TOM.90Aug21073135@hcx2.ssd.csd.harris.com>, tom@ssd (Tom Horsley) writes: [stuff deleted] >minor glitch last night. I tried out the $Header$ feature, using it >to initialize a character string, and it generated a string containing >a file name that looked like: > > C:\PROGS\TESTING\RCS\fred.c > >needless to say, the back slash characters in the file name did not >make it through to the actual string generated in the compiled program... > I've been using the $Id$ function instead to help overcome that problem. It seems the same only without the leading components of the path name. Another problem that I've had is that 'ident' doesn't seem to find any i.d. strings in a binary file. I've used a hex editor to ensure that the data is there. Any ideas? Neil P.S. -- Great thanks to the poster.
lfk@athena.mit.edu (Lee F Kolakowski) (08/22/90)
There have been a number of comments about DOS RCS in this newsgroup and in my mailbox. Here are the responses. This may be a bit long so if you are not interested in RCS for DOS, press ``n'' now. First a few bug problems. BUG #1: On 21 Aug 90 11:31:35 GMT, tom@ssd.csd.harris.com (Tom Horsley) said: > I tried out the $Header$ feature, using it > to initialize a character string, and it generated a string containing > a file name that looked like: > C:\PROGS\TESTING\RCS\fred.c > needless to say, the back slash characters in the file name did not > make it through to the actual string generated in the compiled program... As I posted in an earlier cpib.d message. There were two sets of executables in the RCS posting. The first set was from the sources I got second hand from a fj.binaries group. These executables have been hacked so the the path separator is '\\'. As a result a small number of features break, most notable the one mentioned above. The second set of executables posted as MKSRCSe.zoo, have been reverse hacked so that the path sep is '/'. These do not require that the user own the MKS toolkit, or even use the MKS shell (except for the shell scripts and rcsmerge). BUG #2: On 20 Aug 90 16:21:00 -0700, jbthiel@cse.ogi.edu (John B. Thiel) said: > I much appreciated your recent post of the DOS version of RCS. In > beginning to use it I have uncovered the following potentially serious > bug: > > The handling of the DOS ctrl-Z file terminator character is inconsistent. > If ctrl-Z is the last character of the file, on a line by itself, > it is not included in the rcs-file, but it IS counted as a line > in the generation of edit scripts. > > The effect of this inconsistency is to produce an "EOF on edit" > error from "co" when attempting to retrieve revisions that are > not tip revisions. The problem manifests when the last delete > command in an edit script contains eg. dxxx nnn (counting the > original ctrl-Z line), but the current copy of the text within > the rcs-file has only nnn-1 lines remaining (since the ctrl-Z > line was not stored). > > The net result is that previous revisions CANNOT BE RETRIEVED! This is a result of broken tools, still putting ^Z at the end of files, and is also related to a small problem in moving around the actual RCS files. 1) RCS is for "text" files. 2) On Unix a file is a file. And "Text" files are no different as most of us know unix files have lines therminated by a single '\n'. MSDOS (enlightend as it may be) differntiates between text files and binary files. Text files get mucked with by stdio, and in text files ^Z still represents an absolute EOF. Quick && NOW fix: Use one on the many Unix<==>DOS file filters. It will fix the ^Z problem, and the '\r\n' vs '\n' problems. I like flip written by the previous cpib moderator (R. Dhesi). RCS/*,v files from a unix RCS, will be find on DOS once the ,v in the name is truncated. DOS RCS files must have their lines fixed and ,v appended. I use flip on a Unix box and the Unix version of mmv that was just posted to do this. Long Term FIX: recompile the tools to use binary file IO. and throw away '\r' and ^Z. This should be easy, but I dont have the time for about 1 month to do this. If some one needs this faster (John?), the sources should be in you news shortly. BUG #3: On 20 Aug 90 10:24:58 BST, I.Sparry@gdt.bath.ac.uk (Icarus Sparry) said: > I seem to have found a bug. > 1) Check in a file, say fred > 2) Enable stricy locking 'rcs -L fred' > 3) Checkout fred, without locking 'co fred' > 4) Checkout fred with lock. 'co -l fred' > The last fail, as it can't unlink the readonly copy. > The fix would be to chmod the file first, and then unlink, or else blame MS > for a faulty 'unlink' routine. I have not had a chance to investigate this. But I put it here FYI. BUG #4: I found a number of small problems with RCS merge operations. None of the diff3s I have support the required 5 args. There has been a discussion of this in gnu.utils.bugs. Is there a stable version of gnudiff3 for DOS to which we can make these patches? Also, on simtel and grape.ecs.clarkson.edu, maybe there should a GNU directory with sources and binaries for MS-DOS. I would do it, but I don't have nearly enough disk space for work. That is it on BUGS, Now on to Features: On 20 Aug 90 16:21:00 -0700, jbthiel@cse.ogi.edu (John B. Thiel) said: > A few unrelated notes on DosRCS: > 1. The USR environment variable is undocmented. (any others?) > > 2. Non-strict locking might be a more suitable default > (DOS is usually a single user platform) > > 3. A RCSFlags or RCSOptions environment variable would be useful > to specify things like strict/nonstrict locking, user name, etc. > ie. some of the constant options that can be given on the command > lines to the RCS commands. John must be using the DOSRCS versions of the programs. Those versions use USR as a username string. This is nonstandard. The MKS versions look for LOGNAME Under the MKS shell usernames are specified in the environment variable LOGNAME. So instead of a relatively useless username for everone like MS_USER, the routine checks LOGNAME. The locking issue.... I agree with John, but, we have 35 people working on 3 machines hooked up to a server, so locking makes sense, even though it does not really work that same as Unix. It sort of reminds you to be careful. If it bothers people, there are two possible solutions. 1) recompile the code, 2) some sort of environment variable. I vote for RCSLOCK={-U|-L}. I would tend not to muck with the username in the same mechanism. NOTE: Ian Stewartson's shell will work well with the MKS version of the tools, and uses LOGNAME. On 21 Aug 90 11:31:35 GMT, tom@ssd.csd.harris.com (Tom Horsley) said: > It would also be nice to have the man page that describes RCS file format, > not just the section 1 man pages for the commands. Bill and I (mostly *me*) had a number of problems is getting this stuff out. A munged src.zoo got to Bill, and he posted what manpages he could unpack. What is supposed to happen when he gets to it, is post all the sources, and docs, and manpages. In this set of stuff there is a rcsfiles.5l manpage. This is what you want. In the mean time, go to your nearest unix box, and type man -k rcs (or something like that on sysV). On 20 Aug 90 9:47:13 BST, D.R.Allum@gdt.bath.ac.uk (Dave Allum) said: > > I, and I am sure many others, would gratly appreciate PostScript versions > of the documentation. I will format all the docs and manpages, and put then somewhere for ftp. I am quite busy right now, so I may take 1-2 weeks. Lastly, there have been two makes mention, and one posted, the other in the queue. Dennis Vadura's Dmake supports RSC under MSDOS. This is the make I use. The is a version of GNU-Make which also supports RCS in the queue. These have very different flavors, they are both coverd by the GPL. Dmake is the actual starting point for MKS's make. -- Frank Kolakowski ====================================================================== |lfk@athena.mit.edu || Lee F. Kolakowski | |lfk@eastman2.mit.edu || M.I.T. | |kolakowski@wccf.mit.edu || Dept of Chemistry | |lfk@mbio.med.upenn.edu || Room 18-506 | |lfk@hx.lcs.mit.edu || 77 Massachusetts Ave.| |AT&T: 1-617-253-1866 || Cambridge, MA 02139 | |--------------------------------------------------------------------| | #include <woes.h> | | One-Liner Here! | ======================================================================
michael@wicat.UUCP (Mike Weeks) (08/23/90)
lfk@athena.mit.edu (Lee F Kolakowski) writes: >There have been a number of comments about DOS RCS in this newsgroup >and in my mailbox. Here are the responses. This may be a bit long >so if you are not interested in RCS for DOS, press ``n'' now. >BUG #3: >On 20 Aug 90 10:24:58 BST, >I.Sparry@gdt.bath.ac.uk (Icarus Sparry) said: >> I seem to have found a bug. >> 1) Check in a file, say fred >> 2) Enable stricy locking 'rcs -L fred' >> 3) Checkout fred, without locking 'co fred' >> 4) Checkout fred with lock. 'co -l fred' >> The last fail, as it can't unlink the readonly copy. >> The fix would be to chmod the file first, and then unlink, or else blame MS >> for a faulty 'unlink' routine. >I have not had a chance to investigate this. But I put it here FYI. I have found a similar problem on Novell Netware. With strict locking enable, if I co a file, it is created with read-only access and I cannot edit it unless I chmod it. The RCS/xxx file is also created with read-only access and I cannot do a co -l xxx because co is unable to write to the file. I am waiting for the sources so I can check this out but is anyone else using rcs with Netware successfully? I can do all the same functions on a local drive just fine but when I go to a networked disk, I'm out of it. Thanks, Mike Weeks Wicat Systems, Inc.
strobl@gmdzi.UUCP (Wolfgang Strobl) (08/23/90)
lfk@athena.mit.edu (Lee F Kolakowski) writes: >2) On Unix a file is a file. And "Text" files are no different > as most of us know unix files have lines therminated by a single > '\n'. MSDOS (enlightend as it may be) differntiates between > text files and binary files. ... This is a misleading description. MSDOS doesn't differentiate here between text and binary files, either. MSDOS inherited the standard conforming ASCII newline sequence Carriage Return / Line Feed from CP/M. Unix used the simpler, but nonstandard interpretation of Line Feed as a single character newline indicator. The MSDOS open call does not have a text/binary flag. This flag and the translation CR/LF <-> LF are a feature of the libraries which come with the current MSDOS C compilers and are there to make the C programmers interface to the file system Unix compatible. Of course, this is a minor point. But I am a bit tired to see features where Unix is actually compatible to most versions of itself ;-) presented as inherent Good Things, when they are in fact arbitrary implementation decisions. Wolfgang Strobl #include <std.disclaimer.hpp>
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (08/23/90)
In article <3235@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: |This is a misleading description. MSDOS doesn't differentiate here |between text and binary files, either. MSDOS inherited the standard |conforming ASCII newline sequence Carriage Return / Line Feed |from CP/M. Unix used the simpler, but nonstandard interpretation of |Line Feed as a single character newline indicator. | |The MSDOS open call does not have a text/binary flag. This flag |and the translation CR/LF <-> LF are a feature of the libraries |which come with the current MSDOS C compilers and are there to |make the C programmers interface to the file system Unix |compatible. Actually this is the way the C language is supposed to work, and has little to do with DOS. For text files whatever separates records shows up on input as a \n character. In binary mode the data read is what's in the file. Other operating systems like VMS or GCOS use other conventions, such as counts of characters in a record, or various characters separating lines. | |Of course, this is a minor point. But I am a bit tired to see |features where Unix is actually compatible to most versions |of itself ;-) presented as inherent Good Things, when they |are in fact arbitrary implementation decisions. | There is an ANSI standard X3J11 which defines this. Followup to comp.lang.c. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
lance@hermix.UUCP (Lance Ellinghouse) (03/05/91)
Can someone tell me where I can FTP the sources/binaries to RCS for DOS? the sources would be best as I have to add some custom things to it. Thanks, Lance ----------------------------- |Lance Ellinghouse | |Mark V Systems, Ltd. | |hermix!lance@anes.ucla.edu | -----------------------------