James Youngman <j...@gnu.org> wrote: > > http://sccs.sourceforge.net/man/sccs-admin.1.html > > Thanks. That explanation in that manual page is quite telegraphic, > leaving several things unstated, so I have some clarification
For the "s" flag, This is still the original man page text from Sun... > questions: > > 1. Does this apply equally to both "admin -i" and "get"? Including > the (implicit) "get" performed by "delta"? And prs :GB:? [I assume > yes in each case] Unless you refer to SCCS_V6, there is no implicit "get" in "admin" or "delta" and even with SCCS_V6, the implicit "get" only applies to the use case called "bulk" mode that is implemented with the new "-Nxxx" option. See page 4 ff. in http://sccs.sourceforge.net/man/sccs-get.1.html for a description of the -N bulk option. For SCCS_V6, the basic code from "get" has become a library part and this code follows the rules for the flags. Since "prs -d:GB: ..." calls "get -s -p ...", this applies to prs as well. > 2. If a keyword is known to exist outside this range (e.g. because we > had to read the whole body anyway and the tail contains a keyword) is > the warning (or, where appropriate, fatal error) issued anyway? [I > assume yes] I am not sure what you are asking here. If this is related to the historic SCCS message: "No id keywords (cm7)" and where newer SCCS versions (with "auto-help") print: No id keywords (cm7) cm7: "No id keywords" No SCCS identification keywords were substituted for. You may not have any keywords in the file, in which case you can ignore this warning. If this message came from delta then you just made a delta without any keywords. If this message came from get then the last time you made a delta you changed the lines on which they appeared. It's a little late to be telling you that you messed up the last time you made a delta, but this is the best we can do for now, and it's better than nothing. This isn't an error, only a warning. ----> If there was no actual expansion, there is is a warning, except when the history file is uuencoded. > 3. When the e flag is set (and where it is supported), SCCS (at least > the versions I have tested) scans the uuencoded version of the file > body (!) in order to decide whether to issue the "no id keywords" > warning. Is the line count specified by the s flag lines in the > uuencoded version of the body or the gotten version of the body? uuencoded content never causes a "No id keywords (cm7)" warning. > 4. How do other (i.e. non-Sun-originated) implementations of SCCS > handle this flag? Is it affected by the SCO OpenServer x flag? [I > assume no on the second question since Sun didn't implement that flag] Since "Caldera Linux" prevented the deal with SCO, I cannot tell how SCO SCCS works, but I see no relation to that SCO specific flag, since Sun SCCS since a long time just forwards the "x" permission from/to the history file. As mentioned before, real SCCS is agnostic to unknown flags and copies them literarily. You may check this by e.g. adding a "w" flag that is not known to any normal SCCS into a SCCS history file (using your favorite text editor) and then trying the usual "get", "delta", and "admin flag change" operations after running "admin -z". > 5. When running "admin -fsNNN -i" on a binary file without specifying > admin's -b flag, is the warning still issued? Does it depend on > whether or not the fact that the file is binary is detected within the > first NNN "lines"? As mentioned above, SCCS does not give any "No id keywords (cm7)" warning for uuencoded files and Sun SCCS automatically uuencodes binary files. BTW: "Sun SCCS" should rather be called SCCS_V5, since this is how it is called in the SVr4 source tree published by Sun in December 2006. SCCS_V4 introduced the current text based history format in February 1977 that is still used by SCCS_V5. With SCCS_V4/SCCS_V5, files are uuencoded in case that they have lines starting with ^A, a last line that does not end in a NEWLINE or lines that contain the NUL character. Note that with SCCS_V6, only files that contain NUL bytes are interpreted as "binary" and that the behavor (whether not to give "No id keywords (cm7)" warnings) is bound to whether the history file is uuencoded. Also note that future versions of SCCS will even allow to have NUL characters in "text" files when in SCCS_V6 mode. This already works but it has not yet been enabled. To allow this, SCCS no longer uses fgets() to read the history files (but rather getdelim()) and thus is able to deal with lines that contain NUL chars. Since the SCCS source tree comes with the enhanced Solaris diff(1) program and the enhanced Solaris bdiff(1) program, it is able to deal with files that contain NUL chars as I added support for that feature in 2016. See "man sccsfile": SCCS v6 Body escape extensions There are two additional types of text lines with a control character at the beginning that represent features intro- duced by SCCS v6. These features are not understood by SCCS implementations that support the SCCS v4 history file format only. ^A^A A line in the interleaved delta block that begins with two control characters represents a text line that begins at the second control character. ^AN A line in the interleaved delta block that begins with the ^AN sequence represents a text line that does not end with a newline character. A line in the form ^AN^Atext is extracted as ^Atext without a need to add another quote. Jörg -- EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
