debian/0000755000000000000000000000000012212712307007163 5ustar debian/control0000644000000000000000000000215712212435161010573 0ustar Source: cssc Section: vcs Priority: extra Maintainer: Yann Dirson Build-Depends: debhelper (>= 9), texinfo, dh-buildinfo, autotools-dev Standards-Version: 3.8.4 Homepage: http://www.gnu.org/software/cssc/ Package: cssc Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Suggests: groff Description: Clone of the Unix SCCS revision-control system SCCS is a per-file revision-control system. It is a de-facto standard on commercial Unices, being shipped with most of those. . GNU-based systems usually use RCS instead of SCCS - indeed it has been a choice to design RCS instead of implementing a free SCCS clone. RCS was designed to address some problems with SCCS (eg. extraction time grows linearly with the size of the history file), but it has anyway problems of its own (eg. extraction time of branches grows with trunk length). . Some project-wide revision-control systems, like Aegis, can make use of CSSC instead of RCS. . This package also provides a web frontend to navigate the history of files under SCCS control, with optional support for formatting of manpages using groff. debian/cssc.doc-base0000644000000000000000000000071012211466310011512 0ustar Document: cssc Title: cssc Manual Author: James Youngman Abstract: CSSC (short for Compatibly Stupid Source Control) is a clone of the traditional Un*x SCCS tool (short for Source Code Control System). It is not a complete implementation, but allows one to make sense out of an SCCS file on a GNU/Linux system. Section: Programming Format: HTML Index: /usr/share/doc/cssc/cssc.html/index.html Files: /usr/share/doc/cssc/cssc.html/*.html debian/docs0000644000000000000000000000017712211173047010044 0ustar README NEWS AUTHORS ChangeLog.1 docs/CREDITS docs/TODO docs/BUGS docs/mailing-list.txt docs/missing.txt sccs-cgi/sccs.cgi.text debian/watch0000644000000000000000000000007111344754772010233 0ustar version=2 http://ftp.gnu.org/gnu/cssc/CSSC-(.*)\.tar\.gz debian/install0000644000000000000000000000004312211451474010555 0ustar sccs-cgi/sccs.cgi /usr/lib/cgi-bin debian/copyright0000644000000000000000000000511311344777650011137 0ustar This package was debianized by Yann Dirson on Sat, 30 Sep 2000 It was downloaded from http://savannah.gnu.org/projects/cssc Upstream Authors: James Youngman and others Copyright: This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see . See the file /usr/share/common-licenses/GPL-3 for more information. ----- The "sccs" program and its accompanying documentation were written by Eric Allman, and are covered by a BSD licence: The contents of the "bsd" source directory is covered by this copyright license. If you are using a binary distribution of GNU CSSC, this refers to the executable "sccs", its manual page "sccs.1", the file "sccs.me", and no other part. All other parts of GNU CSSC are covered by the GNU general public license (see the file COPYING). Since I (James Youngman) have made a copyright assignment to the FSF for my past and future work on CSSC, all my modifiactions to this code are assigned to the FSF. However, the coyright license I've used is the original BSD license in acknowledgement of the fact that the majority of the value of this code is provided by the original BSD code; my modifications are needed to make it work with CSSC and to make it portable to various systems etc. While the FSF, being the copyright holders, can license my modifications as they choose, I'd prefer them to retain the BSD license for the contents of this directory. Please note that this copyright notice is not the same as the "original" BSD copyright notice. Specifically, the provision number 3 advertising condition has been removed. This change is described in the letter which is available on the BSD FTP site in the file `README.Impt.License.Change'. The provision which used to be numbered 4 has now been renumbered to 3. Copyright (C) 1998 Free Software Foundation, Inc. All rights reserved. Copyright (c) 1980, 1993 The Regents of the University of California. All rights reserved. See the file /usr/share/common-licenses/BSD for more information. debian/source/0000755000000000000000000000000012211471272010465 5ustar debian/source/format0000644000000000000000000000001411757011462011700 0ustar 3.0 (quilt) debian/source/lintian-overrides0000644000000000000000000000011312211471242014036 0ustar cssc source: license-problem-gfdl-invariants debian/patches/99-info-update debian/compat0000644000000000000000000000000211757011523010366 0ustar 9 debian/README.Debian0000644000000000000000000000057112211447666011243 0ustar Today, none of the (x)emacs packages in Debian know about the CSSC directory. Hopefully this will change. For now, to have (x)emacs' vc mode find the commands, you should add the /usr/lib/cssc directory into your vc-path variable. One easy way to do that is with: M-x customize-variable RET vc-path RET -- Yann Dirson , Tue, 3 Sep 2013 23:08:06 +0200 debian/changelog0000644000000000000000000001604512212711372011044 0ustar cssc (1.3.0-4) unstable; urgency=low * Condition death tests with GTEST_HAS_DEATH_TEST, which is not available for kfreebsd and hurd in the included version of gtest. -- Yann Dirson Sat, 07 Sep 2013 22:56:26 +0200 cssc (1.3.0-3) unstable; urgency=low * Add missing unistd.h inclusion breaking build on non-linux platforms in unit-tests/googletest/include/gtest/internal/gtest-port.h. -- Yann Dirson Fri, 06 Sep 2013 23:43:33 +0200 cssc (1.3.0-2) unstable; urgency=low * Use dh autotools_dev module to refresh config.*, adjust build-depends. -- Yann Dirson Fri, 06 Sep 2013 22:26:55 +0200 cssc (1.3.0-1) unstable; urgency=low * New upstream release. * No more docs/FIXED file to install. * Switched to source format "3.0 (quilt)". * Switched to debhelper 9 and dh. * Remove -D__USE_BSD flag, apparently not useful any more. * Fixed src/file.h not including sys/types.h before using gid_t. * Hacked gl/lib/stdio.h not to cause build failure on "gets" token. * Fixed typo "allows one to" in doc-base file (lintian). * Forced regeneration of shipped prebuilt info file. * Add lintian override for source, to avoid false GFDL error due to missing patch context. * Replaced use of texi2html with simple "make html". * Fixed cssc.texi for typo in @insertcopying usage, and missing references to "sccs admin" subtopics, which prevented curent makeinfo to work. * Fixed typo in README.Debian. -- Yann Dirson Wed, 04 Sep 2013 01:37:21 +0200 cssc (1.2.0-2) unstable; urgency=low * Force removal of info/dir in case gnu install-info is installed (and since there does not seem to be any standard for handling the problem) (Closes: #573684). * Switch from "dh_clean -k" to dh_prep. * Switch section from devel to vcs to match archive override. -- Yann Dirson Fri, 19 Mar 2010 22:20:55 +0100 cssc (1.2.0-1) unstable; urgency=low * New upstream release. * debian/watch, debian/copyright: for new upstream URLs. * debian/copyright: now covered by GPLv3. * Switch to debhelper compat v7. * Add Homepage field to debian/control. * Be sure not to ship info/dir file (lintian). * Capitalize doc-base section (lintian). * Replace unknown man code .om with .Nm (already used in similar places). * Bumped Standards-Version to 3.8.4, no change. -- Yann Dirson Sun, 07 Mar 2010 20:49:16 +0100 cssc (1.0.1-4) unstable; urgency=low * Adjusted extended description. * Install cssc.cgi in /usr/lib/cgi-bin, its doc in the usual place, add a note about it in extended description, and suggest groff. * Updated debian/watch. -- Yann Dirson Thu, 22 Dec 2005 00:12:57 +0100 cssc (1.0.1-3) unstable; urgency=low * Applied patch for g++-3.4 (Closes: #276131). * This uploads will allow rebuild with proper ABI on ia64 (Closes: #330639). * Updated FSF address in copyright file (lintian). * Nuked 3 empty lines from sccs.1 (lintian). * Switch to debhelper compat v4: * added ${misc:Depends} to control file. * Bumped Standards-Version to 3.6.2, no change. -- Yann Dirson Sat, 8 Oct 2005 14:29:32 +0200 cssc (1.0.1-2) unstable; urgency=low * Rebuilt with g++-4.0. -- Yann Dirson Tue, 5 Jul 2005 23:20:32 +0200 cssc (1.0.1-1) unstable; urgency=low * New upstream release. * Removed all those small patches to the code necessary for woody-era compilers. -- Yann Dirson Thu, 27 Jan 2005 21:12:30 +0100 cssc (1.00-1) unstable; urgency=low * New upstream release - supports the Solaris 8 'y' flag (Closes: #275000). * Added debian/watch file. * Removed the "in development" notice from extended description. -- Yann Dirson Sun, 10 Oct 2004 21:43:40 +0200 cssc (0.16alpha.pl0-1) unstable; urgency=low * New upstream release: * get-spec.txt not shipped any more. * Use dh-buildinfo. * Bumped Standards-Version to 3.6.1, no change. -- Yann Dirson Tue, 9 Dec 2003 16:04:28 +0100 cssc (0.15alpha.pl0-3) unstable; urgency=low * Rebuilt with g++-3.3. * Changed default build opts to current policy; honor noopt flag. * Bumped Standards-Version to 3.5.10. * Use debian/compat, adjusted debhelper builddep to 3.4.4 or greater. -- Yann Dirson Sun, 1 Jun 2003 16:27:59 +0200 cssc (0.15alpha.pl0-2) unstable; urgency=low * Rebuilt with g++-3.2. * Removed hacks required by bugs in older g++ versions. * Removed full stop in short desc (lintian). -- Yann Dirson Fri, 17 Jan 2003 10:38:32 +0100 cssc (0.15alpha.pl0-1) unstable; urgency=low * New upstream release. -- Yann Dirson Tue, 24 Dec 2002 00:35:26 +0100 cssc (0.14alpha.pl0-3) unstable; urgency=low * Completely revamped extended description (Closes: #142498). * Force use of g++-3.0 on ia64 to workaround a bug in 2.96, and add build-dep (Closes: #145859). -- Yann Dirson Fri, 24 May 2002 00:19:52 +0200 cssc (0.14alpha.pl0-2) unstable; urgency=low * Fixed a couple of missing includes, some of which cause failure under g++-3.0 (Closes: #142323), and addressed a handful of other warnings. * Use DESTDIR for install, not "prefix". * Force --enable-binary (previously activated by autodetection). -- Yann Dirson Fri, 12 Apr 2002 01:56:12 +0200 cssc (0.14alpha.pl0-1) unstable; urgency=low * New upstream release. -- Yann Dirson Mon, 8 Apr 2002 23:31:44 +0200 cssc (0.13alpha.pl1a-1) unstable; urgency=low * New upstream release (Closes: #120080). -- Yann Dirson Mon, 26 Nov 2001 22:47:08 +0100 cssc (0.13alpha.pl0-2) unstable; urgency=low * Added build-dep on texi2html (Closes: #114147). -- Yann Dirson Wed, 3 Oct 2001 19:58:44 +0200 cssc (0.13alpha.pl0-1) unstable; urgency=low * New upstream release, gcc3 fixes (Closes: #104799). * Minor debian/copyright cleanups (thanks lintian). * Build html version of texinfo manual, using texi2html. Registered in doc-base. * Put stamp files in debian/stampdir. * Mentionned in debian.copyright that the sccs frontend is covered by the BSD licence. * Set LC_ALL=C during build to workaround makeinfo i18n zealotry bug. -- Yann Dirson Sun, 30 Sep 2001 21:25:15 +0200 cssc (0.12alpha.pl0-1) unstable; urgency=low * New upstream release (Closes: #81607). * diff is essential, don't depend on it (lintian). -- Yann Dirson Sat, 28 Jul 2001 18:56:34 +0200 cssc (0.11alpha.pl4-2) unstable; urgency=low * Added note in README.Debian about how to setup emacs to use CSSC, as currently emacsen do not know about it. -- Yann Dirson Thu, 23 Nov 2000 01:33:14 +0100 cssc (0.11alpha.pl4-1) unstable; urgency=low * Initial Release. * Install binaries in /usr/lib/sccs/ instead of /usr/libexec/sccs/. -- Yann Dirson Sat, 30 Sep 2000 15:31:48 +0200 debian/rules0000755000000000000000000000112012212435143010235 0ustar #!/usr/bin/make -f # -*- makefile -*- export DH_VERBOSE=1 %: dh $@ --parallel --with autotools_dev override_dh_auto_configure: dh_auto_configure -- --enable-binary override_dh_auto_clean: test ! -r Makefile || $(MAKE) -j1 distclean override_dh_auto_build: dh_auto_build # force regeneration of prebuilt info file rm -f docs/*.info* $(MAKE) info html override_dh_auto_install: dh_auto_install mkdir -p debian/cssc/usr/share/doc/cssc cp -a docs/cssc.html debian/cssc/usr/share/doc/cssc/ dh_buildinfo override_dh_install: dh_install chmod +x debian/cssc/usr/lib/cgi-bin/*.cgi debian/patches/0000755000000000000000000000000012212711602010607 5ustar debian/patches/01-groff.diff0000644000000000000000000000176611757011422013002 0ustar --- cssc-1.2.0.orig/bsd/sccs.1 +++ cssc-1.2.0/bsd/sccs.1 @@ -147,7 +147,7 @@ of your current editing phase. The same flags will be passed to delta as described above, and all the flags listed for -.om get +.Nm get above except .Fl e and @@ -523,7 +523,6 @@ Copyright \(co 1983, 1990, 1993 .br The Regents of the University of California. All rights reserved. - .Pp Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions @@ -548,7 +547,6 @@ Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. - .El .Pp THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND @@ -562,7 +560,6 @@ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - .Sh HISTORY The .Nm sccs debian/patches/04-fix-texinfo0000644000000000000000000000132012211447276013223 0ustar Description: Fix texinfo documentation @insertcopying usage, and missing references to "sccs admin" subtopics, both prevented curent makeinfo to work. Author: Yann Dirson --- cssc-1.3.0.orig/docs/cssc.texi +++ cssc-1.3.0/docs/cssc.texi @@ -47,7 +47,7 @@ Free Documentation License''. @page @vskip 0pt plus 1filll -@insertcopying{} +@insertcopying @end titlepage @@ -307,6 +307,10 @@ BitKeeper files. Use this option with @ @c TODO: Write the test cases. @end table +@menu +* Flags:: Setting and clearing flags +* Modification Request Numbers:: Modification Request Numbers +@end menu @node Flags, Modification Request Numbers, ,admin @subsection Flags debian/patches/02-gl-lib-gets0000644000000000000000000000106012204500427013056 0ustar Description: Fix gl/lib/ build barfing on "gets" token Author: Yann Dirson --- cssc-1.3.0.orig/gl/lib/stdio.in.h +++ cssc-1.3.0/gl/lib/stdio.in.h @@ -139,7 +139,7 @@ _GL_WARN_ON_USE (fflush, "fflush is not so any use of gets warrants an unconditional warning. Assume it is always declared, since it is required by C89. */ #undef gets -_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead"); +/* _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead"); */ #if @GNULIB_FOPEN@ # if @REPLACE_FOPEN@ debian/patches/06-gtest-death-tests0000644000000000000000000000403112212711552014330 0ustar Description: Disable death tests Condition death tests with GTEST_HAS_DEATH_TEST, which is not available for kfreebsd and hurd in the included version of gtest. Author: Yann Dirson --- cssc-1.3.0.orig/unit-tests/test_mylist.cc +++ cssc-1.3.0/unit-tests/test_mylist.cc @@ -154,6 +154,8 @@ TEST(MylistTest, Different) EXPECT_FALSE(a == b); } +#if GTEST_HAS_DEATH_TEST + TEST(MylistDeathTest, InvalidPointerAssignment) { mylist a; @@ -201,3 +203,5 @@ TEST(MylistDeathTest, SelectOnEmpty) mylist a; EXPECT_EXIT(a.select(0), ::testing::KilledBySignal(SIGABRT), "index"); } + +#endif --- cssc-1.3.0.orig/unit-tests/test_sccsdate.cc +++ cssc-1.3.0/unit-tests/test_sccsdate.cc @@ -58,6 +58,7 @@ TEST(SccsdateTest, FourDigitYear) EXPECT_EQ("99/05/19 01:42:08", d14.as_string()); } +#if GTEST_HAS_DEATH_TEST TEST(SccsdateDeathTest, BuckRogers) { // As a sanity check we verify that the year is within the window @@ -69,6 +70,7 @@ TEST(SccsdateDeathTest, BuckRogers) ::testing::KilledBySignal(SIGABRT), "year < 2069"); } +#endif TEST(SccsdateTest, ColonYear) { --- cssc-1.3.0.orig/unit-tests/test_delta-table.cc +++ cssc-1.3.0/unit-tests/test_delta-table.cc @@ -72,6 +72,7 @@ TEST(DeltaTable, SelectConst) EXPECT_EQ(3, tc.select(0).seq()); } +#if GTEST_HAS_DEATH_TEST TEST(DeltaTableDeathTest, SeqNoRangeChecks) { cssc_delta_table t; @@ -85,7 +86,7 @@ TEST(DeltaTableDeathTest, SeqNoRangeChec EXPECT_EXIT(t.delta_at_seq_exists(seq_no(2)), ::testing::KilledBySignal(SIGABRT), "seq"); } - +#endif // delta_at_seq_exists TEST(DeltaTable, DeltaAtSeqExists) --- cssc-1.3.0.orig/unit-tests/test_delta.cc +++ cssc-1.3.0/unit-tests/test_delta.cc @@ -123,6 +123,7 @@ TEST(DeltaTest, Removed) EXPECT_TRUE(e.removed()); } +#if GTEST_HAS_DEATH_TEST TEST(DeltaDeathTest, InvalidType) { const mylist mrlist; @@ -132,6 +133,7 @@ TEST(DeltaDeathTest, InvalidType) ::testing::KilledBySignal(SIGABRT), "valid"); } +#endif TEST(DeltaTest, Mutators) { debian/patches/05-unistd0000644000000000000000000000066612212446112012273 0ustar Description: Missing unistd.h inclusion Breaks build on kfreebsd and hurd. Author: Yann Dirson --- cssc-1.3.0.orig/unit-tests/googletest/include/gtest/internal/gtest-port.h +++ cssc-1.3.0/unit-tests/googletest/include/gtest/internal/gtest-port.h @@ -173,6 +173,7 @@ #include #include #include +#include #ifndef _WIN32_WCE #include #endif // !_WIN32_WCE debian/patches/99-info-update0000644000000000000000000103635412211457111013221 0ustar Description: Update of generated info file --- cssc-1.3.0.orig/docs/cssc.info +++ cssc-1.3.0/docs/cssc.info @@ -1,17 +1,9 @@ -This is /home/james/source/GNU/CSSC/git/cssc/docs/cssc.info, produced -by makeinfo version 4.13 from -/home/james/source/GNU/CSSC/git/cssc/docs/cssc.texi. +This is cssc.info, produced by makeinfo version 5.1 from cssc.texi. -INFO-DIR-SECTION Miscellaneous -START-INFO-DIR-ENTRY -* cssc: (cssc). The GNU work-alike replacement for SCCS. -END-INFO-DIR-ENTRY +This file documents the GNU 'cssc' package for working with SCCS files. - This file documents the GNU `cssc' package for working with SCCS -files. - - Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, -2003, 2004, 2005, 2007, 2008 Free Software Foundation, Inc. + Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, +2007, 2008 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or @@ -19,15 +11,18 @@ any later version published by the Free Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". +INFO-DIR-SECTION Miscellaneous +START-INFO-DIR-ENTRY +* cssc: (cssc). The GNU work-alike replacement for SCCS. +END-INFO-DIR-ENTRY  File: cssc.info, Node: Top, Next: Overview, Up: (dir) - This file documents the GNU `cssc' package for working with SCCS -files. +This file documents the GNU 'cssc' package for working with SCCS files. - Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, -2003, 2004, 2005, 2007, 2008 Free Software Foundation, Inc. + Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, +2007, 2008 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or @@ -36,8 +31,8 @@ Invariant Sections, no Front-Cover Texts copy of the license is included in the section entitled "GNU Free Documentation License". - This file documents the GNU `CSSC' package, which is a work-alike -for the traditional Unix SCCS suite. + This file documents the GNU 'CSSC' package, which is a work-alike for +the traditional Unix SCCS suite. This is edition 1.10, for CSSC Version 1.3.0. @@ -54,7 +49,7 @@ for the traditional Unix SCCS suite. * Year 2000 Issues:: Status of CSSC with regard to the Millennium. * Testing:: How to run the test suite and write new cases. * Problems:: Reporting bugs. -* Copying:: How you can copy and share `CSSC'. +* Copying:: How you can copy and share 'CSSC'. * GNU Free Documentation License:: Copying and sharing this manual. * BSD Code:: Parts of the code are from BSD. * Glossary:: Definition of some terms relating to CSSC. @@ -72,8 +67,8 @@ traditional Unix SCCS suite. While it is strongly suggested that new projects not use this package, sometimes existing projects require the use of SCCS files. While conversion to other formats is possible, this is also sometimes -impractical. See the documentation for CVS and RCS. *Note What is -CVS?: (cvs)What is CVS?. See also the manual pages for RCS. +impractical. See the documentation for CVS and RCS. *Note What is CVS?: +(cvs)What is CVS?. See also the manual pages for RCS. GNU CSSC is published under the GNU General Public License, which is designed to protect your rights, as the user of this program. You have @@ -85,8 +80,8 @@ the license. *Note GNU General Public L which was written by Ross Ridge. The enhancement work was done by James Youngman. - The `sccs' program itself and its accompanying documentation -`sccs.me' and `sccs.1' were written by Eric Allman, and are covered by + The 'sccs' program itself and its accompanying documentation +'sccs.me' and 'sccs.1' were written by Eric Allman, and are covered by the BSD license (*note BSD Code::).  @@ -95,11 +90,11 @@ File: cssc.info, Node: Interface, Next 2 How to use the suite ********************** -By far the easiest way to use CSSC (or indeed SCCS) is to use VC-mode -in GNU Emacs. *Note Version Systems: (emacs)Version Systems. +By far the easiest way to use CSSC (or indeed SCCS) is to use VC-mode in +GNU Emacs. *Note Version Systems: (emacs)Version Systems. - If you can't use VC-mode, the BSD command `sccs' is a good -interface to the SCCS suite (and hence CSSC). + If you can't use VC-mode, the BSD command 'sccs' is a good interface +to the SCCS suite (and hence CSSC). Other than that, you will need to use each of the programs in the suite individually. @@ -111,7 +106,7 @@ File: cssc.info, Node: Invoking CSSC Pr ************************ The menu items are arranged in approximate order of frequency of use, -except `admin', which is first because you have to use it to start with. +except 'admin', which is first because you have to use it to start with. * Menu: @@ -134,127 +129,132 @@ except `admin', which is first because y  File: cssc.info, Node: admin, Next: cdc, Up: Invoking CSSC Programs -3.1 `admin' +3.1 'admin' =========== -To create an SCCS archive of a source file `foo.c', do +To create an SCCS archive of a source file 'foo.c', do admin -ifoo.c s.foo.c - This creates the archive file `s.foo.c' and initialises it with the -current contents of your source file, `foo.c'. If you use Emacs as -your editor, you can just use `C-x v i' instead. - - Another frequently-used option is `-b', which indicates that the -file is to be treated as a binary file rather than as text. You might -want to do this because the file actually contains binary data, or just + This creates the archive file 's.foo.c' and initialises it with the +current contents of your source file, 'foo.c'. If you use Emacs as your +editor, you can just use 'C-x v i' instead. + + Another frequently-used option is '-b', which indicates that the file +is to be treated as a binary file rather than as text. You might want +to do this because the file actually contains binary data, or just characters that have other meanings within an SCCS file, for example -`^A', the character whose code is 1. +'^A', the character whose code is 1. -`-aXXX' +'-aXXX' Add user or group XXX to the list of those authorised to check - revisions in (that is, use `get -e' and `delta'). Users must be + revisions in (that is, use 'get -e' and 'delta'). Users must be specified by name and groups by numeric ID. This feature is often used in conjunction with a setuid - installation of the `sccs' driver program (*note sccs::). This is + installation of the 'sccs' driver program (*note sccs::). This is not a good idea because the CSSC suite is not secure (*note Known Problems::). -`-b' +'-b' Ensure that the file is encoded as a binary file. This option only - works in conjunction with the `-n' or `-i' options. + works in conjunction with the '-n' or '-i' options. This option is not available if binary file support is turned off (*note Interoperability::) though this can be re-enabled if necessary with an environment variable (*note Environment Variables: Environment.). -`-dF' +'-dF' Delete flag F from the flags present in the file (*note Flags::). - When using `admin -dl' to unlock a release, you need to specify - which release should be unlocked. For example `admin -dla' - unlocks all releases, while `admin -dl2' unlocks only release 2. - This means that `admin -dl' will do nothing, since no release was + When using 'admin -dl' to unlock a release, you need to specify + which release should be unlocked. For example 'admin -dla' unlocks + all releases, while 'admin -dl2' unlocks only release 2. This + means that 'admin -dl' will do nothing, since no release was specified. If all releases are locked, attempting to unlock just one release will have no effect. -`-eXXX' - Erase the specified user or group from the list of those - authorised to check revisions in or out. - -`-fF[XXX]' - Add the flag F (with optional value XXX) to the file's flags - (*note Flags::). For example, `-fv/tmp/checkit' sets the - MR-validation flag to `/tmp/checkit'. +'-eXXX' + Erase the specified user or group from the list of those authorised + to check revisions in or out. + +'-fF[XXX]' + Add the flag F (with optional value XXX) to the file's flags (*note + Flags::). For example, '-fv/tmp/checkit' sets the MR-validation + flag to '/tmp/checkit'. -`-h' +'-h' Check the SCCS file. The exit value will be 0 if the file is valid, and not 0 otherwise. The checks made are the same as those - made for `val'. Some problems with the SCCS file may not be + made for 'val'. Some problems with the SCCS file may not be diagnosed. Warning messages may be emitted, indicating things that may or may - not be wrong (e.g. time apparently going backwards), but if no + not be wrong (e.g. time apparently going backwards), but if no actual errors are encountered, the exit value will still be zero. This option is silently incompatible with all the other options; - the specified SCCS files will not be modified by `admin' if the - `-h' flag is used. + the specified SCCS files will not be modified by 'admin' if the + '-h' flag is used. -`-iFOO' +'-iFOO' Initialise the SCCS file with the contents of the file FOO. If no - argument is given, read from standard input. This implies the - `-n' option. + argument is given, read from standard input. This implies the '-n' + option. -`-mMR-LIST' +'-mMR-LIST' When initialising a file, add the specified list of MR numbers (*note Modification Request Numbers::) to the delta commentary for the initial version. This list can be empty. The specified MRs are validated according to the setting of the V flag, which should be set (*note Flags::). If the V flag is set but has no value - (i.e. is set to the empty string), validation silently succeeds. - If the V flag is not set, the `-m' option causes `delta' to fail. + (i.e. is set to the empty string), validation silently succeeds. + If the V flag is not set, the '-m' option causes 'delta' to fail. -`-n' - Create a new SCCS file. Unless `-i' is also used, the new file +'-n' + Create a new SCCS file. Unless '-i' is also used, the new file will contain control information but the body will be initially - empty. Some versions of SCCS require the `-i' option to be - specified if `-n' is used. Therefore for greatest portability, - specify `-i/dev/null' if you want an empty initial body. *note + empty. Some versions of SCCS require the '-i' option to be + specified if '-n' is used. Therefore for greatest portability, + specify '-i/dev/null' if you want an empty initial body. *note Interoperability::. -`-rN' - Set the initial release number to N. The initial level within - that release is always 1. Some versions of SCCS allow you to - specify actual an actual SID here (for example `1.2' or - `1.8.2.1'). CSSC also allows this, but emits a warning. If you - use the `-r' option, you must also use the `-i' option (not just - the `-n' option). If the initial SID you specify is not on the - trunk, some tools will fail to work with the resulting file. See - also *Note SCCS Version Differences::. +'-rN' + Set the initial release number to N. The initial level within that + release is always 1. Some versions of SCCS allow you to specify + actual an actual SID here (for example '1.2' or '1.8.2.1'). CSSC + also allows this, but emits a warning. If you use the '-r' option, + you must also use the '-i' option (not just the '-n' option). If + the initial SID you specify is not on the trunk, some tools will + fail to work with the resulting file. See also *Note SCCS Version + Differences::. -`-tDESC' - Read in descriptive text for this file from `DESC'. This replaces +'-tDESC' + Read in descriptive text for this file from 'DESC'. This replaces any existing description. If no argument, remove any existing - description (this is illegal if `-i' or `-n' is used). + description (this is illegal if '-i' or '-n' is used). -`-V' +'-V' Display version information. -`-yADAYADA' +'-yADAYADA' When initialising a file, set the comment for that delta to - ADAYADA. If the option is given just as `-y', the comment is + ADAYADA. If the option is given just as '-y', the comment is recorded as empty. The following word in the argument list is not used as the comment. _Note that this behaviour is different to most Unix programs, but is the same as the behaviour of traditional SCCS_. -`-z' +'-z' Fix the checksum information. The SCCS file is still validated by CSSC; apart from possibly having an incorrect checksum, the s-file - must be valid. If you use this option on an SCCS file which - really is invalid, then the attempt may fail or _silently write - out a valid but incorrect file_. This option does not work on - BitKeeper files. Use this option with _extreme_ care. + must be valid. If you use this option on an SCCS file which really + is invalid, then the attempt may fail or _silently write out a + valid but incorrect file_. This option does not work on BitKeeper + files. Use this option with _extreme_ care. + +* Menu: + +* Flags:: Setting and clearing flags +* Modification Request Numbers:: Modification Request Numbers  File: cssc.info, Node: Flags, Next: Modification Request Numbers, Up: admin @@ -262,47 +262,40 @@ File: cssc.info, Node: Flags, Next: Mo 3.1.1 Flags ----------- -Flags are set and cleared with the `admin' program. *Note admin::. +Flags are set and cleared with the 'admin' program. *Note admin::. Boolean Flags ............. -`b' - Enable branch deltas: this enables the `-b' option of get (*note +'b' + Enable branch deltas: this enables the '-b' option of get (*note get::). - -`e' +'e' This flag indicates that the file controlled by this SCCS file is a binary file, and hence the body of the SCCS file is uuencoded. - This flag can only be set with the `-b' option of `admin' at the + This flag can only be set with the '-b' option of 'admin' at the time the file is created (or if admin takes it upon itself to set this flag automatically), and cannot be unset. The circumstances under which this can happen are discussed in *note Interoperability::. - -`f' +'f' This flag is specific to the _BitKeeper_ suite, and is only supported if CSSC has recognised the file as a BitKeeper file. CSSC does not understand the significance of this flag. - -`i' - Make `get' and `delta' exit unsuccessfully when the `Warning: No - id keywords' message is issued. - -`j' +'i' + Make 'get' and 'delta' exit unsuccessfully when the 'Warning: No id + keywords' message is issued. +'j' Enables concurrent updates: if you try to get a revision for editing, this normally fails if another user already has the file - locked. Setting the `j' flag overrides this. - -`n' - Create empty releases when the `-r' option to `get' is used to - skip releases. These empty releases can later serve as branch - points. - -`x' + locked. Setting the 'j' flag overrides this. +'n' + Create empty releases when the '-r' option to 'get' is used to skip + releases. These empty releases can later serve as branch points. +'x' Sets the executable bit on the g-file. This flag is a SCO OpenServer extension and is not supported by other versions of - SCCS. Setting this flag with `admin -fx' generates a warning to + SCCS. Setting this flag with 'admin -fx' generates a warning to this effect. If CSSC is simply processing a file which already has this flag set, no message will be generated. See *note Interoperability:: for more information on compatibility between @@ -311,56 +304,47 @@ Boolean Flags Other Flags ........... -`c' +'c' Set the release ceiling. Releases higher than the ceiling cannot be checked out. - -`f' +'f' Set the release floor. Releases lower then the release floor cannot be checked out. - -`d' - Set the default delta which is used when the `get' command is given - without the `-r' option. The default behaviour for `get' is +'d' + Set the default delta which is used when the 'get' command is given + without the '-r' option. The default behaviour for 'get' is defined in *note get::. - -`l' +'l' Set the locked release list. These releases cannot be checked out - with `get -e'. The special value `a' denotes all releases. - -`q' - Sets the value substituted for the `%Q%' keyword as described in + with 'get -e'. The special value 'a' denotes all releases. +'q' + Sets the value substituted for the '%Q%' keyword as described in *note Keyword Substitution::. This flag is referred to in the - output of SCCS as `csect name', and is variously referred to here + output of SCCS as 'csect name', and is variously referred to here as that, or the "user flag" or the "Q flag". - -`m' - Sets the overridden value for the `%M%' keyword as described in +'m' + Sets the overridden value for the '%M%' keyword as described in *note Keyword Substitution::. - -`t' - Sets the value for the `%Y%' keyword as described in *note Keyword +'t' + Sets the value for the '%Y%' keyword as described in *note Keyword Substitution::. - -`v' +'v' Sets the name of the program used to validate MR (modification request) numbers; MRs are described in *note Modification Request Numbers::. This flag can be set to the empty string, in which case MRs are allowed and the validation silently succeeds without any program being run. - -`y' +'y' By default, all keywords are expanded in the gotten file. See *note Keyword Substitution:: for a list of such keywords. This flag can be set to a list of letters separated by commas, in which case keyword expansion will be limited to the specified keywords. - For example, `admin -fyQ,M,Y' restricts keyword expansion so that - `%Q%', `%M%' and `%Y%' are expanded, while other keywords such as - `%Z%' are not. This flag is an extension introduced by Sun - Solaris 8. See *note Interoperability:: for a discussion of the + For example, 'admin -fyQ,M,Y' restricts keyword expansion so that + '%Q%', '%M%' and '%Y%' are expanded, while other keywords such as + '%Z%' are not. This flag is an extension introduced by Sun Solaris + 8. See *note Interoperability:: for a discussion of the interoperability of CSSC with other SCCS implementations. -  File: cssc.info, Node: Modification Request Numbers, Prev: Flags, Up: admin @@ -368,24 +352,23 @@ File: cssc.info, Node: Modification Req ---------------------------------- MRs are identifiers that can be specified when checking in a revision -using `delta' (or even using `admin', when creating a file). +using 'delta' (or even using 'admin', when creating a file). - If the `v' ("validate") flag is set, the user running `delta' is + If the 'v' ("validate") flag is set, the user running 'delta' is prompted for MR numbers as well as revision comments. If this flag is not set, no validation is performed and no MR numbers are prompted for. -If the `-m' option is given on the command line for `delta', the user -is not prompted. +If the '-m' option is given on the command line for 'delta', the user is +not prompted. MR numbers are not required by CSSC to be actual numbers; they may contain any non-whitespace printable characters; other implementations may not be so flexible. - MR numbers are frequently used to tie code revisions to other -things, for example engineering change management documents or -bug-tracking databases. If your change management systems are -computer-based, you can use the validation program to ensure that the -offered MR number is valid and that the calling user is allowed to -change the file. + MR numbers are frequently used to tie code revisions to other things, +for example engineering change management documents or bug-tracking +databases. If your change management systems are computer-based, you +can use the validation program to ensure that the offered MR number is +valid and that the calling user is allowed to change the file. The first argument passed to the validation program is the name of the g-file and the following arguments are the MR numbers offered. The @@ -393,66 +376,65 @@ validating program should return zero if acceptable. One might think that it would be useful to associate the MR number -with the action of checking out for a modification (`get -e'), but this +with the action of checking out for a modification ('get -e'), but this is not possible with SCCS. If you want to do that kind of thing, you must use a more advanced system, for example GNU CVS.  File: cssc.info, Node: cdc, Next: comb, Prev: admin, Up: Invoking CSSC Programs -3.2 `cdc' +3.2 'cdc' ========= -The `cdc' command allows you to add comments to the commentary for a +The 'cdc' command allows you to add comments to the commentary for a particular delta in an SCCS file. Any delta in the file (other than -ones removed with `rmdel') can be modified. +ones removed with 'rmdel') can be modified. If a comment is not specified on the command line, comments are accepted via standard input. - If the special argument name `-' is being used, this means that a + If the special argument name '-' is being used, this means that a list of files to operate on is being read from standard input, and -therefore the `-y' option is mandatory in this case. +therefore the '-y' option is mandatory in this case. The new comments are prepended to the existing comment for that -delta, followed by a line of the form `*** CHANGED *** yy/mm/dd hh:mm:ss -who'. This is followed by the original comment. Comments cannot be -removed using `cdc', but they can be added. +delta, followed by a line of the form '*** CHANGED *** yy/mm/dd hh:mm:ss +who'. This is followed by the original comment. Comments cannot be +removed using 'cdc', but they can be added. Only three options are supported:- -`-mMR-LIST' - The specified (space-separated) list of MRs is added to the - MR-list for the relevant delta. If more than one MR number is to - be added, the whole option should be quoted, to protect the spaces. - If an MR is prefixed with an exclamation mark (`!'), then the - indicated delta is removed from the existing list of MRs for the - delta. The file comment is modified to indicate what MRs have been - removed. If an MR to be removed is in fact not present in any - case, this is silently ignored. and the comment is not updated for - that MR. If you do not also want to add to the comment for the - delta, specify an empty comment option (that, is, a bare `-y'). +'-mMR-LIST' + The specified (space-separated) list of MRs is added to the MR-list + for the relevant delta. If more than one MR number is to be added, + the whole option should be quoted, to protect the spaces. If an MR + is prefixed with an exclamation mark ('!'), then the indicated + delta is removed from the existing list of MRs for the delta. The + file comment is modified to indicate what MRs have been removed. + If an MR to be removed is in fact not present in any case, this is + silently ignored. and the comment is not updated for that MR. If + you do not also want to add to the comment for the delta, specify + an empty comment option (that, is, a bare '-y'). -`-rSID' - This indicates which delta is to be changed. It must refer to an +'-rSID' + This indicates which delta is to be changed. It must refer to an existing delta in the file, which has not been removed with - `rmdel'. + 'rmdel'. -`-yCOMMENT' +'-yCOMMENT' This option introduces a comment to be added to the commentary for the specified SID. If more than one line is needed, it is a good idea to enclose the option in quotation marks to ensure that the - shell includes them in the argument passed to `cdc'. An empty `-y' + shell includes them in the argument passed to 'cdc'. An empty '-y' option can be used to indicate that the commentary for this delta - is not to be modified (this is only useful when the `-m' option is - used). If the `-y' option is not given, the user is prompted for + is not to be modified (this is only useful when the '-m' option is + used). If the '-y' option is not given, the user is prompted for comments. -  File: cssc.info, Node: comb, Next: delta, Prev: cdc, Up: Invoking CSSC Programs -3.3 `comb' +3.3 'comb' ========== This program is not yet implemented or documented in the manual, there @@ -462,83 +444,83 @@ will eventually be implemented.  File: cssc.info, Node: delta, Next: get, Prev: comb, Up: Invoking CSSC Programs -3.4 `delta' +3.4 'delta' =========== -The `delta' command is used to add a new revision to the ones already +The 'delta' command is used to add a new revision to the ones already stored in an SCCS file. Before being able to do this you need to run -`get -e' to check the file out for editing. +'get -e' to check the file out for editing. - A new revision is created by the `delta' program. These revisions -are each identified by a unique "SID". A SID looks like `1.2.3.4', -where the four numbers are the "release", "level", "branch" and -"sequence" numbers. + A new revision is created by the 'delta' program. These revisions +are each identified by a unique "SID". A SID looks like '1.2.3.4', where +the four numbers are the "release", "level", "branch" and "sequence" +numbers. New revisions on the main sequence (the "trunk") have no branch or -sequence numbers and so just have two number components (`1.2', for +sequence numbers and so just have two number components ('1.2', for example). - When a new version is checked in, `delta' usually prompts for + When a new version is checked in, 'delta' usually prompts for comments describing the changes just made. At this point you can enter any comments, separating lines with backslash-newline pairs. An unescaped newline terminates the comment, allowing operation to continue. - Sometimes, running `delta' results in the creation of a branch in -the SCCS file; this is controlled by the `get' command at the time the -file is checked out for editing (*note Making Branches: branches.). - - The `delta' program checks to see if you are authorised to check in -a delta to this file. The list of authorised users can be maintained -with the `admin' program (*note admin::). If the MR-validation flag -(*note Flags::) is set, you must also supply a valid MR-number in order -to be able to check in your change. + Sometimes, running 'delta' results in the creation of a branch in the +SCCS file; this is controlled by the 'get' command at the time the file +is checked out for editing (*note Making Branches: branches.). + + The 'delta' program checks to see if you are authorised to check in a +delta to this file. The list of authorised users can be maintained with +the 'admin' program (*note admin::). If the MR-validation flag (*note +Flags::) is set, you must also supply a valid MR-number in order to be +able to check in your change. * Menu: -* Basic Usage: delta usage. Frequently-used `delta' commands +* Basic Usage: delta usage. Frequently-used 'delta' commands * Options: delta options. Full list of options  File: cssc.info, Node: delta usage, Next: delta options, Up: delta -3.4.1 Basic usage for `delta' +3.4.1 Basic usage for 'delta' ----------------------------- -Although there are several valid command-line options for `delta', they +Although there are several valid command-line options for 'delta', they are not frequently used; the most common usage of delta is delta SCCS/s.umsp.c -and this command simply applies the changes to the file `umsp.c' to the -SCCS file which tracks it. Though it is possible to specify the -comment and MR-number for this change using command-line options, it's -more common to type them when prompted, unless `delta' is being driven -by another program; either way, it's unusual to specify options for -`delta' on the command line. +and this command simply applies the changes to the file 'umsp.c' to the +SCCS file which tracks it. Though it is possible to specify the comment +and MR-number for this change using command-line options, it's more +common to type them when prompted, unless 'delta' is being driven by +another program; either way, it's unusual to specify options for 'delta' +on the command line. Note that the filename you specify on the command line is that of the SCCS file, not the filename of the working file. The BSD wrapper program, sccs(1), will guess the correct filename for you, but this -doesn't happen unless you do actually invoke it (`sccs delta umsp.c' -for example). +doesn't happen unless you do actually invoke it ('sccs delta umsp.c' for +example).  File: cssc.info, Node: delta options, Prev: delta usage, Up: delta -3.4.2 Options for `delta' +3.4.2 Options for 'delta' ------------------------- -`-gSID-LIST' +'-gSID-LIST' The specified list of deltas are to be ignored when the version - being checked in is retrieved using `get'. The list is a list of + being checked in is retrieved using 'get'. The list is a list of SIDs separated by commas, or can contain ranges of SIDs (these are indicated by a dash). Untested. -`-mMR-LIST' +'-mMR-LIST' Specify the indicated list of MR numbers (separated by spaces) for this change (*note Modification Request Numbers::). If the V flag - (*note Flags::) is set, `delta' will prompt for MR numbers if none + (*note Flags::) is set, 'delta' will prompt for MR numbers if none are given on the command line. If the V flag has a non-empty value, as opposed to just being set, then the supplied list of MR numbers will be verified using that program. The requested delta @@ -547,58 +529,59 @@ File: cssc.info, Node: delta options, When the V flag is set, deltas _must_ be checked in using this flag. If you are using Emacs's vc-mode, you can do this by setting - the variable VC-CHECKIN-FLAGS to `"-m2677"' if the MR with which + the variable VC-CHECKIN-FLAGS to '"-m2677"' if the MR with which you are working is numbered 2677, for example. -`-n' +'-n' If this option is given, the edited file is not deleted once processing has succeeded. The edited file is referred to as the - "g-file", since it is the file which was previously "gotten" by - the `get' command. + "g-file", since it is the file which was previously "gotten" by the + 'get' command. -`-p' +'-p' Display the differences between the old and new versions of the - file during processing. The output of `diff' is echoed on the + file during processing. The output of 'diff' is echoed on the standard output. -`-r' - If several versions are checked out, the `-r' command-line option +'-r' + If several versions are checked out, the '-r' command-line option is used to specify which checked-out version this change is in - reference to. When `get' is used to check out a version for + reference to. When 'get' is used to check out a version for editing, it announces two SIDs:- 3.1 new delta 3.2 402 lines + One identifies the version forming the basis of the change, and the other specifies the SID that the new version will be assigned once it is checked in again. Either of these two SIDs (in this case, - 3.1 or 3.2) can be used for the `-r' option of `delta'. + 3.1 or 3.2) can be used for the '-r' option of 'delta'. -`-s' +'-s' Suppress warning or confirmation messages. Error messages go to standard error. This option is not covered in the test suite. -`-y' +'-y' Specify a comment for the revision log. This option is usually - quoted to protect the spaces contained in it. An empty comment - can be specified by just using a naked `-y'. If this option is - not given on the command line, `delta' will prompt the user for a + quoted to protect the spaces contained in it. An empty comment can + be specified by just using a naked '-y'. If this option is not + given on the command line, 'delta' will prompt the user for a comment.  File: cssc.info, Node: get, Next: help, Prev: delta, Up: Invoking CSSC Programs -3.5 `get' +3.5 'get' ========= -The `get' command is to retrieve previous revisions from an SCCS file. -With the `-e' option, it also locks the gotten revision so that a -modified version can be checked in later using `delta'. +The 'get' command is to retrieve previous revisions from an SCCS file. +With the '-e' option, it also locks the gotten revision so that a +modified version can be checked in later using 'delta'. * Menu: -* Basic Usage: get usage. Frequently-used `get' commands +* Basic Usage: get usage. Frequently-used 'get' commands * Options: get options. Full list of options. * Branches: branches. How branches are made. * Keywords: Keyword Substitution. Keyword Substitution @@ -607,153 +590,151 @@ modified version can be checked in later  File: cssc.info, Node: get usage, Next: get options, Up: get -3.5.1 Basic Usage for `get' +3.5.1 Basic Usage for 'get' --------------------------- - There are very few common basic usage patterns for `get'. Below, - `s.foo.c' denotes the name of any existing SCCS file. + There are very few common basic usage patterns for 'get'. Below, + 's.foo.c' denotes the name of any existing SCCS file. -`get s.foo.c' - Get a copy of the most recent trunk revision of `s.foo.c' into the - file `foo.c'. - -`get -Gbar s.foo.c' - Get a version from `s.foo.c', into `bar' rather than the default - `foo.c'. The file produced by `get' is often referred to as the +'get s.foo.c' + Get a copy of the most recent trunk revision of 's.foo.c' into the + file 'foo.c'. + +'get -Gbar s.foo.c' + Get a version from 's.foo.c', into 'bar' rather than the default + 'foo.c'. The file produced by 'get' is often referred to as the "g-file". -`get -r1.3 s.foo.c' - Get revision 1.3 from `s.foo.c' into `foo.c'. The `-G' option can +'get -r1.3 s.foo.c' + Get revision 1.3 from 's.foo.c' into 'foo.c'. The '-G' option can be used to set the name of the gotten file. -`get -p s.foo.c' +'get -p s.foo.c' Get the most recent trunk revision, and print it on standard - output. The `-r' option could also be used to specify some other + output. The '-r' option could also be used to specify some other revision. - Unless you specify the `-k' or `-e' option, the retrieved file will + Unless you specify the '-k' or '-e' option, the retrieved file will be created read-only.  File: cssc.info, Node: get options, Next: branches, Prev: get usage, Up: get -3.5.2 Options for `get' +3.5.2 Options for 'get' ----------------------- Full description of options - -`-aN' +'-aN' Retrieve the version corresponding to the delta sequence number N. Mainly for use by other programs in the suite. -`-b' +'-b' Create a new branch when the resulting file is checked back in. - Used with the `-e' option. If the `-e' option is not given, or if - the `b' (branch) flag is not set in the SCCS file, this option has + Used with the '-e' option. If the '-e' option is not given, or if + the 'b' (branch) flag is not set in the SCCS file, this option has no effect; a branch is not made. If the version to be checked out for editing has a successor, a branch is created whether or not the - `-b' flag is present (*note branches: branches.). + '-b' flag is present (*note branches: branches.). -`-cwhen' +'-cwhen' Get the version that was current at the time specified by when. The format of the argument is [cc]yy[mm[dd[hh[mm[ss]]]]]. Any fields omitted (except "cc") assume their maximum possible values - so that if you specify `-c92', you get the latest version which - was available in the year 1992. It is possible to give four - digits for the year as a CSSC-specific extension, but only if none - of the other fields are omitted. If only two digits are used and - the resulting value is less than 69, the year is assumed to be in - the twenty-first century (*note prs options:: and *note Year 2000 + so that if you specify '-c92', you get the latest version which was + available in the year 1992. It is possible to give four digits for + the year as a CSSC-specific extension, but only if none of the + other fields are omitted. If only two digits are used and the + resulting value is less than 69, the year is assumed to be in the + twenty-first century (*note prs options:: and *note Year 2000 Issues::). -`-D' +'-D' Turns on debugging output, indicating what is going on as the SCCS - file is read. This option may go away or have its behaviour - change in the near future. + file is read. This option may go away or have its behaviour change + in the near future. -`-e' +'-e' Indicates that the retrieved version is for editing. When checked back in the resulting file will have a new revision number. The retrieved file is writable, and keyword substitution does not take - place. A "p-file" is created; this file contains information - about what versions of the s-file are being edited, and by whom. - Unless the `j' flag is set (*note Flags::), `get -e' will fail if - someone else already has the file locked. If the list of - authorised users in the SCCS file is not empty, you must be in - that list in order to use this option. + place. A "p-file" is created; this file contains information about + what versions of the s-file are being edited, and by whom. Unless + the 'j' flag is set (*note Flags::), 'get -e' will fail if someone + else already has the file locked. If the list of authorised users + in the SCCS file is not empty, you must be in that list in order to + use this option. -`-g' +'-g' Do a dry-run, showing what version would be retrieved, but don't actually get the file. This is sometimes done by scripts, just to test the exit status. -`-GFOO' - Name the gotten file `FOO', instead of the default name. +'-GFOO' + Name the gotten file 'FOO', instead of the default name. -`-iLIST' - Include the deltas for the listed SIDs. See also `-x'. +'-iLIST' + Include the deltas for the listed SIDs. See also '-x'. -`-k' +'-k' Avoid doing keyword substitution (*note Keyword Substitution::). - This is assumed when `-e' is specified. The gotten file is + This is assumed when '-e' is specified. The gotten file is writable. -`-l' +'-l' Generates a delta summary file in the current working directory. - The name of the file is `l.foo' where `foo' is the name that would + The name of the file is 'l.foo' where 'foo' is the name that would normally be used for the gotten file. The name of the delta - summary file is not affected by the `-G' option. The delta - summary file is similar in content to the output of `prt', though - it contains less information. - -`-lp' - This is obsolete; use `-L' instead. - -`-L' - Generate a delta summary as for the `-l' option, but print it on - stdout instead of creating a file. If `-L' and `-p' are both + summary file is not affected by the '-G' option. The delta summary + file is similar in content to the output of 'prt', though it + contains less information. + +'-lp' + This is obsolete; use '-L' instead. + +'-L' + Generate a delta summary as for the '-l' option, but print it on + stdout instead of creating a file. If '-L' and '-p' are both specified, the delta summary is printed first. -`-m' +'-m' Prepend to each line of the result the SID corresponding to the - `delta' which introduced this line to the file. + 'delta' which introduced this line to the file. -`-n' +'-n' Precede each line of output with the module name, before any SID - added with the `-m' option. + added with the '-m' option. -`-p' +'-p' Write the result to the standard output, rather than to a file. -`-rX' +'-rX' Retrieve version X, rather than the default. -`-s' +'-s' Run silently. -`-t' +'-t' Get the "top" delta for the indicated release. The default - behaviour of `get' is to get the highest revision on the trunk. - The `-t' option only modifies this behaviour in the situation - where the topmost trunk revision is a branch point. In this case, - the `-t' option causes the topmost revision on this branch to be - retrieved. In other words, the `-t' option removes the - restriction that the retrieved version should be on the trunk. - This option is used by `comb' (*note comb::) and by the driver - program `sccs' from BSD (*note sccs::). + behaviour of 'get' is to get the highest revision on the trunk. + The '-t' option only modifies this behaviour in the situation where + the topmost trunk revision is a branch point. In this case, the + '-t' option causes the topmost revision on this branch to be + retrieved. In other words, the '-t' option removes the restriction + that the retrieved version should be on the trunk. This option is + used by 'comb' (*note comb::) and by the driver program 'sccs' from + BSD (*note sccs::). -`-V' +'-V' Show version information. -`-wXXX' +'-wXXX' When performing keyword substitution (*note Keyword - Substitution::), use XXX rather than `%Z%%M% %I%' as the + Substitution::), use XXX rather than '%Z%%M% %I%' as the substitution value for %W%. -`-xLIST' - Exclude the indicated deltas from the result. Deltas are - indicated by specifying the SID at which they arrived in the file. - +'-xLIST' + Exclude the indicated deltas from the result. Deltas are indicated + by specifying the SID at which they arrived in the file.  File: cssc.info, Node: branches, Next: Keyword Substitution, Prev: get options, Up: get @@ -762,12 +743,12 @@ File: cssc.info, Node: branches, Next: --------------------- Normally, editing revision 1.1 of a file produces revision 1.2. Editing -that produces revision 1.3, and so on. Sometimes, however, we need to +that produces revision 1.3, and so on. Sometimes, however, we need to make a change to an earlier version which has already been superseded. This might happen, for example, when a bug has been reported in a released version of a file; a rapid bug-fix is required, but you're in -the middle of working towards a new release. A viable strategy is to +the middle of working towards a new release. A viable strategy is to make a branch at the previously-released version, modify that to fix the bug (and release this bug-fix). Meanwhile, development can be continued along the "main trunk", and the same bug-fix can be incorporated in @@ -777,9 +758,9 @@ this, ready for the next release later o what the SID of the new version will be. For normal progress along the trunk, the "level number" is incremented. This is the second numeric element of the SID. In general, a SID is composed of four numbers -`R.L.B.S', where "R" stands for "Release", "L" stands for "Level", "B" +'R.L.B.S', where "R" stands for "Release", "L" stands for "Level", "B" stands for "Branch", and "S" stands for "Sequence number" (not the same -as the sequence numbers produced in the output of `prt'). +as the sequence numbers produced in the output of 'prt'). Trunk revisions have only two components; you can think of the branch and sequence numbers as being zero. Non-trunk revisions have four @@ -790,13 +771,13 @@ to one. Hence the first branch from ver 1.1.1.1, and if a branch is made from that, its SID will be 1.1.2.1. Branches are made from any given version when that version already -has a successor. For example, a `get -e' on version 1.1 will result in -a branch (1.1.1.1) if version 1.2 exists, and a `get -e' on version +has a successor. For example, a 'get -e' on version 1.1 will result in +a branch (1.1.1.1) if version 1.2 exists, and a 'get -e' on version 1.2.1.1 will result in a branch (1.2.2.1) if version 1.2.1.2 exists. If the "enable branches" flag is set, it is also possible to make branches for revisions that do not have successors. This is done with -the `-b' flag of `get'. +the '-b' flag of 'get'.  File: cssc.info, Node: Keyword Substitution, Next: Included Excluded and Ignored deltas, Prev: branches, Up: get @@ -804,88 +785,70 @@ File: cssc.info, Node: Keyword Substitu 3.5.4 Keyword Substitution -------------------------- -Keyword substitution is performed unless the `-k' option or the `-e' -option is given to `get'. +Keyword substitution is performed unless the '-k' option or the '-e' +option is given to 'get'. *note what:: contains a keyword substitution example. - The keywords are all of the form `%x%' where x stands for an + The keywords are all of the form '%x%' where x stands for an upper-case letter, one of: A - Expands to the same as `%Z% %Y% %M% %I% %Z%'. - + Expands to the same as '%Z% %Y% %M% %I% %Z%'. B The branch number of the gotten version - C Current line in the output file - D The date at the time the file was gotten, in the form yy/mm/dd. The year is always represented as two digits but this is not ambiguous since the two-digit year is no later than 2068 (*note Year 2000 Issues::). - E The date that the newest delta in the gotten file was applied, yy/mm/dd. The year is always represented as two digits but this is - not ambiguous since the two-digit year is no later than 2068 - (*note Year 2000 Issues::). - + not ambiguous since the two-digit year is no later than 2068 (*note + Year 2000 Issues::). F - Name of the SCCS file, for example `s.foo.c'. - + Name of the SCCS file, for example 's.foo.c'. G As for %E%, but in the US format mm/dd/yy. - H As for %D%, but in the US format mm/dd/yy. - I Expands to the same as %R%.%L%.%B%.%S%, that is, the SID of the retrieved version. - L The level number of the retrieved version. - M - Module name: the value of the `m' (module) flag, or the base name - of the SCCS file with the `s.' removed if the module flag is unset. - + Module name: the value of the 'm' (module) flag, or the base name + of the SCCS file with the 's.' removed if the module flag is unset. P Full name of the SCCS file. - Q - Value of the `q' flag. The `q' flag has no other purpose, and can - be set with `admin -fqfoo'. *Note Flags::. - + Value of the 'q' flag. The 'q' flag has no other purpose, and can + be set with 'admin -fqfoo'. *Note Flags::. R Release number of the retrieved version. - S Sequence number of the retrieved version. - T Current time (hh:mm:ss) when the file was retrieved, see %D% and %H%. - W - Expands to %Z% %M% %I% or the argument for the `-w' flag, if + Expands to %Z% %M% %I% or the argument for the '-w' flag, if given. - Y - Value of the `t' (module type) flag. - + Value of the 't' (module type) flag. Z - The literal string `@(#)'. *Note what::. + The literal string '@(#)'. *Note what::. Some of the keywords listed above have expansions that are described -in terms of the contents of other keywords. This expansion is -performed as if the `y' flag in the SCCS file is not set. For example, -`admin -fyA' will cause the `%I%' keyword not to be expanded, but the -`%A%' keyword is still fully expanded, even though it is defined in -terms of `%I%'. +in terms of the contents of other keywords. This expansion is performed +as if the 'y' flag in the SCCS file is not set. For example, 'admin +-fyA' will cause the '%I%' keyword not to be expanded, but the '%A%' +keyword is still fully expanded, even though it is defined in terms of +'%I%'.  File: cssc.info, Node: Included Excluded and Ignored deltas, Prev: Keyword Substitution, Up: get @@ -895,8 +858,8 @@ File: cssc.info, Node: Included Exclude This section describes how included, excluded and ignored deltas are handled by CSSC. Little documentation is available on how SCCS handles -this, and so while this section describes how CSSC works, it may in -fact not be an accurate description of how CSSC _should_ work. +this, and so while this section describes how CSSC works, it may in fact +not be an accurate description of how CSSC _should_ work. If you spot a defect in this section (or of course any other section) of the CSSC manual, please report this as a bug (*note Reporting Bugs: @@ -908,25 +871,25 @@ Problems.). The usual case is where none of the deltas in the SCCS file has any included, excluded or ignored deltas. All the lines in the body of the SCCS file are there because they were first inserted by a particular -delta. All of these lines are copied through to the gotten file, -unless they are deleted by a later delta. For example if an SCCS file -contains deltas 1.1 and 1.2, then all the lines from delta 1.2 will be -included, and all the lines from delta 1.1 which are not deteled in -version 1.2 are also included. +delta. All of these lines are copied through to the gotten file, unless +they are deleted by a later delta. For example if an SCCS file contains +deltas 1.1 and 1.2, then all the lines from delta 1.2 will be included, +and all the lines from delta 1.1 which are not deteled in version 1.2 +are also included. 3.6.2 Included Deltas --------------------- Normally the contents of the gotten delta is included in the output, -along with all the non-deleted lines of its ancestors. However, a -delta can also specify that some other delta should be included. This -really only makes a difference when there is a branch in the file. +along with all the non-deleted lines of its ancestors. However, a delta +can also specify that some other delta should be included. This really +only makes a difference when there is a branch in the file. For example, if delta 1.5 includes 1.3.1.5, then the gotten file will include the contents of versions 1.1 through to 1.5, plus the contents -of the 1.3.1 branch up to and including 1.3.1.5. Lines which were -(say) added in 1.2 but delted in 1.3.1.1 will not appear in the output, -since we have included a delta that deletes them. +of the 1.3.1 branch up to and including 1.3.1.5. Lines which were (say) +added in 1.2 but delted in 1.3.1.1 will not appear in the output, since +we have included a delta that deletes them. 3.6.3 Excluded Deltas --------------------- @@ -952,141 +915,140 @@ appear in the gotten file.  File: cssc.info, Node: help, Next: prs, Prev: get, Up: Invoking CSSC Programs -3.7 `help' +3.7 'help' ========== This module is not implemented, and it probably will never be, because it exists to translate the sometimes obscure error messages produced by (genuine) SCCS. These messages come with identifying codes (like -"(ge4)"); one might type `help ge4' to translate an obscure message -into a more readable message detailing what has gone wrong. The -problem with this approach is that it results in a program called -`help' on the user's path. When a naive user types `help' they are -probably not looking for an explanation of an obscure message from -SCCS. In fact, `help' is in any case a shell builtin for GNU Bash. -Explanations of any obscure or unusual error messages belong in this -manual, and so no `sccs-help' program is provided or planned. +"(ge4)"); one might type 'help ge4' to translate an obscure message into +a more readable message detailing what has gone wrong. The problem with +this approach is that it results in a program called 'help' on the +user's path. When a naive user types 'help' they are probably not +looking for an explanation of an obscure message from SCCS. In fact, +'help' is in any case a shell builtin for GNU Bash. Explanations of any +obscure or unusual error messages belong in this manual, and so no +'sccs-help' program is provided or planned.  File: cssc.info, Node: prs, Next: prt, Prev: help, Up: Invoking CSSC Programs -3.8 `prs' +3.8 'prs' ========= -The `prs' command (mnemonic: "print revision summary") prints +The 'prs' command (mnemonic: "print revision summary") prints information about an SCCS file in a user-defined format. There are options for selecting which deltas are reported on; selection is possible by check-in time or by SID. The format of the output can also be specified on the command line. All parts of an SCCS file can be -dumped with `prs'. Those parts which appear once per delta can be +dumped with 'prs'. Those parts which appear once per delta can be uniquely identified by SID or by time. - Typical uses for `prs' are + Typical uses for 'prs' are * Producing an audit trail of who changed what, and why, for example for a software release report, or for ISO 9000 documentation. * Discovering how a particular piece of code became broken, and - deducing which change broke it. The `get -m' command is also - useful for this, see *note Options for `get': get options. + deducing which change broke it. The 'get -m' command is also + useful for this, see *note Options for 'get': get options. * Listing all changes made on Friday afternoons, as a preparation for extra checking. * Menu: -* Basic Usage: prs usage. Frequently-used `prs' commands +* Basic Usage: prs usage. Frequently-used 'prs' commands * Options: prs options. Full list of options * Keywords: Data Keywords. Data Keyword Substitution  File: cssc.info, Node: prs usage, Next: prs options, Up: prs -3.8.1 Basic Usage for `prs' +3.8.1 Basic Usage for 'prs' --------------------------- Here are some examples of the use of prs, with explanations of what they do. -`prs s.myfile.c' - Show information about all the versions of `myfile.c'. +'prs s.myfile.c' + Show information about all the versions of 'myfile.c'. -`prs SCCS' - Show information about all the SCCS files in the directory `SCCS'. +'prs SCCS' + Show information about all the SCCS files in the directory 'SCCS'. -`prs -e -d:P: s.main.c | sort -u' +'prs -e -d:P: s.main.c | sort -u' Show which users have made changes to main.c. -`prs -l -c`date +%y%m%d --date "last week"` SCCS' - Examine all the SCCS files in the directory `SCCS'. Show any deltas - that have been created since last week. +'prs -l -c`date +%y%m%d --date "last week"` SCCS' + Examine all the SCCS files in the directory 'SCCS'. Show any + deltas that have been created since last week.  File: cssc.info, Node: prs options, Next: Data Keywords, Prev: prs usage, Up: prs -3.8.2 Options for `prs' +3.8.2 Options for 'prs' ----------------------- -`-a' +'-a' Include even removed deltas in the output. Removed deltas have a type "R", as output by the :DT: keyword. -`-c[CC]YYMMDDHHMMSS' +'-c[CC]YYMMDDHHMMSS' Specifies the time of the "cutoff". When this option is given, the - delta selected by `prs' is the last one checked in before the + delta selected by 'prs' is the last one checked in before the cutoff. As usual, any fields left unspecified in the cutoff are given the maximum legal value (for example, the seconds field defaults to 59). The fields can be separated by any non-numeric - character, for example `-c97/11/02-11:25:42'. + character, for example '-c97/11/02-11:25:42'. As an extension specific to CSSC, if the argument contains more than twelve (12) digits, and the first four characters are all digits, it is assumed that a four-digit year form has been used. - This means that you can say `-c1997/11/02-11:25:42' to mean the + This means that you can say '-c1997/11/02-11:25:42' to mean the same as the above. In line with the X/Open CAE Specification, Commands and Utilities (version 2, September 1994, pages 588 and 361), if the century - field is _not_ given and the year is less than 69, it is assumed - to be a year in the twenty-first century. The X/Open document - does not mandate a four-digit year specifier, but it would not - make sense to apply this rule if a four-digit year is specified. - *Note Year 2000 Issues::. + field is _not_ given and the year is less than 69, it is assumed to + be a year in the twenty-first century. The X/Open document does + not mandate a four-digit year specifier, but it would not make + sense to apply this rule if a four-digit year is specified. *Note + Year 2000 Issues::. - This behaviour is usually not the one required, and hence the `-e' - or `-l' options are specified too. + This behaviour is usually not the one required, and hence the '-e' + or '-l' options are specified too. -`-dFORMAT' +'-dFORMAT' This specifies the data format for the output. Because the default output format is sensible, this is typically used either in a shell script which will process the output further, or by a human to - retrieve information which is not shown by default. See *note - Data Keywords:: for the various keywords that can be used. Any + retrieve information which is not shown by default. See *note Data + Keywords:: for the various keywords that can be used. Any characters in the data format which are not part of a keyword are output as well. - If one specifies the `-d' option, `prs' by default only gives + If one specifies the '-d' option, 'prs' by default only gives information about the latest delta. To restore the default - behavior of showing all the deltas, use the `-e' option as well. + behavior of showing all the deltas, use the '-e' option as well. -`-e' - Makes the `-c' option select deltas created at or earlier than the - specified time. Makes the `-r' option select deltas before and +'-e' + Makes the '-c' option select deltas created at or earlier than the + specified time. Makes the '-r' option select deltas before and including the one specified by the indicated SID. -`-l' - As the `-e' option, but select only later deltas rather than +'-l' + As the '-e' option, but select only later deltas rather than earlier ones. -`-rSID' +'-rSID' Specifies the SID for which information is provided. If blank, the latest delta is selected. -  File: cssc.info, Node: Data Keywords, Prev: prs options, Up: prs -3.8.3 Data Keywords for the `-d' option of `prs' +3.8.3 Data Keywords for the '-d' option of 'prs' ------------------------------------------------ 3.8.3.1 Global Keywords @@ -1095,74 +1057,74 @@ File: cssc.info, Node: Data Keywords, These keywords expand to the same thing, no matter which version is being examined. Many of these are SCCS file flags (*note Flags::). -`:BD:' +':BD:' Emits the body of the SCCS file, that is, the part containing all the delta information. Note that since this is dumped verbatim, it contains control characters. If you want a more readable format, - consider using the `-b' option of `prt' (*note prt options::). + consider using the '-b' option of 'prt' (*note prt options::). -`:BF:' - Indicates the setting (`yes' or `no') of the branch flag. +':BF:' + Indicates the setting ('yes' or 'no') of the branch flag. -`:CB:' +':CB:' Indicates the value of the release number ceiling flag. -`:Ds:' +':Ds:' The default SID to check out (See *note Flags:: and *note get::). -`:F:' +':F:' Name of the SCCS file. -`:FB:' +':FB:' Indicates the value of the release floor boundary flag. -`:FD:' +':FD:' File descriptive text (*note admin::). -`:FL:' +':FL:' List of SCCS file flags. -`:J:' - Value (`yes' or `no') of the joint-edit flag. +':J:' + Value ('yes' or 'no') of the joint-edit flag. -`:KF:' - Value (`yes' or `no') of the keyword-warning flag (*note admin::). +':KF:' + Value ('yes' or 'no') of the keyword-warning flag (*note admin::). -`:LK:' +':LK:' Value of the locked-releases flag. -`:M:' - The module name (the value of the `m' flag). +':M:' + The module name (the value of the 'm' flag). -`:MF:' - The value (`yes' or `no') of the MR validation flag (*note +':MF:' + The value ('yes' or 'no') of the MR validation flag (*note delta::). -`:MP:' +':MP:' The value of the MR validation program flag (*note delta::). This is usually the name of an executable file. -`:ND:' - The value of the null-delta (`n') flag (`yes' or `no'). +':ND:' + The value of the null-delta ('n') flag ('yes' or 'no'). -`:Q:' +':Q:' The value of the (user-defined) Q flag (arbitrary one-line text). -`:PN:' +':PN:' The full path name of the SCCS file. -`:UN:' +':UN:' List of users authorised to make deltas to this file (one per - line). This list can be modified with the use of the options `-a' - and `-e' of `admin'; if this list is empty, any user is allowed to - use `delta' on this file (subject to the usual file permissions + line). This list can be modified with the use of the options '-a' + and '-e' of 'admin'; if this list is empty, any user is allowed to + use 'delta' on this file (subject to the usual file permissions checks made by the operating system). However, in this case the - `UN' data keyword somewhat curiously expands to `none'. + 'UN' data keyword somewhat curiously expands to 'none'. -`:Y:' +':Y:' Value of the module-type flag. - The `:BD:', `:FD:', `:FL:' and `:UN:' keywords from this section may + The ':BD:', ':FD:', ':FL:' and ':UN:' keywords from this section may expand to strings containing newlines. 3.8.3.2 Version-specific Keywords @@ -1170,259 +1132,257 @@ expand to strings containing newlines. These keywords expand to data that is specific to a particular version. -`:A:' - Expands to `:Z::Y: :M: :I::Z:', useful for `what'. - -`:B:' +':A:' + Expands to ':Z::Y: :M: :I::Z:', useful for 'what'. +':B:' Branch number of SID -`:C:' +':C:' Comments for this delta. These may extend over several lines. -`:D:' +':D:' Date (yy/mm/dd) that this version was checked in. Expands to - `:Dy:/:Dm:/:Dd:'. The year is always represented as two digits but + ':Dy:/:Dm:/:Dd:'. The year is always represented as two digits but is not ambiguous since the two-digit year is no later than 2068 (*note Year 2000 Issues::). -`:Dd:' +':Dd:' Day-of-month on which the delta was checked in (two digits). -`:Dg:' +':Dg:' Sequence numbers of ignored deltas (separated by white space). -`:DI:' - Expands to `:Dn:/:Dx:/:Dg:' (sequence numbers +':DI:' + Expands to ':Dn:/:Dx:/:Dg:' (sequence numbers included/excluded/ignored). -`:DL:' - Expands to `:Li:/:Ld:/:Lu:' (lines inserted/deleted/unchanged). +':DL:' + Expands to ':Li:/:Ld:/:Lu:' (lines inserted/deleted/unchanged). -`:Dm:' +':Dm:' Month when this version as checked in (two digits). -`:Dn:' +':Dn:' Sequence numbers of included deltas (separated by white space). -`:DP:' +':DP:' Sequence number of the delta that precedes this one. -`:DS:' +':DS:' Sequence number of this delta. -`:Dt:' - Expands to `:DT: :I: :D: :T: :P: :DS: :DP:'. +':Dt:' + Expands to ':DT: :I: :D: :T: :P: :DS: :DP:'. -`:DT:' - Delta type: `R' (removed) or `D' (normal). +':DT:' + Delta type: 'R' (removed) or 'D' (normal). -`:Dx:' +':Dx:' Sequence numbers of excluded deltas (separated by white space). -`:Dy:' +':Dy:' Year when this version was checked in. The year is always represented as two digits but is not ambiguous since the two-digit year is no later than 2068 (*note Year 2000 Issues::). -`:GB:' +':GB:' The body for this version, as distinct from the body of the SCCS - file itself, which is obtained with `:BD:'. Keyword expansion - will be performed in the same way as if `get' had been used. + file itself, which is obtained with ':BD:'. Keyword expansion will + be performed in the same way as if 'get' had been used. -`:I:' +':I:' The SID of this version. -`:L:' +':L:' The level component of the SID (that is, the second number). -`:Ld:' +':Ld:' Number of lines deleted in this version, with respect to its predecessor. -`:Li:' +':Li:' Number of lines inserted in this version, with respect to its predecessor. -`:Lu:' +':Lu:' Number of lines unchanged in this version, with respect to its predecessor. -`:MR:' +':MR:' The MR numbers specified when this delta was created. -`:P:' +':P:' Perpetrator: the login name of the user who created this delta. -`:R:' +':R:' The release number of the SID (the first number). -`:S:' +':S:' The sequence number of the SID. Don't confuse this with the delta sequence numbers (*note Delta Table::), which are internal - identifiers for deltas which are output by the keywords :DI:, - :Dn:, :Dx: and :Dg:. + identifiers for deltas which are output by the keywords :DI:, :Dn:, + :Dx: and :Dg:. -`:T:' - Time that this version was checked in (`:Th:::Tm:::Ts:'). +':T:' + Time that this version was checked in (':Th:::Tm:::Ts:'). -`:Th:' - Hours component of check-in time (`:T:'). +':Th:' + Hours component of check-in time (':T:'). -`:Tm:' - Minutes component of check-in time (`:T:'). +':Tm:' + Minutes component of check-in time (':T:'). -`:Ts:' - Seconds component of check-in time (`:T:'). +':Ts:' + Seconds component of check-in time (':T:'). -`:W:' - Shorthand for `:Z::M::I:', suitable for `what' (*note what::). +':W:' + Shorthand for ':Z::M::I:', suitable for 'what' (*note what::). -`:Z:' - Expands to `@(#)' (*note what::). +':Z:' + Expands to '@(#)' (*note what::). - The `:C:', `:GB:' and `:MR:' keywords from this section may expand -to strings containing newlines. + The ':C:', ':GB:' and ':MR:' keywords from this section may expand to +strings containing newlines.  File: cssc.info, Node: prt, Next: rmdel, Prev: prs, Up: Invoking CSSC Programs -3.9 `prt' +3.9 'prt' ========= -The `prt' command provides information about an SCCS file without +The 'prt' command provides information about an SCCS file without modifying it. There are many options, though the default behaviour is usually appropriate. It is possible to select what revisions to print information on, by SID or by date. - Some SCCS implementations lack the `prt' command, though none lack -the `prs' command (*note prs::) which is otherwise quite similar. + Some SCCS implementations lack the 'prt' command, though none lack +the 'prs' command (*note prs::) which is otherwise quite similar. * Menu: -* Basic usage: prt usage. Frequently-used `prt' commands +* Basic usage: prt usage. Frequently-used 'prt' commands * Options: prt options. Full list of options -* Output format: prt output. The format of `prt''s output +* Output format: prt output. The format of 'prt''s output  File: cssc.info, Node: prt usage, Next: prt options, Up: prt -3.9.1 Basic usage for `prt' +3.9.1 Basic usage for 'prt' --------------------------- -The output provided by `prt' when no options are given is sufficient +The output provided by 'prt' when no options are given is sufficient most of the time, and so it's common to use it without any options:- prt s.umsp.c -The default output contains slightly more information than the output -of `get -L'. If you require more detail, the `-e' ("everything") -option produces more detail:- +The default output contains slightly more information than the output of +'get -L'. If you require more detail, the '-e' ("everything") option +produces more detail:- prt -e s.umsp.c As usual, any argument that is the name of a directory causes all SCCS -files in that directory to be processed; the special argument `-' -indicates that a list of SCCS files are to be read from `prt''s -standard input. +files in that directory to be processed; the special argument '-' +indicates that a list of SCCS files are to be read from 'prt''s standard +input.  File: cssc.info, Node: prt options, Next: prt output, Prev: prt usage, Up: prt -3.9.2 Options for `prt' +3.9.2 Options for 'prt' ----------------------- -`-a' +'-a' "All deltas"; this means that the output will include "removed" - deltas. Removed deltas exist after `rmdel' has been used to remove + deltas. Removed deltas exist after 'rmdel' has been used to remove a delta. -`-b' +'-b' Print the body of the SCCS file. This is printed in a readable - format. The control character `^A' (Control-A, ASCII code 1) which + format. The control character '^A' (Control-A, ASCII code 1) which starts some lines of an SCCS file is printed as three asterisks, - `***'. Lines that do not start with the control character are + '***'. Lines that do not start with the control character are indented by one tab stop. For encoded (binary) files, the encoded form of the file data is printed (this is what actually appears in the SCCS file itself). If you want to extract the actual body of - the SCCS file, use the `:BD:' keyword of `prs' (*note Data + the SCCS file, use the ':BD:' keyword of 'prs' (*note Data Keywords::. -`-d' +'-d' Print information about the deltas in the file, as opposed to information about the SCCS file itself (for example the authorised users). This is the default behaviour. The default behaviour is - turned off by the `-b', `-f', `-t' and `-u' flags, but specifying - `-d' on the command line again will ensure that the delta + turned off by the '-b', '-f', '-t' and '-u' flags, but specifying + '-d' on the command line again will ensure that the delta information is printed. -`-e' - "Everything"; Means the same as `-i -u -f -t -d'. +'-e' + "Everything"; Means the same as '-i -u -f -t -d'. -`-c[CC]YYMMDDHHMMSS' +'-c[CC]YYMMDDHHMMSS' Specifies the time of the "cutoff". When this option is given, - `prt' stops printing delta information when it reaches a SID at + 'prt' stops printing delta information when it reaches a SID at least as old as the cutoff. As usual, any fields left unspecified in the cutoff are given the maximum legal value (for example, the seconds field defaults to 59). The fields can be separated by any - non-numeric character, for example `-c97/11/02-11:25:42'. + non-numeric character, for example '-c97/11/02-11:25:42'. As an extension specific to CSSC, if the argument contains more than twelve (12) digits, and the first four characters are all digits, it is assumed that a four-digit year form has been used. - This means that you can say `-c1997/11/02-11:25:42' to mean the + This means that you can say '-c1997/11/02-11:25:42' to mean the same as the above. In line with the X/Open CAE Specification, Commands and Utilities (version 2, September 1994, pages 588 and 361), if the century - field is _not_ given and the year is less than 69, it is assumed - to be a year in the twenty-first century. The X/Open document - does not mandate a four-digit year specifier, but it would not - make sense to apply this rule if a four-digit year is specified. - *Note Year 2000 Issues::. + field is _not_ given and the year is less than 69, it is assumed to + be a year in the twenty-first century. The X/Open document does + not mandate a four-digit year specifier, but it would not make + sense to apply this rule if a four-digit year is specified. *Note + Year 2000 Issues::. - The `-c' and `-r' options are mutually exclusive. + The '-c' and '-r' options are mutually exclusive. -`-f' +'-f' Print the flags of the SCCS file (*note Flags::). -`-i' +'-i' Print the serial numbers of included, excluded, and ignored deltas. -`-r[CC]YYMMDDHHMMSS' - Specifies a cutoff, as with the `-c' option, but with the opposite +'-r[CC]YYMMDDHHMMSS' + Specifies a cutoff, as with the '-c' option, but with the opposite sense; that is, nothing is printed for deltas that are more recent than the indicated time. - The `-c' and `-r' options are mutually exclusive. + The '-c' and '-r' options are mutually exclusive. -`-s' +'-s' Print only a summary line for each delta (that is, the MR list and comments and so on are omitted). -`-t' - Print the text description of the SCCS file, as set by `admin -t' +'-t' + Print the text description of the SCCS file, as set by 'admin -t' (*note admin::). -`-u' +'-u' Print the list of users and group IDs authorised to make deltas, one per line. -`-ySID' +'-ySID' Print only information for deltas as new as the specified SID. If the argument part is empty, that is, the option used is simply - `-y', the most recent delta is selected. The oder in which delta + '-y', the most recent delta is selected. The oder in which delta information is stored within the SCCS file is such that the SID selected by this option will be the last one printed. - If the `-y' option is used in conjunction with either the `-c' or + If the '-y' option is used in conjunction with either the '-c' or the -Y option, processing stops when either condition (date or SID match) is satisfied. -  File: cssc.info, Node: prt output, Prev: prt options, Up: prt -3.9.3 `prt' output format +3.9.3 'prt' output format ------------------------- The output format is fixed, though parts of the output can be omitted. @@ -1430,18 +1390,16 @@ The output format is fixed, though parts 1. The header * Newline - * SCCS file name, followed by a colon - * Two further newlines. - 2. Delta table information (for `-d', `-e', also the default, but - not if `-b', `-f', `-t', `-u' are specified). This section is - printed once for each selected delta. + 2. Delta table information (for '-d', '-e', also the default, but not + if '-b', '-f', '-t', '-u' are specified). This section is printed + once for each selected delta. This begins with a newline as a separator (except when a cutoff is - being used, in which case the SCCS file name is used, followed by - a colon and a TAB character). + being used, in which case the SCCS file name is used, followed by a + colon and a TAB character). * Delta type 'R' for removed deltas (*note rmdel::), and 'D' for ordinary @@ -1457,108 +1415,96 @@ The output format is fixed, though parts * Sequence number of the previous delta - * Line statistics `inserted/deleted/unchanged'. These + * Line statistics 'inserted/deleted/unchanged'. These statistics are capped at 99999, due to a limitation in the - file format. + file format. * Newline - 3. Delta detail information This section is printed once for each selected delta, unless the - `-s' option has been specified. + '-s' option has been specified. * Included deltas - * Excluded deltas - * Ignored deltas * MR numbers - * Delta comments - 4. Global information Once information has been printed for each of the selected deltas, - the global information is printed. This consists of + the global information is printed. This consists of * List of authorised users and group IDs (if the list is blank, - `everyone' is printed) - + 'everyone' is printed) * The SCCS file flags (*note Flags::) are printed. - - * The description of the SCCS file is printed (this is - the description set by the `-t' option of `admin'). - + * The description of the SCCS file is printed (this is the + description set by the '-t' option of 'admin'). * The body of the SCCS file is printed, in a readable format. - The control character `^A' that begins some lines is - printed as `*** ', and other lines are printed indented - by one tab stop. Other than that, the body is printed - as found in the SCCS file. This means that binary - files are left encoded. - - + The control character '^A' that begins some lines is printed + as '*** ', and other lines are printed indented by one tab + stop. Other than that, the body is printed as found in the + SCCS file. This means that binary files are left encoded.  File: cssc.info, Node: rmdel, Next: sact, Prev: prt, Up: Invoking CSSC Programs -3.10 `rmdel' +3.10 'rmdel' ============ -The `rmdel' ("Remove Delta") command allows the last version last +The 'rmdel' ("Remove Delta") command allows the last version last checked in to an SCCS file to be removed again. Typically, one does this after realizing that newly checked in version doesn't compile, or doesn't work, and the fix is simple. In the author's opinion, it's almost always better to be honest about mistakes, and just make a new delta for the fixed version. - The SID of a removed delta is soon re-used by `delta', usually for + The SID of a removed delta is soon re-used by 'delta', usually for the fixed version. - The `rmdel' command takes only one option, `-r', which specifies the + The 'rmdel' command takes only one option, '-r', which specifies the SID of the version to be removed. This option is mandatory. - The `rmdel' command will fail if you hadn't checked in that -revision, or if it is in use in some way. For example, `rmdel' fails -if the specified SID is not the latest revision on its branch, or if it -has been checked out for editing. + The 'rmdel' command will fail if you hadn't checked in that revision, +or if it is in use in some way. For example, 'rmdel' fails if the +specified SID is not the latest revision on its branch, or if it has +been checked out for editing. As usual, any number of SCCS files can be named on the command line. -The special argument `-' indicates that the list of files to be -operated on should be read from standard input. If an argument is a -directory, the RMDEL command is applied to all SCCS files in that -directory. +The special argument '-' indicates that the list of files to be operated +on should be read from standard input. If an argument is a directory, +the RMDEL command is applied to all SCCS files in that directory.  File: cssc.info, Node: sact, Next: sccs, Prev: rmdel, Up: Invoking CSSC Programs -3.11 `sact' +3.11 'sact' =========== -The `sact' ("Show Editing Activity") command provides a summary of -which files are currently checked out for editing. For each -checked-out file, a summary line is given. This line is of the form -`old-SID new-SID user date time'. +The 'sact' ("Show Editing Activity") command provides a summary of which +files are currently checked out for editing. For each checked-out file, +a summary line is given. This line is of the form 'old-SID new-SID user +date time'. -`old-SID' +'old-SID' Identifies the revision that was checked out for editing. -`new-SID' - This is the SID that will be allocated by `delta' when the working +'new-SID' + This is the SID that will be allocated by 'delta' when the working file is checked in again. -`user' +'user' The login name of the user who checked out the file. -`date time' +'date time' The date and time at which the checking-out was done. No output is produced for SCCS files that are not currently locked for editing. If a directory is specified on the command line, the whole directory is examined. Directory hierarchies are not descended beyond -this one level. If `-' is given as an argument, filenames are read -from standard input. +this one level. If '-' is given as an argument, filenames are read from +standard input. Note that times in SCCS files (and lock-files) are stored as local time, so if you are collaborating with developers in another time zone, @@ -1568,108 +1514,106 @@ editing.  File: cssc.info, Node: sccs, Next: sccsdiff, Prev: sact, Up: Invoking CSSC Programs -3.12 `sccs' +3.12 'sccs' =========== -The `sccs' utility is available with `CSSC'. The code has been adapted +The 'sccs' utility is available with 'CSSC'. The code has been adapted to support GNU Autoconf, but it should function in the same way. The -only difference between the operation of the original BSD `sccs' -program and that of the one provided by `CSSC' is that way that the -called programs are searched for. While the original program has the -paths hard-coded in as `/usr/sccs/*', the version accompanying `CSSC' -first searches for them on the PATH, and then falls back on -`/usr/sccs/*'. If the executable is running set-user-id, the `PATH' -environment variable is ignored. The `sccs' program itself should be -fairly secure, but the other programs in the suite are not. *Note -Known Problems::, for more information. - - The `sccs' program is documented in its online manual page, and also -in `An Introduction to the Source Code Control System' by Eric Allman, -a copy of which is included with this suite. +only difference between the operation of the original BSD 'sccs' program +and that of the one provided by 'CSSC' is that way that the called +programs are searched for. While the original program has the paths +hard-coded in as '/usr/sccs/*', the version accompanying 'CSSC' first +searches for them on the PATH, and then falls back on '/usr/sccs/*'. If +the executable is running set-user-id, the 'PATH' environment variable +is ignored. The 'sccs' program itself should be fairly secure, but the +other programs in the suite are not. *Note Known Problems::, for more +information. + + The 'sccs' program is documented in its online manual page, and also +in 'An Introduction to the Source Code Control System' by Eric Allman, a +copy of which is included with this suite. - Unlike all the other parts of the suite, the `sccs' program and its + Unlike all the other parts of the suite, the 'sccs' program and its accompanying documentation are covered by the BSD copyright license; see -*note BSD Code::, and the file `COPYING.bsd', for more information. +*note BSD Code::, and the file 'COPYING.bsd', for more information. - The original BSD version of the `sccs' program can easily be found -on BSD mirrors, for example `ftp://ftp.freebsd.org/'. + The original BSD version of the 'sccs' program can easily be found on +BSD mirrors, for example .  File: cssc.info, Node: sccsdiff, Next: unget, Prev: sccs, Up: Invoking CSSC Programs -3.13 `sccsdiff' +3.13 'sccsdiff' =============== -The `sccsdiff' command compares two revisions stored in an SCCS file, -using the system utility `diff'. Options can be passed on to `diff', +The 'sccsdiff' command compares two revisions stored in an SCCS file, +using the system utility 'diff'. Options can be passed on to 'diff', for example to set the output format. As with the other utilities in -the suite, `sccsdiff' will operate on a list of s-files, but unlike -most of the others, it will not process directories named on the -command line. +the suite, 'sccsdiff' will operate on a list of s-files, but unlike most +of the others, it will not process directories named on the command +line. If you wish to compare the working copy of a file with a version -stored in the s-file, you should use the command `sccs diffs' (*note +stored in the s-file, you should use the command 'sccs diffs' (*note sccs::). - The options for `sccsdiff' are described below. + The options for 'sccsdiff' are described below. -`--help' +'--help' This option is provided by CSSC but not by other SCCS implementations. It briefly describes the usage of the program. -`--version' - Indicates the version information for the `sccsdiff' program. +'--version' + Indicates the version information for the 'sccsdiff' program. -`-p' +'-p' The differences are piped through pr, rather than just being output directly. -`-rSID' - This option is used to select a revision from the s-file. It - must be specified exactly twice, in order to select a pair of - revisions to compare. - - All other options not appearing above are passed on to the `diff' -program. All the non-option arguments will be processed in turn as -SCCS files. +'-rSID' + This option is used to select a revision from the s-file. It must + be specified exactly twice, in order to select a pair of revisions + to compare. + + All other options not appearing above are passed on to the 'diff' +program. All the non-option arguments will be processed in turn as SCCS +files.  File: cssc.info, Node: unget, Next: val, Prev: sccsdiff, Up: Invoking CSSC Programs -3.14 `unget' +3.14 'unget' ============ -The `unget' command is used to reverse the effect of `get -e'. -Typically you might do this when you embark on an edit of a file, and -it all goes horribly wrong. Using `unget' allows you to revert to a +The 'unget' command is used to reverse the effect of 'get -e'. +Typically you might do this when you embark on an edit of a file, and it +all goes horribly wrong. Using 'unget' allows you to revert to a previously-known state. In fact, if you have exercised some care in -checking in new revisions, perhaps using a test suite, then `unget' can +checking in new revisions, perhaps using a test suite, then 'unget' can be used to return you to the last working version. -3.14.1 Options for `unget' +3.14.1 Options for 'unget' -------------------------- -`-n' +'-n' Do not delete the g-file which you were editing - -`-s' +'-s' Operate silently - -`-rSID' - When joint editing is enabled (*note Flags::), several versions - may be checked out for editing. If this is the case, SID must be - used to indicate which edit is to be aborted. +'-rSID' + When joint editing is enabled (*note Flags::), several versions may + be checked out for editing. If this is the case, SID must be used + to indicate which edit is to be aborted.  File: cssc.info, Node: val, Next: what, Prev: unget, Up: Invoking CSSC Programs -3.15 `val' +3.15 'val' ========== -The `val' command is used to validate a (possibly suspect) SCCS file. +The 'val' command is used to validate a (possibly suspect) SCCS file. If an SCCS command reports that the checksum of an SCCS file is incorrect, this may mean that the file has been corrupted. In this -case, `val' may help to confirm this (but *note Why val doesn't solve +case, 'val' may help to confirm this (but *note Why val doesn't solve the whole problem: Paranoia.). Example usages:- @@ -1689,29 +1633,29 @@ the whole problem: Paranoia.).  File: cssc.info, Node: Options for val, Next: Validation Warnings, Up: val -3.15.1 Options for `val' +3.15.1 Options for 'val' ------------------------ -`-mNAME' +'-mNAME' Assert that the module name flag of the SCCS file is set to NAME. The return value of VAL will be zero only if all the other checks succeed and the history file has its module name flag set to this value. *Note Flags::, for a description of the SCCS file flags. -`-s' +'-s' Silent operation; suppress any error or warning messages that would otherwise be emitted; the return value of the program will still indicate the existence and general nature of any problems. -`-V' +'-V' Display version information . This option does not exist in the traditional SCCS implementation. -`-rWANTED' +'-rWANTED' Validation will succeed if the SID WANTED is valid, unambiguous, and present in the history file. -`-yTYPE' +'-yTYPE' Assert that the module type flag of the SCCS file is set to TYPE. The return value of VAL will be zero only if all the other checks succeed and the history file has its module name flag set to this @@ -1724,7 +1668,7 @@ File: cssc.info, Node: Validation Warni -------------------------- Some possible problems with SCCS files are not definitively errors. In -these situations, `val' will emit a warning message but the validation +these situations, 'val' will emit a warning message but the validation will not fail (that is, if there are no other problems the return value will be zero). An explanation of the possible warnings appears below. @@ -1732,16 +1676,16 @@ WARNING: date for version 1.1 is later t This message indicates that a delta exists in the history file where the "parent" delta has a delta creation time which is later than the creation time of the "child" delta. This is a warning - only because the delta creation time is measured in local time, - and so if two developers with different time locale settings both - edit the file in a short period of time, this can happen. If all - the developers who create deltas in a history file use the same + only because the delta creation time is measured in local time, and + so if two developers with different time locale settings both edit + the file in a short period of time, this can happen. If all the + developers who create deltas in a history file use the same timezone settings, this should not happen. - Some versions of SCCS, but not CSSC exhibit a peculiar behaviour - in these circumstances, and do not include in the gotten file any + Some versions of SCCS, but not CSSC exhibit a peculiar behaviour in + these circumstances, and do not include in the gotten file any lines apparently inserted after the date of the delta which has - been selected. This applies to `get' but more importantly also + been selected. This applies to 'get' but more importantly also applies to the temporary file generated by DELTA which is compared with the working copy of tyhe file. Once this has happened there is no way to recover from this problem other than to hand-edit the @@ -1756,19 +1700,18 @@ Unknown special comment intro construction it doesn't recognise, this warning is issued. The 'y' flag specifies a keyword letter 'X' but %X% is not a recognised SCCS keyword - This message is displayed when the `y' flag of the SCCS file is - set to a value which includes a keyword letter which is not known. + This message is displayed when the 'y' flag of the SCCS file is set + to a value which includes a keyword letter which is not known. This is harmless unless you intended to set the flag to some other value. *note Flags::. -  File: cssc.info, Node: Return Value, Next: Paranoia, Prev: Validation Warnings, Up: val 3.15.3 Return Value ------------------- -The value returned by the `val' program depends on the outcome of the +The value returned by the 'val' program depends on the outcome of the validation as follows :- 0 @@ -1777,17 +1720,17 @@ validation as follows :- value; see *note Validation Warnings::, for more information. 1 - The `-m' option was used but the module name did not match. + The '-m' option was used but the module name did not match. 2 - The `-y' option was used but the module type did not match. + The '-y' option was used but the module type did not match. 4 - The `-r' option was used but the specified SID was ambiguous, or + The '-r' option was used but the specified SID was ambiguous, or not present in the history file. 8 - The `-r' option was used but the specified SID was invalid. + The '-r' option was used but the specified SID was invalid. 16 Either the named file could not be opened, or it is not an SCCS @@ -1822,7 +1765,7 @@ Things that paranoid people might bear i checksum accordingly (in other words, an on-disk checksum only protects the data while it is on the disk). - * Even if `val' concludes that a history file is structurally valid, + * Even if 'val' concludes that a history file is structurally valid, this does not mean that the file contains what you thought it did (for example, perhaps the file was corrupted by having another, valid, SCCS file copied over it, or perhaps it was overwritten by @@ -1834,54 +1777,53 @@ Things that paranoid people might bear i Things that an optimistic person might bear in mind are * The chances of a random change simultaneously fooling the checksum - and the checks that `val' does are very small indeed. + and the checks that 'val' does are very small indeed. * Hardware failures rarely cause file corruption. The use of ECC memory substantially reduces your changes of having undetected data corruption. - * When CSSC operates on an SCCS file, most of the checks that `val' + * When CSSC operates on an SCCS file, most of the checks that 'val' performs are done anyway (CSSC differs slightly in this respect from the traditional SCCS toolset). The summary is that it is theoretically possible to fool the -integrity checks performed by the SCCS file checksum and by `val' but -the checksum isn't fooled often and the chances of fooling both -together are very small. The use of quality hardware reduces the -chance of data corruption yet further. +integrity checks performed by the SCCS file checksum and by 'val' but +the checksum isn't fooled often and the chances of fooling both together +are very small. The use of quality hardware reduces the chance of data +corruption yet further.  File: cssc.info, Node: what, Prev: val, Up: Invoking CSSC Programs -3.16 `what' +3.16 'what' =========== -The `what' program is designed to search in files for the recognition -string `@(#)'. All the strings it finds matching this are printed on +The 'what' program is designed to search in files for the recognition +string '@(#)'. All the strings it finds matching this are printed on standard output. - The exit status of `what' if zero is a matching string as found, and + The exit status of 'what' if zero is a matching string as found, and 1 otherwise. -3.16.1 Options for `what' +3.16.1 Options for 'what' ------------------------- -`what [-s] [-V] file [file ...]' -`-s' +'what [-s] [-V] file [file ...]' +'-s' Exit successfully after finding the first string. - -`-V' - Show version information for `what'. +'-V' + Show version information for 'what'. 3.16.2 Example -------------- -While the file is being edited (either at first or after `get -e'):- +While the file is being edited (either at first or after 'get -e'):- #ifndef CONFIG_NO_SCCS_IDS static const char sccs_id[] = "%W%"; #endif - When the file is checked out for compiling (with `get'):- + When the file is checked out for compiling (with 'get'):- #ifndef CONFIG_NO_SCCS_IDS static const char sccs_id[] = "@(#)foo.c 1.3"; #endif @@ -1893,16 +1835,16 @@ While the file is being edited (either a If the executable is linked from several source files, you will get a line of output for each string containing the identification string -`@(#)'. This is useful for finding out exactly what code went into an +'@(#)'. This is useful for finding out exactly what code went into an executable. This technique also works on object files, archive libraries, text files, and in fact any sorts of files at all. - Unlike the `strings' command, there is no way to make `what' operate + Unlike the 'strings' command, there is no way to make 'what' operate on standard input. The data would need to be written to a file first. - The rationale for the preprocessor construct `CONFIG_NO_SCCS_IDS' is + The rationale for the preprocessor construct 'CONFIG_NO_SCCS_IDS' is that sometimes compilers or lint-pickers complain that the variable -SCCS_ID is unused, and defining `CONFIG_NO_SCCS_IDS' will remove these +SCCS_ID is unused, and defining 'CONFIG_NO_SCCS_IDS' will remove these IDs and thus silence the warnings.  @@ -1912,21 +1854,17 @@ File: cssc.info, Node: Filenames, Next *********** Temporary files are used during normal operation of CSSC (and SCCS). -Many of these are given fixed names. The prefixes for the various -files used by CSSC are listed in the table below. +Many of these are given fixed names. The prefixes for the various files +used by CSSC are listed in the table below. -`s.' +'s.' The history file itself. - -`l.' - The delta summary file created by `get -l'. Unlike the other - files in this table, the l-file is created in the current - directory. - -`p.' +'l.' + The delta summary file created by 'get -l'. Unlike the other files + in this table, the l-file is created in the current directory. +'p.' The file containing the list of edit locks. - -`z.' +'z.' The lock file used to arbitrate access to the history file. The running CSSC (or SCCS) program puts its PID into this file. Some versions of SCCS (but _not_ CSSC) will break the lock after 60 @@ -1934,21 +1872,17 @@ files used by CSSC are listed in the tab In order to work more reliably over networked file systems, CSSC will not do this; stale lock files would have to be removed manually. - -`x.' +'x.' Temporary file into which is written the new s-file. Once processing is complete, the old s-file is replaced by the x-file. - -`q.' +'q.' Temporary file into which is written the new p-file - -`d.' +'d.' Temporary file used by delta; contains the gotten body of the previous version (which we run diff against). This filename is used by SCCS in the same situation, but according to the SCCS - manual pages, it puts the output of `diff' in this file instead. - -`u.' + manual pages, it puts the output of 'diff' in this file instead. +'u.' Encoded version of the gotten file; created by delta. Except for the l-file, all of the temporary files in the above table @@ -1969,8 +1903,8 @@ File: cssc.info, Node: File Format, Ne ************* This chapter provides a description of the format of SCCS files. It is -_not authoritative_, and may not match some of the peculiarities of -your vendor's implementation. +_not authoritative_, and may not match some of the peculiarities of your +vendor's implementation. * Menu: @@ -1985,17 +1919,17 @@ File: cssc.info, Node: File Format Over ============ An SCCS file contains two parts, the header and the body. The header -contains information about both the file as a whole and also -information about each version stored in the file. After this comes the -body itself, which is a stream of fragments from the controlled file +contains information about both the file as a whole and also information +about each version stored in the file. After this comes the body +itself, which is a stream of fragments from the controlled file interspersed with control information which indicates which versions these fragments appear in. - Most of the control information for SCCS files appears on lines -which are marked as special by the character whose value is 1 (ASCII -SOH); this is usually referred to as `^A'. Lines in SCCS files always -end with a line feed (ASCII LF) rather than a carriage return (ASCII -CR) followed by a line feed. + Most of the control information for SCCS files appears on lines which +are marked as special by the character whose value is 1 (ASCII SOH); +this is usually referred to as '^A'. Lines in SCCS files always end +with a line feed (ASCII LF) rather than a carriage return (ASCII CR) +followed by a line feed.  File: cssc.info, Node: The Header, Next: The Body, Prev: File Format Overview, Up: File Format @@ -2020,22 +1954,22 @@ File: cssc.info, Node: Checksum Line, 5.2.1 Checksum -------------- -The first line of an SCCS file contains the checksum, preceded by -`^Ah'. The checksum is in decimal and is generated by adding together -the values of all the characters in the file, and taking the result -modulo 65536. A checksum line might look like this:- +The first line of an SCCS file contains the checksum, preceded by '^Ah'. +The checksum is in decimal and is generated by adding together the +values of all the characters in the file, and taking the result modulo +65536. A checksum line might look like this:- ^Ah36650 - On systems whose C implementation considers the `char' type to be + On systems whose C implementation considers the 'char' type to be unsigned, characters with their highest bit set appear to be considered -positive, and on machines with a signed `char' type, these characters +positive, and on machines with a signed 'char' type, these characters appear to be considered negative. This seems to mean that these two types of machines will not agree on the correctness of an SCCS file's checksum. - The _BitKeeper_ suite uses `^AH' to introduce its checksum line -rather than `^Ah', but the checksum is computed in the same way. + The _BitKeeper_ suite uses '^AH' to introduce its checksum line +rather than '^Ah', but the checksum is computed in the same way.  File: cssc.info, Node: Delta Table, Next: Authorised User List, Prev: Checksum Line, Up: The Header @@ -2048,7 +1982,7 @@ version stored in the history file, and some comment lines. The first line introduces a new delta table entry and has the form - `^As 00001/00000/00010' + ^As 00001/00000/00010 The three numbers represent the numbers of lines inserted, deleted and unchanged in this version (with respect to its predecessor). For @@ -2061,19 +1995,19 @@ contain 99999. The second line has the form - `^AD 1.5 68/12/31 23:59:59 james 5 4' + ^AD 1.5 68/12/31 23:59:59 james 5 4 -Here, the `D' indicates that this is a normal delta. The only other -type of delta is the removed delta. Removed deltas are created with -the `rmdel' program and are labelled with an `R' instead of a `D'. -This is followed by the SID, which will have either two or four fields -separated by a decimal point (ASCII code 46 decimal). A SID with only -two fields (release and level) is said to be on the trunk of the -revision tree. A SID with the full four fields (the last two are the -branch number and the sequence number) is said to be a "branch -revision". Each field in the SID, if present, must contain a positive -integer no larger than 9999. This means that `1.0' would not be a -valid version number, for example. +Here, the 'D' indicates that this is a normal delta. The only other +type of delta is the removed delta. Removed deltas are created with the +'rmdel' program and are labelled with an 'R' instead of a 'D'. This is +followed by the SID, which will have either two or four fields separated +by a decimal point (ASCII code 46 decimal). A SID with only two fields +(release and level) is said to be on the trunk of the revision tree. A +SID with the full four fields (the last two are the branch number and +the sequence number) is said to be a "branch revision". Each field in +the SID, if present, must contain a positive integer no larger than +9999. This means that '1.0' would not be a valid version number, for +example. The third and fourth fields on this line are the date and time at which this delta was added to the history file (rather than, for @@ -2093,30 +2027,30 @@ in on the controlling terminal. The final two fields are called "delta sequence numbers", or "seqnos". They are for the internal use of the implementation and should not be confused with "sequence numbers", which are the final -fields of four-field ("branch") SIDS. The seqno of the delta added -last will be larger than that of any other delta. Each delta has a -unique seqno. The first of these two fields is the seqno of this delta -itself, and the second field is the seqno of its predecessor (that is, -the version which had been checked out with `get -e'). The seqno 0 is +fields of four-field ("branch") SIDS. The seqno of the delta added last +will be larger than that of any other delta. Each delta has a unique +seqno. The first of these two fields is the seqno of this delta itself, +and the second field is the seqno of its predecessor (that is, the +version which had been checked out with 'get -e'). The seqno 0 is special and appears only as the (nonexistent) predecessor of the first delta. Since the delta table entries appear in reverse order of addition -(i.e. new entries are always added at the top), the initial delta +(i.e. new entries are always added at the top), the initial delta appears at the foot of the delta table. Many of the SCCS utilities define their cutoffs in such a way that they can stop traversing the delta table when they find a delta which is too old. - After the `^Ad' line there may be several lines which indicate lists + After the '^Ad' line there may be several lines which indicate lists of included, excluded or ignored sequence numbers for this delta. I don't understand this area of the functionality of SCCS very well, so -any description here may be vague or incorrect. The CSSC -implementation may also be incomplete in this area. +any description here may be vague or incorrect. The CSSC implementation +may also be incomplete in this area. - The list of included seqnos is introduced with `^Ai', the excluded -seqnos with `^Ax', and ignored seqnos with `^Ag'. These are followed -by a space character, and then the list itself, which is a -space-separated list of integers. + The list of included seqnos is introduced with '^Ai', the excluded +seqnos with '^Ax', and ignored seqnos with '^Ag'. These are followed by +a space character, and then the list itself, which is a space-separated +list of integers. If the MR-validation flag (*note Flags::) was turned on at the time of the creation of this delta, one or more lines of the form @@ -2129,28 +2063,27 @@ of the creation of this delta, one or mo may occur. These lines constitute a list of Modification Request Numbers, one on each line. - The next part of the delta table entry is the delta commentary. -This comment is intended to contain a description of the changes made in -this delta, and is written and read by humans. This may extend over one -or many lines, each introduced with `^Ac', like this:- + The next part of the delta table entry is the delta commentary. This +comment is intended to contain a description of the changes made in this +delta, and is written and read by humans. This may extend over one or +many lines, each introduced with '^Ac', like this:- ^Ac The end of the world ^Ac as we know it If there is no comment for a particular delta, because it was -suppressed with the `-y' option to `delta' or `cdc', or because the -user was presented with a prompt for comments but just typed the return -key, an empty `^Ac' control line will appear at this point. +suppressed with the '-y' option to 'delta' or 'cdc', or because the user +was presented with a prompt for comments but just typed the return key, +an empty '^Ac' control line will appear at this point. CSSC is currently slightly incorrect in this area. If the comment is -suppressed with the `-y' option, it emits no `^Ac' lines at all. +suppressed with the '-y' option, it emits no '^Ac' lines at all. - The _BitKeeper_ suite uses comment lines of the form `^AcX' (where -`X' is a non-blank character) to store data which is specific to + The _BitKeeper_ suite uses comment lines of the form '^AcX' (where +'X' is a non-blank character) to store data which is specific to BitKeeper. This data is ignored by CSSC, which provides read-only -support for BitKeeper files. These special lines are distinguished -from normal comment lines by the fact that there is no space after the -`c':- +support for BitKeeper files. These special lines are distinguished from +normal comment lines by the fact that there is no space after the 'c':- ^AcHathlon.transmeta.com ^AcK09043 @@ -2160,8 +2093,8 @@ from normal comment lines by the fact th ^AcX0x821 ^AcZ-08:00 - Some SCCS files contain an MR list which follows rather than -precedes the comments for a delta, but this is unusual. + Some SCCS files contain an MR list which follows rather than precedes +the comments for a delta, but this is unusual. The comment block, and in fact the whole delta table entry, is terminated by a control line of the form @@ -2186,16 +2119,16 @@ File: cssc.info, Node: Authorised User 5.2.3 Authorised User List -------------------------- -Next, there is the list of authorised users, introduced by a `^Au' -line. Only users in the authorised users list can modify the SCCS -file. This list always appears (though many implementations will not -complain if you remove it with an editor) but is often empty. One user -login name appears on each line. Lines can alternatively contain -numbers, denoting whole groups of users (as listed in `/etc/group' on -many systems). The authorised-users list is terminated with a `^AU' -line. Some broken implementations emit lines of the form `^AU 0' here -instead; the polite thing to do is to ignore gaffes of this sort. This -is of course what CSSC does. +Next, there is the list of authorised users, introduced by a '^Au' line. +Only users in the authorised users list can modify the SCCS file. This +list always appears (though many implementations will not complain if +you remove it with an editor) but is often empty. One user login name +appears on each line. Lines can alternatively contain numbers, denoting +whole groups of users (as listed in '/etc/group' on many systems). The +authorised-users list is terminated with a '^AU' line. Some broken +implementations emit lines of the form '^AU 0' here instead; the polite +thing to do is to ignore gaffes of this sort. This is of course what +CSSC does.  File: cssc.info, Node: Global Flags Section, Next: File Description, Prev: Authorised User List, Up: The Header @@ -2213,7 +2146,7 @@ These lines look like this:- ^Af f q Q-flag-value ^Af f v /bin/true - The `e' flag, if set to a nonzero value, indicates that the + The 'e' flag, if set to a nonzero value, indicates that the controlled file is binary and is therefore stored in uuencoded form in the file body. If this flag is set to zero or is missing, then the file body is not encoded. See *note Flags:: for information about the other @@ -2221,19 +2154,19 @@ possible flag letters and their meanings for information about sharing SCCS files with other implementations of SCCS. - The `e' flag is a boolean flag but is stored within the SCCS file -with a value, as shown in the example above. When CSSC initially -writes the SCCS file header for a new SCCS fiel created with `admin --i', it does not know if the initial body of the file is binary or not, -so `^Af f e 0' is written into the header and if the file turns out to -need encoding, `admin' will seek back to the header and change `^Af f e -0' to `^Af f e 1'. If binary file support is disabled (*note Binary -File Support::, `^Af f e 0' is still used but will never be changed to -`^Af f e 1'. + The 'e' flag is a boolean flag but is stored within the SCCS file +with a value, as shown in the example above. When CSSC initially writes +the SCCS file header for a new SCCS fiel created with 'admin -i', it +does not know if the initial body of the file is binary or not, so '^Af +f e 0' is written into the header and if the file turns out to need +encoding, 'admin' will seek back to the header and change '^Af f e 0' to +'^Af f e 1'. If binary file support is disabled (*note Binary File +Support::, '^Af f e 0' is still used but will never be changed to '^Af f +e 1'. - The value for the `y' flag is stored as a space-separated list of + The value for the 'y' flag is stored as a space-separated list of keyword letters, even though the letters were separated by commas when -they were passed to `admin -fy'. This flag is an extension introduced +they were passed to 'admin -fy'. This flag is an extension introduced by Sun Solaris 8. See *note Interoperability:: for a discussion of the interoperability of CSSC with other SCCS implementations. @@ -2246,15 +2179,15 @@ File: cssc.info, Node: File Description The flags section is followed by the descriptive text for the history file. This section is intended to contain text which might contain a copyright statement, or might indicate the purpose of a file or contain -special instructions, and so on. This section starts with a `^At' -control line and is terminated with a `^AT' control line:- +special instructions, and so on. This section starts with a '^At' +control line and is terminated with a '^AT' control line:- ^At This is the blah blah... ... blah. ^AT - The `^AT' control line marks the end of the SCCS file's header. The + The '^AT' control line marks the end of the SCCS file's header. The following line is the first line of the file body.  @@ -2310,11 +2243,11 @@ File: cssc.info, Node: The Body, Prev: ============ The body of an SCCS file is usually much longer than its header, but -contains fewer ingredients. It contains control lines, which signal -the beginning or end of a chunk of user data, and the user data itself. -If, for example, you added the text `I was here' to the controlled file -as a delta whose delta sequence number was 7, the history might contain -these lines:- +contains fewer ingredients. It contains control lines, which signal the +beginning or end of a chunk of user data, and the user data itself. If, +for example, you added the text 'I was here' to the controlled file as a +delta whose delta sequence number was 7, the history might contain these +lines:- ^AI 7 I was here @@ -2322,10 +2255,10 @@ these lines:- I currently have no clear understanding of the interaction of excluded, included or excluded revisions with the normal check-in -processing. Hence I can't thoroughly explain the precise meaning of -the `^AI', `^AE' and `^AD' control lines. This section will be -completed at a future date. If you have an understanding of these -issues, please let me () know. +processing. Hence I can't thoroughly explain the precise meaning of the +'^AI', '^AE' and '^AD' control lines. This section will be completed at +a future date. If you have an understanding of these issues, please let +me () know.  File: cssc.info, Node: Interoperability, Next: Environment, Prev: File Format, Up: Top @@ -2333,15 +2266,15 @@ File: cssc.info, Node: Interoperability 6 Interoperability ****************** -This part of the CSSC manual describes how CSSC interoperates with -SCCS. For the enormous majority of cases, this occurs seamlessly; -however sometimes it is not possible for CSSC to pick "one right way" -to proceed unaided. Circumstances where this occurs are described in -detail, below. +This part of the CSSC manual describes how CSSC interoperates with SCCS. +For the enormous majority of cases, this occurs seamlessly; however +sometimes it is not possible for CSSC to pick "one right way" to proceed +unaided. Circumstances where this occurs are described in detail, +below. In order to interoperate better with other implementations of SCCS, -the CSSC suite can also be configured to turn off several features -which provide flexibility beyond that which is available in some other +the CSSC suite can also be configured to turn off several features which +provide flexibility beyond that which is available in some other implementations of SCCS. Some other interoperability features of CSSC exist to maintain compatibility but do not need to be turned off. @@ -2365,20 +2298,20 @@ File: cssc.info, Node: Binary File Supp ======================= Binary file support can be turned off when you run "configure" by -specifying the `--disable-binary' option. This will cause `admin' to +specifying the '--disable-binary' option. This will cause 'admin' to refuse to create an SCCS file whose "e" flag is set (*note Flags::). -The `admin' program would normally do this if the user requested it via -the `-b' option or if it discovered that the file could not safely be +The 'admin' program would normally do this if the user requested it via +the '-b' option or if it discovered that the file could not safely be stored in the normal SCCS file format. This setting can be overridden with the environment variable -`CSSC_BINARY_SUPPORT'; for a description of how to use this environment +'CSSC_BINARY_SUPPORT'; for a description of how to use this environment variable, see *note Environment Variables: Environment. If you use CSSC with support for encoded SCCS files turned off, encoded files will still be handled; CSSC will just refuse to create a -new one. This provides as great a degree of interoperability with -other implementations of SCCS as possible. +new one. This provides as great a degree of interoperability with other +implementations of SCCS as possible.  File: cssc.info, Node: Executable File Support, Next: BitKeeper, Prev: Binary File Support, Up: Interoperability @@ -2392,15 +2325,15 @@ controlled file is used for any particul files can contain non-ASCII acharacters. This should be contrasted with support for _executable_ files, which -have a specific Unix file mode bit set (see the manual page for `chmod' +have a specific Unix file mode bit set (see the manual page for 'chmod' for more details). Unix executable files may or may not be binary files. It's common to control shell scripts with CSSC, for example. Shell scripts are normaly executable but not binary. - If the `x' flag is set, CSSC will generate a g-file whose execute + If the 'x' flag is set, CSSC will generate a g-file whose execute bits are set. This feature exists for compatibility with SCO OpenServer's SCCS. Do not use this feature if you wish to interoperate -with other implementations of SCCS. Setting this flag with `admin -fx' +with other implementations of SCCS. Setting this flag with 'admin -fx' generates a warning about this.  @@ -2409,25 +2342,21 @@ File: cssc.info, Node: BitKeeper, Next 6.3 BitKeeper ============= -Read-only support is provided for files produced by the BitKeeper -suite. Flags and information which are specific to BitKeeper is -ignored by CSSC. At the moment, it is not possible to turn off support -for BitKeeper files, but a warning message is issued when one is +Read-only support is provided for files produced by the BitKeeper suite. +Flags and information which are specific to BitKeeper is ignored by +CSSC. At the moment, it is not possible to turn off support for +BitKeeper files, but a warning message is issued when one is encountered. Actions on BitKeeper files that CSSC will not perform include * get -e - * delta - * cdc - * rmdel - * Some options to admin - CSSC does not prevent the use of `unget' on BitKeeper files, because -`unget' does not examine the SCCS file header (and therefore has no way + CSSC does not prevent the use of 'unget' on BitKeeper files, because +'unget' does not examine the SCCS file header (and therefore has no way to determine if the file is a BitKeeper file or not).  @@ -2438,12 +2367,12 @@ File: cssc.info, Node: Maximum Line Len By default, CSSC enforces no line length limits. The CSSC tools will correctly process input files containing lines of arbitrary length, -subject to the limits of available memory. The system command `diff' +subject to the limits of available memory. The system command 'diff' may impose its own limit however; this is discussed below (*note Limitations of diff::). - If you are working with a binary file (that is, the `-b' option to -`admin' was used when the history file was created), the encoding + If you are working with a binary file (that is, the '-b' option to +'admin' was used when the history file was created), the encoding mechanism used by CSSC (and those SCCS implementations that support binary files) ensures that data is encoded before being stored in the body of the history file, and so the "binary" file can contain any @@ -2453,35 +2382,35 @@ sequence of bytes at all - the "line len the maximum length of line that can be handled in a text file (that is, those versions of SCCS which have such a limit do not apply this limit for binary files). To set such a limit in CSSC, use the -`--enable-max-line-length=N' option to "configure". This sets the -limit to the specified value. +'--enable-max-line-length=N' option to "configure". This sets the limit +to the specified value. This setting can be overridden with the environment variable -`CSSC_MAX_LINE_LENGTH'; for a description of how to use this -environment variable, see *note Environment Variables: Environment. To -determine the current setting of the line length limit, run `admin -V' -and read the output. +'CSSC_MAX_LINE_LENGTH'; for a description of how to use this environment +variable, see *note Environment Variables: Environment. To determine +the current setting of the line length limit, run 'admin -V' and read +the output. If (and only if) you have configured CSSC with such a maximum line length limitation, the lengths of input lines are checked as they are being read. When CSSC is adding a new delta to an existing file, if it -finds an input line which is longer than N characters, it will fail -with an explanatory message (the alternative would be that an SCCS file -would be generated that could not be read by other implementations of -SCCS having a lower line length limit). +finds an input line which is longer than N characters, it will fail with +an explanatory message (the alternative would be that an SCCS file would +be generated that could not be read by other implementations of SCCS +having a lower line length limit). - When CSSC is creating a new SCCS file in response to the `admin -i' + When CSSC is creating a new SCCS file in response to the 'admin -i' command, one of two things will happen when an over-length line is found. If binary file support is enabled, the SCCS file will -automatically be created as an encoded file. Otherwise, `admin' will +automatically be created as an encoded file. Otherwise, 'admin' will fail with an explanatory message. - When the CSSC tools are reading a history file, the lines in the -SCCS file are not subject to the limits described above; that is, CSSC + When the CSSC tools are reading a history file, the lines in the SCCS +file are not subject to the limits described above; that is, CSSC imposes these limits on lines it puts _into_ the SCCS file, but not on -lines it reads _from_ the SCCS file. This means that the CSSC `get' +lines it reads _from_ the SCCS file. This means that the CSSC 'get' utility will cope with arbitrarily long lines in the SCCS file, even if -CSSC has been configured in sauch a way that `delta' would not put such +CSSC has been configured in sauch a way that 'delta' would not put such long lines into the history file.  @@ -2490,35 +2419,34 @@ File: cssc.info, Node: Limitations of d 6.5 Limitations of diff ======================= -The `diff' utility may have limits on the lengths of lines that it can -process, though the GNU `diff' program has no such limits. This means -that if you are using CSSC in combination with a `diff' which has a -line length limit, that limit will apply to the operation of the CSSC -`delta' and `sccsdiff' programs (though not to any other component of -CSSC). +The 'diff' utility may have limits on the lengths of lines that it can +process, though the GNU 'diff' program has no such limits. This means +that if you are using CSSC in combination with a 'diff' which has a line +length limit, that limit will apply to the operation of the CSSC 'delta' +and 'sccsdiff' programs (though not to any other component of CSSC). - This kind of problem may cause `delta' to fail because the file you + This kind of problem may cause 'delta' to fail because the file you are checking in contains an over-length line. However, because SCCS files may be operated on by SCCS implementations that have different upper limits, you might also find that the delta you checked out from the history file already contained a line which is longer than can be -coped with by your `delta' utility. GNU CSSC can always be switched -back a mode in which there is no line length limit (i.e. the mode which +coped with by your 'delta' utility. GNU CSSC can always be switched +back a mode in which there is no line length limit (i.e. the mode which is usually the default) and so can be used to work around such situations. - Bear in mind that implementations of `diff' and SCCS on a given + Bear in mind that implementations of 'diff' and SCCS on a given system can have _different_ limits on the sizes of lines that can be -handled by `delta', `get' and `diff'. This is not the case with the -GNU system however, which has no such limits. +handled by 'delta', 'get' and 'diff'. This is not the case with the GNU +system however, which has no such limits. - The `diff' utility will also fail if the last line in one of the -files being compared does not end in a newline. To work around this -you can either encode the file as a binary file (*note admin::) or add -a terminating newline (which is usually the best course of action). + The 'diff' utility will also fail if the last line in one of the +files being compared does not end in a newline. To work around this you +can either encode the file as a binary file (*note admin::) or add a +terminating newline (which is usually the best course of action). - The `diff' program to be used by the CSSC tools is selected when the -`configure' script is run, before CSSC is compiled. *note + The 'diff' program to be used by the CSSC tools is selected when the +'configure' script is run, before CSSC is compiled. *note Configuration:: explains how you can determine which diff command is used by CSSC. @@ -2529,7 +2457,7 @@ File: cssc.info, Node: Configuration, ====================================== To discover how a particular installation of CSSC is configured, pass -the `-V' option to any of the CSSC tools. The "configure" script +the '-V' option to any of the CSSC tools. The "configure" script defaults to not limiting the maximum line length, but you must specifically indicate if binary file support is to be enabled or not when running "configure". @@ -2541,24 +2469,24 @@ File: cssc.info, Node: Bug-for-Bug, Ne ============================= Some other implementations of SCCS have bugs, too. Where we know about -these and can work around them, we do this. Please note that these -bugs only affect _some_ other versions of SCCS - if they affected all +these and can work around them, we do this. Please note that these bugs +only affect _some_ other versions of SCCS - if they affected all versions, they'd be the correct behaviour of CSSC too! * Some versions of SCCS had a Y2K-related problem where the tens digit in the year fields within the delta table of the SCCS file - contains a colon (`:') rather than a digit. When reading files, + contains a colon (':') rather than a digit. When reading files, CSSC correctly understands this to be a zero and issues a warning message. The fault is corrected if the SCCS file is being modified. *Note Year 2000 Issues::. * Some versions of the Data General implementation were changed to use four-digit years in the p-file instead of two-digit years, - apparently as part of a Y2K-fix. While arguably this in fact - might have been the right way to fix the problem, none of the - other SCCS implementations went along with the idea. *Note Year - 2000 Issues::. If the file is being modified, the year is written - back out as a two-digit field. + apparently as part of a Y2K-fix. While arguably this in fact might + have been the right way to fix the problem, none of the other SCCS + implementations went along with the idea. *Note Year 2000 + Issues::. If the file is being modified, the year is written back + out as a two-digit field. * Although it is unusual for SCCS files to have "^A m" lines after "^A c" lines, this does sometimes occur. CSSC accepts either @@ -2566,7 +2494,7 @@ versions, they'd be the correct behaviou delta. * CSSC accepts "^A m" lines with no argument, although this is - unusual. This may in fact not actually be a bug. + unusual. This may in fact not actually be a bug. * Some versions of SCCS (allegedly some versions of the Sun Code Manager product) emit lines of the form "^AU 0" instead of "^A U". @@ -2601,24 +2529,24 @@ File: cssc.info, Node: SCCS Version Dif 6.9 SCCS Version Differences ============================ -This section outlines some of the ways in which various versions of -SCCS differ from each other and therefore sometimes from CSSC. +This section outlines some of the ways in which various versions of SCCS +differ from each other and therefore sometimes from CSSC. 6.9.1 Binary file support and line lengths ------------------------------------------ -The various versions of SCCS differ in their level of support for -binary files (*note Binary File Support::), and in the maximum line -length that they will support (*note Maximum Line Length::. +The various versions of SCCS differ in their level of support for binary +files (*note Binary File Support::), and in the maximum line length that +they will support (*note Maximum Line Length::. 6.9.2 sccsdiff -------------- There are some small variations in the way that the several versions of -`sccsdiff' behave. These are outlined in the table below :- +'sccsdiff' behave. These are outlined in the table below :- Solaris 8 - Prints a separator line between the `diff' output for each s-file. + Prints a separator line between the 'diff' output for each s-file. This separator is output before the first set of diff output, even if only one s-file has been named on the command line. @@ -2628,57 +2556,56 @@ Solaris 2.6 and many other versions of U 6.9.3 admin ----------- -There are a few differences in the behaviour of the `admin' command +There are a few differences in the behaviour of the 'admin' command across the various SCCS Implementations :- -The `-n' option - Some versions of Dynix do not allow the use of the `-n' option - without the `-i' option. A workaround is to use `-n -i/dev/null' +The '-n' option + Some versions of Dynix do not allow the use of the '-n' option + without the '-i' option. A workaround is to use '-n -i/dev/null' instead. Binary file support Most implementations of SCCS do not support the encoding of binary - files, either automatically or by the use of the `-b' option to - `admin'. See *note Binary File Support::, for more information. + files, either automatically or by the use of the '-b' option to + 'admin'. See *note Binary File Support::, for more information. Executable file support - The SCO OpenServer implementation of SCCS provides an `x' flag, + The SCO OpenServer implementation of SCCS provides an 'x' flag, which turns on the executable bits of the mode of the g-file when it is created. Other versions of SCCS do not have this feature. - While CSSSC provides this feature also, its use is not - recommended. The `prt -f' command does not indicate the value of - the `x' flag. + While CSSSC provides this feature also, its use is not recommended. + The 'prt -f' command does not indicate the value of the 'x' flag. Initial delta - The `-r' option is used to specify the release of the initial + The '-r' option is used to specify the release of the initial delta. Some implementations of SCCS allow this to be used to - specify more components of a SID than just the release number. - The CSSC version of `admin' allows this usage but issues a warning - message. If the `-r' option is used to specify a non-trunk SID - (that is, a SID with more than two components), this is allowed - but some of the other tools in the CSSC suite will not work - correctly on the resulting file. + specify more components of a SID than just the release number. The + CSSC version of 'admin' allows this usage but issues a warning + message. If the '-r' option is used to specify a non-trunk SID + (that is, a SID with more than two components), this is allowed but + some of the other tools in the CSSC suite will not work correctly + on the resulting file. 6.9.4 prt --------- -If the "encoded" flag is set, some versions of `prt' (but not the CSSC +If the "encoded" flag is set, some versions of 'prt' (but not the CSSC version) omit a newline in the output and so the next thing follows immediately on the same line. 6.9.5 get --------- -Sun Solaris 8 features a `y' flag. If the `y' flag is set in the SCCS +Sun Solaris 8 features a 'y' flag. If the 'y' flag is set in the SCCS file, only the specified SCCS keywords will be expanded in the gotten -file (assuming that the `-k' and `-e' options are not used). +file (assuming that the '-k' and '-e' options are not used). - The `get' command on SCO OpenServer honours the setting of the `x' + The 'get' command on SCO OpenServer honours the setting of the 'x' flag. This is described above. For a discussion of the interoperability of CSSC with other SCCS -implementations, see *note Interoperability::. For a description of -the `x' and `y' flags, see *note Flags::. +implementations, see *note Interoperability::. For a description of the +'x' and 'y' flags, see *note Flags::.  File: cssc.info, Node: CSSC Extensions, Prev: SCCS Version Differences, Up: Interoperability @@ -2696,72 +2623,71 @@ Line Length Line Length::. Date handling - The `-c' option to `get' supports four-digit years. *Note The - Good News::. + The '-c' option to 'get' supports four-digit years. *Note The Good + News::. Binary file handling - When you generate a new SCCS file with `admin -i', the `admin' + When you generate a new SCCS file with 'admin -i', the 'admin' command will automatically determine if the file needs to be encoded. Other versions of SCCS which do this rely on being able - to seek in the input file specified as the argument to the `-i' + to seek in the input file specified as the argument to the '-i' option, which means that this is not possible if the initial file - body is being read by a pipe. The CSSC implementation of `admin' + body is being read by a pipe. The CSSC implementation of 'admin' does not have this limitation, since it seeks on the file being created instead. *Note Unemulated Features::. Combinations of features - Various other SCCS implementations have extensions (for example - the `x' and `y' flags and binary file encoding). The CSSC suite + Various other SCCS implementations have extensions (for example the + 'x' and 'y' flags and binary file encoding). The CSSC suite attempts to honour all of these extensions, and is probably the only implementation which has all these features. If you try to - use a feature which is specific to only one implementation of - SCCS, CSSC will issue a warning that what you are doing is not - portable. + use a feature which is specific to only one implementation of SCCS, + CSSC will issue a warning that what you are doing is not portable. If you use features of CSSC which are extensions originating in - more than one other SCCS implementation, for example both the `x' - and the `y' flags, you have effectively tied yourself to CSSC. + more than one other SCCS implementation, for example both the 'x' + and the 'y' flags, you have effectively tied yourself to CSSC. Once you are in that position, you are no longer able to interoperate with any other version of SCCS (since, in this example, any other version of SCCS will fail to understand either - the `x' or the `y' flag). If interoperability with other versions + the 'x' or the 'y' flag). If interoperability with other versions of SCCS is no longer an issue, you might as well bite the bullet - and migrate to a more modern configuration control system - entirely. *Note Overview::. + and migrate to a more modern configuration control system entirely. + *Note Overview::. Validation - The CSSC implementation of `val' implements some checks that other - implementations lack. Howver, it is not complete, and so there - are also checks that other implementations make that CSSC does not. + The CSSC implementation of 'val' implements some checks that other + implementations lack. Howver, it is not complete, and so there are + also checks that other implementations make that CSSC does not. Error Messages The error messages issued by CSSC are intended to be - self-explanatory and so lack reference numbers like `(ge4)'. + self-explanatory and so lack reference numbers like '(ge4)'. Closed File Descriptors - If you invoke CSSC with file descriptor 0, 1 or 2 closed, that - file descriptor is attached to `/dev/null'. This prevents error + If you invoke CSSC with file descriptor 0, 1 or 2 closed, that file + descriptor is attached to '/dev/null'. This prevents error messages going into a file opened by CSSC for writing (for example an SCCS file). Read-only reaction to unsupported features If CSSC discovers a construct in an SCCS file which it doesn't understand, it will avoid modifying the file (though read-only - tools like `prt' and `get' will still work). + tools like 'prt' and 'get' will still work). Invoking other tools - It is usual for CSSC to invoke other programs, for example `diff' - and the MR-validator specified by the `v' flag. However, with the - exception of the `sccsdiff' shell script, the tools within the - CSSC suite do not invoke each other. For example, `delta' does - not invoke `get'. This behaviour is different to the traditional + It is usual for CSSC to invoke other programs, for example 'diff' + and the MR-validator specified by the 'v' flag. However, with the + exception of the 'sccsdiff' shell script, the tools within the CSSC + suite do not invoke each other. For example, 'delta' does not + invoke 'get'. This behaviour is different to the traditional architecture of SCCS and might introduce subtle differences of behaviour. Any such differences are bugs; see *note Reporting Bugs: Problems. Environment - Some environment variables are specific to CSSC. *Note - Environment Variables: Environment. + Some environment variables are specific to CSSC. *Note Environment + Variables: Environment. See also *note Missing Features and other Problems: Incomplete. @@ -2787,31 +2713,30 @@ File: cssc.info, Node: Child Processes, =================== Unlike some other implementations of SCCS, CSSC tools do not usually -execute each other. This means for example that `delta' does not -invoke `get' to extract the previous version of the file, and `prs' -doesn't use `get' when processing the `:GB:' keyword. +execute each other. This means for example that 'delta' does not invoke +'get' to extract the previous version of the file, and 'prs' doesn't use +'get' when processing the ':GB:' keyword. There are a small number of exceptions to this rule :- -`sccs' - The `sccs' driver program can be used to invoke any of the other +'sccs' + The 'sccs' driver program can be used to invoke any of the other tools in the suite. *Note Known Problems::, for a discussion of the issues this raises. -`delta' - The `delta' program runs a program to validate the Modification +'delta' + The 'delta' program runs a program to validate the Modification Request Numbers offered by the user. *Note Modification Request Numbers::. -`sccsdiff' - The `sccsdiff' program is a shell script, and invokes `get', - `diff' and `pr', as well as other tools such as `cat', `test' and - `rm'. The `sccsdiff' program must not be installed set-user-id. - - The driver program `sccs' takes a number of precautionary steps if -it detects that it is running set-user-id or set-group-id. These steps -are described below, as part of the discussion of each environment -variable. +'sccsdiff' + The 'sccsdiff' program is a shell script, and invokes 'get', 'diff' + and 'pr', as well as other tools such as 'cat', 'test' and 'rm'. + The 'sccsdiff' program must not be installed set-user-id. + + The driver program 'sccs' takes a number of precautionary steps if it +detects that it is running set-user-id or set-group-id. These steps are +described below, as part of the discussion of each environment variable.  File: cssc.info, Node: Configuration Variables, Next: Other Variables, Prev: Child Processes, Up: Environment @@ -2825,38 +2750,36 @@ overridden with the use of environment v 7.2.1 CSSC_BINARY_SUPPORT ------------------------- -The `CSSC_BINARY_SUPPORT' environment variable controls whether CSSC +The 'CSSC_BINARY_SUPPORT' environment variable controls whether CSSC will create "encoded" SCCS files. The three valid values for this variable are as follows :- -`enabled' +'enabled' CSSC will create encoded SCCS files if required - -`disabled' +'disabled' CSSC will not create encoded SCCS files - unset The default behaviour is used; this default will be the same as for - one of `enabled' or `disabled'. The default is set by passing - either `--enable-binary' or `--disable-binary' to "configure" when + one of 'enabled' or 'disabled'. The default is set by passing + either '--enable-binary' or '--disable-binary' to "configure" when CSSC is compiled. If this option was not specified, the default - value is `enabled'. For more information see *note + value is 'enabled'. For more information see *note Interoperability::. - This variable is unset by the `sccs' driver program, if it is + This variable is unset by the 'sccs' driver program, if it is installed set-user-id or set-group-id. 7.2.2 CSSC_MAX_LINE_LENGTH -------------------------- -The `CSSC_MAX_LINE_LENGTH' environment variable controls the maximum +The 'CSSC_MAX_LINE_LENGTH' environment variable controls the maximum length of lines that CSSC will allow to go into an SCCS file. This variable should be set to a decimal integer. The default behaviour of CSSC when this variable is unset is described in *note Interoperability::. - This variable is unset by the `sccs' driver program, if it is + This variable is unset by the 'sccs' driver program, if it is installed set-user-id or set-group-id.  @@ -2868,84 +2791,84 @@ File: cssc.info, Node: Other Variables, 7.3.1 USER ---------- -If "configure" detects that UIDs are not supported on the system you -are running on (that is, you are compiling on a system that doesn't look -at all like Unix) then the environment variable USER is used to -determine the invoking user's name. This is then the name which is used -in the p-file and in the delta information for new deltas. This -username is also compared against the list of authorised users by -`delta'. Of course, this doesn't provide much security but in the -absence of user ID support, CSSC can't tell who users really are anyway. - - The behaviour of CSSC with respect to this option is not sensitive -to whether or not programs are installed set-user-id, because this -variable is only consulted on systems where set-user-id is not -supported. This may be a problem on systems where it is possible to -grant enhanced privileges to a program, but which do not look like Unix -to the "configure" program. +If "configure" detects that UIDs are not supported on the system you are +running on (that is, you are compiling on a system that doesn't look at +all like Unix) then the environment variable USER is used to determine +the invoking user's name. This is then the name which is used in the +p-file and in the delta information for new deltas. This username is +also compared against the list of authorised users by 'delta'. Of +course, this doesn't provide much security but in the absence of user ID +support, CSSC can't tell who users really are anyway. + + The behaviour of CSSC with respect to this option is not sensitive to +whether or not programs are installed set-user-id, because this variable +is only consulted on systems where set-user-id is not supported. This +may be a problem on systems where it is possible to grant enhanced +privileges to a program, but which do not look like Unix to the +"configure" program. 7.3.2 CSSC_SHOW_SEQSTATE ------------------------ -If set, the environment variable `CSSC_SHOW_SEQSTATE' will cause CSSC -to emit debugging information about the delta table to stderr. This is +If set, the environment variable 'CSSC_SHOW_SEQSTATE' will cause CSSC to +emit debugging information about the delta table to stderr. This is only of use when debugging CSSC. 7.3.3 PROJECTDIR ---------------- -The `PROJECTDIR' environment variable is used only by the `sccs' driver -program. This variable is ignored if the `sccs' program is installed +The 'PROJECTDIR' environment variable is used only by the 'sccs' driver +program. This variable is ignored if the 'sccs' program is installed with the set-user-ID bit set. See *note Known Problems::, for other remarks concerning setuid execution. - The `PROJECTDIR' variable is used to locate the SCCS history file + The 'PROJECTDIR' variable is used to locate the SCCS history file corresponding to a filename given on the command line. If the value of -`PROJECTDIR' starts with a `/', it is used as an absolute directory -name. If `PROJECTDIR' does not start with a slash, it is assumed to be -the name of a user, and SCCS files are assumed to be in the -subdirectory "src" or "source" beneath their home directory. +'PROJECTDIR' starts with a '/', it is used as an absolute directory +name. If 'PROJECTDIR' does not start with a slash, it is assumed to be +the name of a user, and SCCS files are assumed to be in the subdirectory +"src" or "source" beneath their home directory. 7.3.4 PATH ---------- -Normally, the `sccs' driver program locates the other tools by -searching the directories specified in `PATH', but if it is running -set-user-id or set-group-id, a compiled-in value is used instead. By -default, this value is is `/usr/sccs'. - - If SCCS is not privileged, it will fall back on the compiled-in -value in order to find the other tools if they are not found in any of -the directories in `$PATH'. - - In normal operation, `sccs diffs' will use the system `diff' command -by searching the `PATH' environment variable. This doesn't happen if -it is running set-user-id or set-group-id. +Normally, the 'sccs' driver program locates the other tools by searching +the directories specified in 'PATH', but if it is running set-user-id or +set-group-id, a compiled-in value is used instead. By default, this +value is is '/usr/sccs'. + + If SCCS is not privileged, it will fall back on the compiled-in value +in order to find the other tools if they are not found in any of the +directories in '$PATH'. + + In normal operation, 'sccs diffs' will use the system 'diff' command +by searching the 'PATH' environment variable. This doesn't happen if it +is running set-user-id or set-group-id. 7.3.5 LD_LIBRARY_PATH --------------------- None of the programs in the CSSC suite take any specific action -regarding the `LD_LIBRARY_PATH' environment variable, but your system +regarding the 'LD_LIBRARY_PATH' environment variable, but your system libraries may take notice of it (or decide not to do so, for example when a program is running set-user-id or set-group-id). 7.3.6 TMPDIR ------------ -The `sccsdiff' program ignores the setting of the `TMPDIR' environment +The 'sccsdiff' program ignores the setting of the 'TMPDIR' environment variable. Temporary files with predictable names are created in the -`/tmp' directory. *Note Known Problems::. +'/tmp' directory. *Note Known Problems::. 7.3.7 Locale variables ---------------------- -The `sccs' driver program uses the `setlocale' function, whose -behaviour depends on several implementation-dependent environment -variables. If you are using the GNU C library, these variables are -`LC_COLLATE', `LC_CTYPE', `LC_MESSAGES', `LC_MONETARY', `LC_NUMERIC', -`LC_TIME', and `LANG'. The `setlocale' function is not called if SCCS -is running set-user-id or set-group-id. +The 'sccs' driver program uses the 'setlocale' function, whose behaviour +depends on several implementation-dependent environment variables. If +you are using the GNU C library, these variables are 'LC_COLLATE', +'LC_CTYPE', 'LC_MESSAGES', 'LC_MONETARY', 'LC_NUMERIC', 'LC_TIME', and +'LANG'. The 'setlocale' function is not called if SCCS is running +set-user-id or set-group-id.  File: cssc.info, Node: Incomplete, Next: Year 2000 Issues, Prev: Environment, Up: Top @@ -2973,34 +2896,33 @@ File: cssc.info, Node: Missing Features * On platforms where the C++ compiler used to compile CSSC does not support exceptions, the normal mechanism for recovering from an - error in the processing of an SCCS file is unavailable. This - means that if such an error occurs, the program will immediately - make a fatal exit, as opposed to carrying on with the next file. - In order to fix this problem, please either CSSC with a compiler - which has working support for exceptions, or process just one file - at a time. + error in the processing of an SCCS file is unavailable. This means + that if such an error occurs, the program will immediately make a + fatal exit, as opposed to carrying on with the next file. In order + to fix this problem, please either CSSC with a compiler which has + working support for exceptions, or process just one file at a time. * Some programs behave subtly differently to their original counterparts. Error messages are different, and also extra - warnings are provided in some circumstances. All other - differences are also bugs. Please report them (*note Reporting - Bugs: Problems.). + warnings are provided in some circumstances. All other differences + are also bugs. Please report them (*note Reporting Bugs: + Problems.). * Known bugs are listed on the bug tracking system at - `http://savannah.gnu.org/bugs/?group=cssc'. Some historical known - issues are listed in the file `docs/BUGS'. Once this file has + . Some historical known + issues are listed in the file 'docs/BUGS'. Once this file has become obsolete it will be removed from the distribution. - If an item on the TODO list (see the file `docs/TODO') has in fact + If an item on the TODO list (see the file 'docs/TODO') has in fact been fixed, this is a bug in the TODO list. Please report this via the bug tracking system. * Some programs are partially implemented. Not all programs support - all the command-line options of their original counterparts. - Also, some features are currently missing. If you would like - support for some feature that is missing, please request it in the - same way you would report a bug; I'd like to know which features - are required first. + all the command-line options of their original counterparts. Also, + some features are currently missing. If you would like support for + some feature that is missing, please request it in the same way you + would report a bug; I'd like to know which features are required + first.  File: cssc.info, Node: Known Problems, Next: Unemulated Features, Prev: Missing Features, Up: Incomplete @@ -3009,60 +2931,60 @@ File: cssc.info, Node: Known Problems, ================== There are a small number of known problems documented in the files -`docs/BUGS' and `docs/TODO'. These will be fixed at some point in the -future. Future problems should be reported via the CSSC Bug Tracker, -at `http://savannah.gnu.org/bugs/?group=cssc'. +'docs/BUGS' and 'docs/TODO'. These will be fixed at some point in the +future. Future problems should be reported via the CSSC Bug Tracker, at +. There are also some security problems with this code:- 1. Temporary file races -- CSSC opens many temporary files, most of - them with very predictable names. This can be used as a lever - for compromising the security of a system, often by anticipating - the name of a file which will be opened at some point, and - creating a symbolic link of the same name. Most of the temporary - files used are created in the same directory as the SCCS file - itself. CSSC should not be used by the owners of files whose - security is important, especially to control files whose SCCS file - is in a world-writable directory. *Note Filenames::. + them with very predictable names. This can be used as a lever for + compromising the security of a system, often by anticipating the + name of a file which will be opened at some point, and creating a + symbolic link of the same name. Most of the temporary files used + are created in the same directory as the SCCS file itself. CSSC + should not be used by the owners of files whose security is + important, especially to control files whose SCCS file is in a + world-writable directory. *Note Filenames::. - The `sccsdiff' program ignores the setting of the `TMPDIR' + The 'sccsdiff' program ignores the setting of the 'TMPDIR' environment variable. Temporary files with predictable names are - created in the `/tmp' directory. + created in the '/tmp' directory. 2. Setuid execution -- It is common to install an extra set of binaries with the set-user-id bit turned on in their modes, to allow a specified group of users to make revisions to some - important files. There are many ways in which a setuid program - can be used by malicious users to gain access to the security + important files. There are many ways in which a setuid program can + be used by malicious users to gain access to the security privileges of the user as whom a program runs. CSSC has not been reviewed with the relevant security issues in mind. Please do not install CSSC programs with the set-user-id or set-group-id bits turned on. 3. Environment variables -- CSSC invokes external programs, notably - the `diff' command and the program specified as the MR validation - program. Some CSSC programs (for example `sccsdiff') invoke - others. This is done without "cleaning up" the environment, and - so this is another reason not to use the set-user-id bit for CSSC + the 'diff' command and the program specified as the MR validation + program. Some CSSC programs (for example 'sccsdiff') invoke + others. This is done without "cleaning up" the environment, and so + this is another reason not to use the set-user-id bit for CSSC programs. *Note Environment Variables: Environment. Please refer to the section of the GNU General Public License entitled "NO WARRANTY" for information regarding the lack of warranty -for this program. CSSC is _not_ a secure program, please do not rely -on it to behave in a secure fashion. +for this program. CSSC is _not_ a secure program, please do not rely on +it to behave in a secure fashion. Contributions of code or patches to fix these problems are, as always, gleefully welcomed. Please submit these to the maintainer. Additionally, there is currently one problem that may not ever be -fixed. This problem occurs only in the `prt' program when the list of +fixed. This problem occurs only in the 'prt' program when the list of ignored or excluded deltas is present for a SID _but that list is -empty_. In this case SCCS prints the `Included:' or `Excluded:' line -in its output (with no numbers afterward) and CSSC prints nothing. -Since "fixing" this problem would require a horrible kludge, this has -not been done. It is not expected that this will cause a problem for -any users; if this is a problem for you, let the maintainer know and it -will be fixed. +empty_. In this case SCCS prints the 'Included:' or 'Excluded:' line in +its output (with no numbers afterward) and CSSC prints nothing. Since +"fixing" this problem would require a horrible kludge, this has not been +done. It is not expected that this will cause a problem for any users; +if this is a problem for you, let the maintainer know and it will be +fixed.  File: cssc.info, Node: Unemulated Features, Prev: Known Problems, Up: Incomplete @@ -3073,19 +2995,19 @@ File: cssc.info, Node: Unemulated Featu There are some features of (some implementations of) the traditional SCCS suite which it may not be desirable to copy. - 1. If an SCCS file is created with the `-i' option, and it turns out + 1. If an SCCS file is created with the '-i' option, and it turns out to need encoding, then genuine SCCS seeks back to the start of the file and encodes it. However, if the input file is not seekable, for example if it is a pipe, then this doesn't always work. The SCCS file is then sometimes created containing only the initial part of the body, before the offending segment of the file. The - exit value of the `admin' program is nevertheless still zero. - Tests for this situation are in `tests/binary/seeking.sh' but - these tests are only carried out if the program under test seems - to be CSSC rather than the genuine SCCS suite. The CSSC suite - does not have this problem, and will always detect the need to - encode the file, and will successfully complete the process (it - does not try to seek on the input pipe). + exit value of the 'admin' program is nevertheless still zero. + Tests for this situation are in 'tests/binary/seeking.sh' but these + tests are only carried out if the program under test seems to be + CSSC rather than the genuine SCCS suite. The CSSC suite does not + have this problem, and will always detect the need to encode the + file, and will successfully complete the process (it does not try + to seek on the input pipe). 2. The normal configuration for CSSC is that it supports binary files and has no limit on line length in file with which it deals. Both @@ -3095,12 +3017,10 @@ SCCS suite which it may not be desirable interoperability with other implementations of SCCS. 3. If you have a hard link to an SCCS file, then SCCS programs would - "break" the hard link because the SCCS file is rewritten. For - this reason, SCCS checks the link count on the file before using - it. The SCCS suite also does this. While CSSC does this - consistently, SCCS does not - for example the VAL program does not - do this check. - + "break" the hard link because the SCCS file is rewritten. For this + reason, SCCS checks the link count on the file before using it. + The SCCS suite also does this. While CSSC does this consistently, + SCCS does not - for example the VAL program does not do this check. There are also a small number of respects in which various implementations differ from each other; in such cases CSSC picks a @@ -3114,10 +3034,10 @@ File: cssc.info, Node: Year 2000 Issues Primordial (but not current) versions of the genuine SCCS suite fail to work correctly in and after the year 2000. The commands affected are -`get' and `prs'. Unix vendors have ensured that the version of SCCS +'get' and 'prs'. Unix vendors have ensured that the version of SCCS that they currently ship works correctly in the year 2000. Sun Microsystems, for example, state in their Year 2000 FAQ -(`http://www.sun.com/y2000/faq.html') +() * *Does Sun see any problems with the source code control system @@ -3126,7 +3046,7 @@ Microsystems, for example, state in thei standard, the year 2000 compliant version of SCCS will not be affected by the end of century transition. The X/Open standard states that old dates held in ("yy/mm/dd") format does not change - in "s." files, but the values "yy" which range from 69 - 99 are to + in "s." files, but the values "yy" which range from 69 - 99 are to be interpreted as 1969 - 1999 respectively. Values of "yy" which range from 00 - 68 are to be interpreted as 2000 - 2068 respectively. This interpretation ensures that the year 2000 @@ -3134,12 +3054,13 @@ Microsystems, for example, state in thei implementing X/Open's standard, Sun has ensured SCCS user's compatibility with other providers of the SCCS utility. For more information please refer to: - `http://www.xopen.org/public/tech/base/year2000.html' + Copyright (C) 1994 - 1997 Sun Microsystems, Inc., 901 San Antonio - Road, Palo Alto, CA 94303 USA. All rights reserved. + Road, Palo Alto, CA 94303 USA. All rights reserved. + * Menu: @@ -3160,13 +3081,13 @@ strategy mandated by X/Open. The comman with similarly. CSSC provides an additional feature for your convenience. If the -argument to the `-c' option of `get', `prt', or `prs' contains more -than twelve digits, the first two are understood to be the century part -of the year. For example, `971120193000' and `19971120193000' both -represent exactly the same time (7:30 p.m. on November 20, 1997). The -fields of a date can be separated with other (non-digit) characters, -and so `1997/11/20-19:30:00' also denotes the same time (but -`1997/11/20' is an error because there are fewer than twelve digits). +argument to the '-c' option of 'get', 'prt', or 'prs' contains more than +twelve digits, the first two are understood to be the century part of +the year. For example, '971120193000' and '19971120193000' both +represent exactly the same time (7:30 p.m. on November 20, 1997). The +fields of a date can be separated with other (non-digit) characters, and +so '1997/11/20-19:30:00' also denotes the same time (but '1997/11/20' is +an error because there are fewer than twelve digits). Some versions of SCCS are not year 2000 compliant and write incorrect timestamps into SCCS files. CSSC correctly understands the intended @@ -3175,14 +3096,14 @@ Bug-for-Bug Compatibility: Bug-for-Bug.) CSSC represents dates internally in a way that works for Gregorian dates up to at least the year 32767 AD on all systems. Some countries -didn't recognise the Gregorian calendar system until the early -twentieth century but this of course is not really a problem now. The -useful life of SCCS is from 1969 until 2068. Years are stored in -two-digit form in SCCS files and so although CSSC has no such limits -internally, it's not possible to indicate a year outside this range in -an SCCS file if you want to retain compatibility with other -implementations of SCCS. All the CSSC programs will successfully work -with any date in this range, all the way up to 2068, on all systems. +didn't recognise the Gregorian calendar system until the early twentieth +century but this of course is not really a problem now. The useful life +of SCCS is from 1969 until 2068. Years are stored in two-digit form in +SCCS files and so although CSSC has no such limits internally, it's not +possible to indicate a year outside this range in an SCCS file if you +want to retain compatibility with other implementations of SCCS. All +the CSSC programs will successfully work with any date in this range, +all the way up to 2068, on all systems. In this future, years after 2068 may be represented as four-digit fields, but CSSC doesn't do this yet. @@ -3190,7 +3111,7 @@ fields, but CSSC doesn't do this yet. The CSSC test suite (*note The Test Suite: Testing.) contains some test files which may be useful in determining the date range with which your usual SCCS implementation will cope. These are in the directory -`tests/year-2000'. +'tests/year-2000'.  File: cssc.info, Node: The Bad News, Next: Year 2000 Summary, Prev: The Good News, Up: Year 2000 Issues @@ -3199,18 +3120,18 @@ File: cssc.info, Node: The Bad News, N ================ It's not all good news though. When new deltas are created with the -`delta' command, CSSC must consult the operating system to find the +'delta' command, CSSC must consult the operating system to find the current date and time. Some operating systems have a limited range of -date representation. For example, the development system I use for -most of the work on CSSC can't report any date later than Tuesday Jan -19 03:14:07 2038 as the current time. When running on such systems, -CSSC will still be able to work with SCCS files containing dates after -this, but activities involving the current time will not work correctly. +date representation. For example, the development system I use for most +of the work on CSSC can't report any date later than Tuesday Jan 19 +03:14:07 2038 as the current time. When running on such systems, CSSC +will still be able to work with SCCS files containing dates after this, +but activities involving the current time will not work correctly. This date breakdown occurs most obviously with the date stamp that -the `delta' program gives each delta in the SCCS file, but also with -the commentary-change message of `cdc' and the default comment produced -by `admin' when an SCCS file is created. +the 'delta' program gives each delta in the SCCS file, but also with the +commentary-change message of 'cdc' and the default comment produced by +'admin' when an SCCS file is created.  File: cssc.info, Node: Year 2000 Summary, Prev: The Bad News, Up: Year 2000 Issues @@ -3220,20 +3141,19 @@ File: cssc.info, Node: Year 2000 Summar To summarise, all reporting activities of CSSC will work correctly throughout the range of time representable in an SCCS file (that is, -from 1969 to 2068 inclusive). However, commands which modify SCCS -files and need to add dates may fail earlier than this (but then again, -may not, depending on your operating system). +from 1969 to 2068 inclusive). However, commands which modify SCCS files +and need to add dates may fail earlier than this (but then again, may +not, depending on your operating system). Now that you know that whatever version of SCCS you are using has probably been fixed by the vendor, and that even if your vendor's SCCS implementation cannot be updated for some reason, CSSC is Year-2000 -compliant and to an extent Year-2038 compliant, I'd like you to -remember the conversion effort that this has saved you. I'd also like -to urge to to actually use that effort to convert your existing -projects from SCCS to a more modern version control system, for example -GNU CVS. There are other considerations besides Year-2000 compliance, -after all. CSSC is not called "Compatibly Stupid Source Control" for -nothing. +compliant and to an extent Year-2038 compliant, I'd like you to remember +the conversion effort that this has saved you. I'd also like to urge to +to actually use that effort to convert your existing projects from SCCS +to a more modern version control system, for example GNU CVS. There are +other considerations besides Year-2000 compliance, after all. CSSC is +not called "Compatibly Stupid Source Control" for nothing.  File: cssc.info, Node: Testing, Next: Problems, Prev: Year 2000 Issues, Up: Top @@ -3241,10 +3161,9 @@ File: cssc.info, Node: Testing, Next: 10 The Test Suite ***************** -The test suite is the most important single component of the CSSC -suite. It ensures that ports to new platforms are working correctly, -and that changes in one part of the suite don't accidentally break -anything else. +The test suite is the most important single component of the CSSC suite. +It ensures that ports to new platforms are working correctly, and that +changes in one part of the suite don't accidentally break anything else. The test suites cannot cover everything. More are needed. If you only ever contribute one thing to CSSC, make it a new test case. This @@ -3275,11 +3194,11 @@ you might compile CSSC with The full test suite takes just over five minutes to run on a 486 running Linux. If everything works correctly, you will see messages like:- - cd tests && make all-tests + cd tests && make all-tests make[1]: Entering directory `..../CSSC/compile-here/tests' cd ../lndir && make make[2]: Entering directory `..../CSSC/compile-here/lndir' - make[2]: `lndir' is up to date. + make[2]: `lndir' is up to date. make[2]: Leaving directory `..../CSSC/compile-here/lndir' ../lndir/lndir ../../Master-Source/tests ../../Master-Source/tests/get: @@ -3317,15 +3236,15 @@ something like this:- Tests failed. make: *** [all-tests] Error 2 -The thing to remember is that when you run `make check', the `make' -program will print on the last line a message saying "Error" only if -the tests have failed. +The thing to remember is that when you run 'make check', the 'make' +program will print on the last line a message saying "Error" only if the +tests have failed. If the test suite does indicate that the tests have failed, please submit a bug report (*note Reporting Bugs: Problems.). Please include in your bug report - * The output of the test suite (you may find the Unix `script' + * The output of the test suite (you may find the Unix 'script' program invaluable for this) * The contents of the directory containing the test that failed (if @@ -3333,18 +3252,17 @@ in your bug report want the one in the "object" directory). * As much information about your system as you think is useful, for - example the names and versions of the operating system and - compiler that you are using. + example the names and versions of the operating system and compiler + that you are using. If you want to run just some of the tests, there are rules in the makefile for just running some of them. For example, the tests in the -directory `tests/admin' can be run with `make test-admin'. Each test -directory is named after one of the CSSC programs. This indicates -which program the tests concentrate on verifying. Inevitably these -tests will use more than just one CSSC program; for example, most of -the tests involve using `admin' to create a SCCS file in the first -place. However, the directory indicates which tool those tests -concentrate on. +directory 'tests/admin' can be run with 'make test-admin'. Each test +directory is named after one of the CSSC programs. This indicates which +program the tests concentrate on verifying. Inevitably these tests will +use more than just one CSSC program; for example, most of the tests +involve using 'admin' to create a SCCS file in the first place. +However, the directory indicates which tool those tests concentrate on. It is possible for a test to neither pass or fail, but just go wrong. This can happen when the test script comes upon something that prevents @@ -3356,7 +3274,7 @@ happens you get output much like this:- rm: foo: Permission denied flags.sh: Test could not be completed -The part before the colon (`flags.sh') indicates which script could not +The part before the colon ('flags.sh') indicates which script could not be completed. No further tests will be attempted. Diagnosing the problem may or may not be simple. In this case, it's not hard; the problem is that the test suite is trying to clear away any temporary @@ -3374,13 +3292,13 @@ File: cssc.info, Node: Writing new test =========================== The test cases are really just shell scripts. They are suitable for -`/bin/sh' on most machines. The procedure for running these is +'/bin/sh' on most machines. The procedure for running these is explained in *note Running the tests::. These shell scripts read in some common function definitions (mostly from -`tests/common/test-common') and then proceed to conduct the tests. -This section explains those commands used in the test scripts that are -not simply normal shell commands. Normal shell commands like `sed' and -`grep' are not described. +'tests/common/test-common') and then proceed to conduct the tests. This +section explains those commands used in the test scripts that are not +simply normal shell commands. Normal shell commands like 'sed' and +'grep' are not described. The best approach for writing new test scripts or just individual new test cases is to first think of some aspect that needs better test @@ -3408,17 +3326,17 @@ File: cssc.info, Node: testing tests, ----------------------------- The best strategy for testing the CSSC test suite itself is to run it -against a genuine edition of SCCS, if you have one available. Before -running `make check', set the environment variable `dir' to point to -the directory containing the programs to be tested; this should usually -be `/usr/sccs'. +against a genuine edition of SCCS, if you have one available. Before +running 'make check', set the environment variable 'dir' to point to the +directory containing the programs to be tested; this should usually be +'/usr/sccs'. In many implementations of SCCS, some of the tools execute others -(for example, `delta' often executes `get' to retrieve the previous +(for example, 'delta' often executes 'get' to retrieve the previous version of the controlled file). This means that to correctly test the -test suite, your `PATH' environment variable should be set up to select +test suite, your 'PATH' environment variable should be set up to select the SCCS tools you want to test. Here is an example of the correct way -to set up the environment to test SCCS tools in `/usr/ccs/bin' :- +to set up the environment to test SCCS tools in '/usr/ccs/bin' :- dir=/usr/ccs/bin PATH=/usr/ccs/bin:$PATH @@ -3427,8 +3345,8 @@ to set up the environment to test SCCS t When you are sure that the test script is expecting the correct behaviour from programs under test, you can then run it against CSSC. -After all, if you're going to set out writing your test by assuming -that CSSC is correct in the area under test, of what value is the test? +After all, if you're going to set out writing your test by assuming that +CSSC is correct in the area under test, of what value is the test?  File: cssc.info, Node: docommand, Next: remove, Prev: testing tests, Up: Writing new test cases @@ -3436,28 +3354,28 @@ File: cssc.info, Node: docommand, Next 10.2.2 docommand ---------------- -The `docommand' function runs a specified program, and checks its -return value, standard output and error output against an expected -version. If any mismatch occurs, `fail' is called. The `docommand' -function is invoked with up to six arguments:- +The 'docommand' function runs a specified program, and checks its return +value, standard output and error output against an expected version. If +any mismatch occurs, 'fail' is called. The 'docommand' function is +invoked with up to six arguments:- docommand [--silent] LABEL COMMAND RETVAL STDOUT STDERR - The `docommand' function normally prints the label to indicate what + The 'docommand' function normally prints the label to indicate what stage the current test script has reached, followed by "done" when it -has finished. The `--silent' option turns off this behaviour, so that +has finished. The '--silent' option turns off this behaviour, so that if nothing goes wrong, no progress message is printed. This is occasionally used for commands that have already been tested by a script and are known to work, but which must be repeated several times in order to make some other kind of test, which is yet to come. I recommend you try to avoid using this option. - The other arguments to `docommand' are:- + The other arguments to 'docommand' are:- LABEL This is what is printed to indicate what is going on when the test starts. If all goes according to plan, it is followed by - `...done'. + '...done'. COMMAND This is the command to be executed, with all the required @@ -3465,20 +3383,20 @@ COMMAND RETVAL This is the expected return value. If COMMAND exits returning any - other value, `fail' will be called. If the test should not care - about the return value, use `IGNORE' as RETVAL. + other value, 'fail' will be called. If the test should not care + about the return value, use 'IGNORE' as RETVAL. STDOUT This is the text expected on the standard output of COMMAND. If - the test should not care about the standard output, use `IGNORE' as + the test should not care about the standard output, use 'IGNORE' as STDOUT. STDERR This is the text expected on the error output of COMMAND. If the - test should not care about the error output, use `IGNORE' as + test should not care about the error output, use 'IGNORE' as STDERR. - This command will run `admin' with three arguments, and expect it to + This command will run 'admin' with three arguments, and expect it to produce no output at all and return the value zero:- docommand C5 "${admin} -ifoo -yMyComment $s" 0 "" "" @@ -3490,9 +3408,9 @@ fail, returning 1 as its exit status:- In the example above, the error messages produced by SCCS and CSSC are different, but both indicate the same thing. However, since the -messages are different, `IGNORE' is used. +messages are different, 'IGNORE' is used. - The STDOUT and STDERR arguments are processed with the `echo_nonl' + The STDOUT and STDERR arguments are processed with the 'echo_nonl' function, and so escape codes are valid and indeed heavily used:- # Test the -m (annotate SID) option with several deltas... @@ -3506,7 +3424,7 @@ File: cssc.info, Node: remove, Next: s 10.2.3 remove ------------- -The `remove' function is for clearing up temporary files after tests +The 'remove' function is for clearing up temporary files after tests have finished, and for making sure that no instance of a file that a test is supposed to create already exists before the test is made. Typical usage is this:- @@ -3516,7 +3434,7 @@ Typical usage is this:- p=p.$f remove $f $s $p -The `remove' function is defined as:- +The 'remove' function is defined as:- remove () { rm -rf $* || miscarry Could not remove $* ; }  @@ -3525,9 +3443,9 @@ File: cssc.info, Node: success, Next: 10.2.4 success -------------- -The `success' function prints a message indicating that the current -test script has passed, and exits successfully. This is always done at -the foot of a test script. +The 'success' function prints a message indicating that the current test +script has passed, and exits successfully. This is always done at the +foot of a test script.  File: cssc.info, Node: fail, Next: echo_nonl, Prev: success, Up: Writing new test cases @@ -3535,11 +3453,11 @@ File: cssc.info, Node: fail, Next: ech 10.2.5 fail ----------- -If a test fails, it is usually because one of the `docommand' calls -fails, and so direct calls to the `fail' function are rare. However, -if you do want to call this function directly, you should supply as its +If a test fails, it is usually because one of the 'docommand' calls +fails, and so direct calls to the 'fail' function are rare. However, if +you do want to call this function directly, you should supply as its argument a short description of what has gone wrong. For example, the -`docommand' function uses `fail' in the following way:- +'docommand' function uses 'fail' in the following way:- fail "$label: $1: Expected return value $2, got return value $rv" @@ -3549,19 +3467,19 @@ File: cssc.info, Node: echo_nonl, Next 10.2.6 echo_nonl ---------------- -The `echo_nonl' function outputs its argument, without a following -newline. Escape codes as for `echo(1)' are understood. Depending on +The 'echo_nonl' function outputs its argument, without a following +newline. Escape codes as for 'echo(1)' are understood. Depending on the actual flavour of system that the test suite is running on, this -might internally use `echo -n' or `echo -e .....\c'. +might internally use 'echo -n' or 'echo -e .....\c'. - Please do not use either the `-n' or `-e' options for `echo(1)' -directly in test scripts, because they don't work in the same way on -all machines. The `echo_nonl' function is provided for this reason; -therefore, please use it. Please note also that while the `printf(1)' + Please do not use either the '-n' or '-e' options for 'echo(1)' +directly in test scripts, because they don't work in the same way on all +machines. The 'echo_nonl' function is provided for this reason; +therefore, please use it. Please note also that while the 'printf(1)' command may seem superior, it absolutely cannot be used because not all systems provide it. - Typical usage of `echo_nonl' might be:- + Typical usage of 'echo_nonl' might be:- echo_nonl Please wait while I finish what I am doing... # ... @@ -3573,7 +3491,7 @@ File: cssc.info, Node: miscarry, Next: 10.2.7 miscarry --------------- -The `miscarry' function is used to indicate that while the test suite +The 'miscarry' function is used to indicate that while the test suite has not found a problem with the programs being tested, there has been some other kind of problem that prevents further testing. @@ -3590,21 +3508,20 @@ File: cssc.info, Node: real-thing, Nex ----------------- The various implementations of SCCS vary in several different ways, but -the CSSC test suite tries very hard to pass when run against any -genuine implementation of SCCS unless it has a definite bug. This -means for example that although the CSSC version of `admin -i' will -support automatic switch-over to binary mode for a file provided via -stdin, and the test suite tests this, the same property is not required -of SCCS itself. - - The `real-thing' script checks if we are actually tesing a real -implementation of SCCS. It sets the environment variable -`TESTING_CSSC' to `true' or `false', depending on whether we are -testing CSSC or not. +the CSSC test suite tries very hard to pass when run against any genuine +implementation of SCCS unless it has a definite bug. This means for +example that although the CSSC version of 'admin -i' will support +automatic switch-over to binary mode for a file provided via stdin, and +the test suite tests this, the same property is not required of SCCS +itself. + + The 'real-thing' script checks if we are actually tesing a real +implementation of SCCS. It sets the environment variable 'TESTING_CSSC' +to 'true' or 'false', depending on whether we are testing CSSC or not. If you are really interested in whether the implementation being tested supports binary files or not, you should be using the -`config-data' script instead. +'config-data' script instead.  File: cssc.info, Node: need-prt, Prev: real-thing, Up: Writing new test cases @@ -3612,18 +3529,18 @@ File: cssc.info, Node: need-prt, Prev: 10.2.9 need-prt --------------- -The possible non-availability of `prt' is another thing that the CSSC +The possible non-availability of 'prt' is another thing that the CSSC test suite needs to know about in order to run successfully against all -working versions of SCCS. Some versions of SCCS lack the `prt' -program. For this reason, the tests for this tool (in the `tests/prt' -directory) are skipped if `prt' is missing. When writing test scripts, -you should never use `prt' unless you are actually testing `prt' itself -(you can almost always use `prs' instead). +working versions of SCCS. Some versions of SCCS lack the 'prt' program. +For this reason, the tests for this tool (in the 'tests/prt' directory) +are skipped if 'prt' is missing. When writing test scripts, you should +never use 'prt' unless you are actually testing 'prt' itself (you can +almost always use 'prs' instead). If your test is specifically designed to test the functionality of -`prt' itself on the other hand, just source `need-prt' before the first -test. The `need-prt' script will skip the remainder of the invoking -test script if `prt' is missing. You might use it like this, for +'prt' itself on the other hand, just source 'need-prt' before the first +test. The 'need-prt' script will skip the remainder of the invoking +test script if 'prt' is missing. You might use it like this, for example :- #! /bin/sh @@ -3640,26 +3557,25 @@ File: cssc.info, Node: Problems, Next: 11 Reporting Bugs ***************** -If you find a bug in GNU `CSSC', please report this via the CSSC bug -tracking system at `http://savannah.gnu.org/bugs/?group=cssc'. Please -include the version number, which you can find by giving the option -`--version' to any `CSSC' command. Also include in your message the -output that the program produced and the output you expected. An `s.' -file and instructions for reproducing the error are almost essential -unless the bug is very trivial. If you are unable to send the actual -s-file itself due to confidentiality concerns, you can mask the -contents by using the script `mogrify.awk', which removes the contents -of an SCCS file while preserving its structure. You will need to use -`admin -z' on the result in order to correct the checksum of the -transformed version of the file. If you do this, please make sure that -you check that the problem still occurs with the transformed version of -the file. +If you find a bug in GNU 'CSSC', please report this via the CSSC bug +tracking system at . Please +include the version number, which you can find by giving the option '--version' +to any 'CSSC' command. Also include in your message the output that the +program produced and the output you expected. An 's.' file and +instructions for reproducing the error are almost essential unless the +bug is very trivial. If you are unable to send the actual s-file itself +due to confidentiality concerns, you can mask the contents by using the +script 'mogrify.awk', which removes the contents of an SCCS file while +preserving its structure. You will need to use 'admin -z' on the result +in order to correct the checksum of the transformed version of the file. +If you do this, please make sure that you check that the problem still +occurs with the transformed version of the file. You may also find it helpful to join the mailing list. See the file -`docs/mailing-list.txt' for information about the mailing list. +'docs/mailing-list.txt' for information about the mailing list. If you have other questions, comments or suggestions about GNU -`CSSC', contact the maintainer via electronic mail to `jay@gnu.org' . +'CSSC', contact the maintainer via electronic mail to 'jay@gnu.org' .  File: cssc.info, Node: Copying, Next: GNU Free Documentation License, Prev: Problems, Up: Top @@ -3669,7 +3585,7 @@ GNU General Public License Version 3, 29 June 2007 - Copyright (C) 2007 Free Software Foundation, Inc. `http://fsf.org/' + Copyright (C) 2007 Free Software Foundation, Inc. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. @@ -3683,11 +3599,11 @@ and other kinds of works. The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to -share and change all versions of a program--to make sure it remains -free software for all its users. We, the Free Software Foundation, use -the GNU General Public License for most of our software; it applies -also to any other work released this way by its authors. You can apply -it to your programs, too. +share and change all versions of a program--to make sure it remains free +software for all its users. We, the Free Software Foundation, use the +GNU General Public License for most of our software; it applies also to +any other work released this way by its authors. You can apply it to +your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you @@ -3697,9 +3613,9 @@ want it, that you can change the softwar free programs, and that you know you can do these things. To protect your rights, we need to prevent others from denying you -these rights or asking you to surrender the rights. Therefore, you -have certain responsibilities if you distribute copies of the software, -or if you modify it: responsibilities to respect the freedom of others. +these rights or asking you to surrender the rights. Therefore, you have +certain responsibilities if you distribute copies of the software, or if +you modify it: responsibilities to respect the freedom of others. For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same @@ -3718,16 +3634,15 @@ changed, so that their problems will not authors of previous versions. Some devices are designed to deny users access to install or run -modified versions of the software inside them, although the -manufacturer can do so. This is fundamentally incompatible with the -aim of protecting users' freedom to change the software. The -systematic pattern of such abuse occurs in the area of products for -individuals to use, which is precisely where it is most unacceptable. -Therefore, we have designed this version of the GPL to prohibit the -practice for those products. If such problems arise substantially in -other domains, we stand ready to extend this provision to those domains -in future versions of the GPL, as needed to protect the freedom of -users. +modified versions of the software inside them, although the manufacturer +can do so. This is fundamentally incompatible with the aim of +protecting users' freedom to change the software. The systematic +pattern of such abuse occurs in the area of products for individuals to +use, which is precisely where it is most unacceptable. Therefore, we +have designed this version of the GPL to prohibit the practice for those +products. If such problems arise substantially in other domains, we +stand ready to extend this provision to those domains in future versions +of the GPL, as needed to protect the freedom of users. Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of @@ -3764,8 +3679,8 @@ TERMS AND CONDITIONS To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for - infringement under applicable copyright law, except executing it - on a computer or modifying a private copy. Propagation includes + infringement under applicable copyright law, except executing it on + a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. @@ -3779,8 +3694,8 @@ TERMS AND CONDITIONS to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to - the extent that warranties are provided), that licensees may - convey the work under this License, and how to view a copy of this + the extent that warranties are provided), that licensees may convey + the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion. @@ -3788,8 +3703,8 @@ TERMS AND CONDITIONS 1. Source Code. The "source code" for a work means the preferred form of the work - for making modifications to it. "Object code" means any - non-source form of a work. + for making modifications to it. "Object code" means any non-source + form of a work. A "Standard Interface" means an interface that either is an official standard defined by a recognized standards body, or, in @@ -3800,10 +3715,10 @@ TERMS AND CONDITIONS The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that - Major Component, and (b) serves only to enable use of the work - with that Major Component, or to implement a Standard Interface - for which an implementation is available to the public in source - code form. A "Major Component", in this context, means a major + Major Component, and (b) serves only to enable use of the work with + that Major Component, or to implement a Standard Interface for + which an implementation is available to the public in source code + form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code @@ -3811,15 +3726,15 @@ TERMS AND CONDITIONS The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable - work) run the object code and to modify the work, including - scripts to control those activities. However, it does not include - the work's System Libraries, or general-purpose tools or generally + work) run the object code and to modify the work, including scripts + to control those activities. However, it does not include the + work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, - Corresponding Source includes interface definition files - associated with source files for the work, and the source code for - shared libraries and dynamically linked subprograms that the work - is specifically designed to require, such as by intimate data + Corresponding Source includes interface definition files associated + with source files for the work, and the source code for shared + libraries and dynamically linked subprograms that the work is + specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. @@ -3836,22 +3751,22 @@ TERMS AND CONDITIONS copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running - a covered work is covered by this License only if the output, - given its content, constitutes a covered work. This License - acknowledges your rights of fair use or other equivalent, as - provided by copyright law. + a covered work is covered by this License only if the output, given + its content, constitutes a covered work. This License acknowledges + your rights of fair use or other equivalent, as provided by + copyright law. You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the - sole purpose of having them make modifications exclusively for - you, or provide you with facilities for running those works, - provided that you comply with the terms of this License in - conveying all material for which you do not control copyright. - Those thus making or running the covered works for you must do so - exclusively on your behalf, under your direction and control, on - terms that prohibit them from making any copies of your - copyrighted material outside their relationship with you. + sole purpose of having them make modifications exclusively for you, + or provide you with facilities for running those works, provided + that you comply with the terms of this License in conveying all + material for which you do not control copyright. Those thus making + or running the covered works for you must do so exclusively on your + behalf, under your direction and control, on terms that prohibit + them from making any copies of your copyrighted material outside + their relationship with you. Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section @@ -3868,8 +3783,8 @@ TERMS AND CONDITIONS When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License - with respect to the covered work, and you disclaim any intention - to limit operation or modification of the work as a means of + with respect to the covered work, and you disclaim any intention to + limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures. @@ -3939,8 +3854,8 @@ TERMS AND CONDITIONS b. Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a - written offer, valid for at least three years and valid for - as long as you offer spare parts or customer support for that + written offer, valid for at least three years and valid for as + long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a @@ -3950,32 +3865,31 @@ TERMS AND CONDITIONS to copy the Corresponding Source from a network server at no charge. - c. Convey individual copies of the object code with a copy of - the written offer to provide the Corresponding Source. This + c. Convey individual copies of the object code with a copy of the + written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b. d. Convey the object code by offering access from a designated - place (gratis or for a charge), and offer equivalent access - to the Corresponding Source in the same way through the same + place (gratis or for a charge), and offer equivalent access to + the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the - Corresponding Source may be on a different server (operated - by you or a third party) that supports equivalent copying - facilities, provided you maintain clear directions next to - the object code saying where to find the Corresponding Source. + Corresponding Source may be on a different server (operated by + you or a third party) that supports equivalent copying + facilities, provided you maintain clear directions next to the + object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you - remain obligated to ensure that it is available for as long - as needed to satisfy these requirements. + remain obligated to ensure that it is available for as long as + needed to satisfy these requirements. e. Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d. - A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work. @@ -3983,8 +3897,8 @@ TERMS AND CONDITIONS A "User Product" is either (1) a "consumer product", which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for - incorporation into a dwelling. In determining whether a product - is a consumer product, doubtful cases shall be resolved in favor of + incorporation into a dwelling. In determining whether a product is + a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, "normally used" refers to a typical or common use of that class of product, regardless of the status of the particular user or of the @@ -4015,11 +3929,11 @@ TERMS AND CONDITIONS The requirement to provide Installation Information does not include a requirement to continue to provide support service, - warranty, or updates for a work that has been modified or - installed by the recipient, or for the User Product in which it - has been modified or installed. Access to a network may be denied - when the modification itself materially and adversely affects the - operation of the network or violates the rules and protocols for + warranty, or updates for a work that has been modified or installed + by the recipient, or for the User Product in which it has been + modified or installed. Access to a network may be denied when the + modification itself materially and adversely affects the operation + of the network or violates the rules and protocols for communication across the network. Corresponding Source conveyed, and Installation Information @@ -4049,8 +3963,8 @@ TERMS AND CONDITIONS Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright - holders of that material) supplement the terms of this License - with terms: + holders of that material) supplement the terms of this License with + terms: a. Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or @@ -4060,9 +3974,8 @@ TERMS AND CONDITIONS Legal Notices displayed by works containing it; or c. Prohibiting misrepresentation of the origin of that material, - or requiring that modified versions of such material be - marked in reasonable ways as different from the original - version; or + or requiring that modified versions of such material be marked + in reasonable ways as different from the original version; or d. Limiting the use for publicity purposes of names of licensors or authors of the material; or @@ -4081,11 +3994,10 @@ TERMS AND CONDITIONS you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document - contains a further restriction but permits relicensing or - conveying under this License, you may add to a covered work - material governed by the terms of that license document, provided - that the further restriction does not survive such relicensing or - conveying. + contains a further restriction but permits relicensing or conveying + under this License, you may add to a covered work material governed + by the terms of that license document, provided that the further + restriction does not survive such relicensing or conveying. If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the @@ -4101,13 +4013,13 @@ TERMS AND CONDITIONS You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights - under this License (including any patent licenses granted under - the third paragraph of section 11). + under this License (including any patent licenses granted under the + third paragraph of section 11). However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) - provisionally, unless and until the copyright holder explicitly - and finally terminates your license, and (b) permanently, if the + provisionally, unless and until the copyright holder explicitly and + finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. @@ -4119,10 +4031,10 @@ TERMS AND CONDITIONS after your receipt of the notice. Termination of your rights under this section does not terminate - the licenses of parties who have received copies or rights from - you under this License. If your rights have been terminated and - not permanently reinstated, you do not qualify to receive new - licenses for the same material under section 10. + the licenses of parties who have received copies or rights from you + under this License. If your rights have been terminated and not + permanently reinstated, you do not qualify to receive new licenses + for the same material under section 10. 9. Acceptance Not Required for Having Copies. @@ -4136,7 +4048,7 @@ TERMS AND CONDITIONS by modifying or propagating a covered work, you indicate your acceptance of this License to do so. - 10. Automatic Licensing of Downstream Recipients. + 10. Automatic Licensing of Downstream Recipients. Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and @@ -4150,21 +4062,21 @@ TERMS AND CONDITIONS covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or - could give under the previous paragraph, plus a right to - possession of the Corresponding Source of the work from the - predecessor in interest, if the predecessor has it or can get it - with reasonable efforts. + could give under the previous paragraph, plus a right to possession + of the Corresponding Source of the work from the predecessor in + interest, if the predecessor has it or can get it with reasonable + efforts. You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you - may not impose a license fee, royalty, or other charge for - exercise of rights granted under this License, and you may not - initiate litigation (including a cross-claim or counterclaim in a - lawsuit) alleging that any patent claim is infringed by making, - using, selling, offering for sale, or importing the Program or any - portion of it. + may not impose a license fee, royalty, or other charge for exercise + of rights granted under this License, and you may not initiate + litigation (including a cross-claim or counterclaim in a lawsuit) + alleging that any patent claim is infringed by making, using, + selling, offering for sale, or importing the Program or any portion + of it. - 11. Patents. + 11. Patents. A "contributor" is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. @@ -4184,15 +4096,15 @@ TERMS AND CONDITIONS Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and - otherwise run, modify and propagate the contents of its - contributor version. + otherwise run, modify and propagate the contents of its contributor + version. In the following three paragraphs, a "patent license" is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a - patent or covenant not to sue for patent infringement). To - "grant" such a patent license to a party means to make such an - agreement or commitment not to enforce a patent against the party. + patent or covenant not to sue for patent infringement). To "grant" + such a patent license to a party means to make such an agreement or + commitment not to enforce a patent against the party. If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available @@ -4222,36 +4134,35 @@ TERMS AND CONDITIONS conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third - party that is in the business of distributing software, under - which you make payment to the third party based on the extent of - your activity of conveying the work, and under which the third - party grants, to any of the parties who would receive the covered - work from you, a discriminatory patent license (a) in connection - with copies of the covered work conveyed by you (or copies made - from those copies), or (b) primarily for and in connection with - specific products or compilations that contain the covered work, - unless you entered into that arrangement, or that patent license - was granted, prior to 28 March 2007. + party that is in the business of distributing software, under which + you make payment to the third party based on the extent of your + activity of conveying the work, and under which the third party + grants, to any of the parties who would receive the covered work + from you, a discriminatory patent license (a) in connection with + copies of the covered work conveyed by you (or copies made from + those copies), or (b) primarily for and in connection with specific + products or compilations that contain the covered work, unless you + entered into that arrangement, or that patent license was granted, + prior to 28 March 2007. Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law. - 12. No Surrender of Others' Freedom. + 12. No Surrender of Others' Freedom. - If conditions are imposed on you (whether by court order, - agreement or otherwise) that contradict the conditions of this - License, they do not excuse you from the conditions of this - License. If you cannot convey a covered work so as to satisfy - simultaneously your obligations under this License and any other - pertinent obligations, then as a consequence you may not convey it - at all. For example, if you agree to terms that obligate you to - collect a royalty for further conveying from those to whom you - convey the Program, the only way you could satisfy both those - terms and this License would be to refrain entirely from conveying - the Program. + If conditions are imposed on you (whether by court order, agreement + or otherwise) that contradict the conditions of this License, they + do not excuse you from the conditions of this License. If you + cannot convey a covered work so as to satisfy simultaneously your + obligations under this License and any other pertinent obligations, + then as a consequence you may not convey it at all. For example, + if you agree to terms that obligate you to collect a royalty for + further conveying from those to whom you convey the Program, the + only way you could satisfy both those terms and this License would + be to refrain entirely from conveying the Program. - 13. Use with the GNU Affero General Public License. + 13. Use with the GNU Affero General Public License. Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed @@ -4262,22 +4173,21 @@ TERMS AND CONDITIONS General Public License, section 13, concerning interaction through a network will apply to the combination as such. - 14. Revised Versions of this License. + 14. Revised Versions of this License. The Free Software Foundation may publish revised and/or new - versions of the GNU General Public License from time to time. - Such new versions will be similar in spirit to the present - version, but may differ in detail to address new problems or - concerns. + versions of the GNU General Public License from time to time. Such + new versions will be similar in spirit to the present version, but + may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of - that numbered version or of any later version published by the - Free Software Foundation. If the Program does not specify a - version number of the GNU General Public License, you may choose - any version ever published by the Free Software Foundation. + that numbered version or of any later version published by the Free + Software Foundation. If the Program does not specify a version + number of the GNU General Public License, you may choose any + version ever published by the Free Software Foundation. If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that @@ -4289,24 +4199,24 @@ TERMS AND CONDITIONS author or copyright holder as a result of your choosing to follow a later version. - 15. Disclaimer of Warranty. + 15. Disclaimer of Warranty. THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY - APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE + APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE + MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. - 16. Limitation of Liability. + 16. Limitation of Liability. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES - AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU - FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR + AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR + DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD @@ -4314,7 +4224,7 @@ TERMS AND CONDITIONS PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. - 17. Interpretation of Sections 15 and 16. + 17. Interpretation of Sections 15 and 16. If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, @@ -4323,7 +4233,6 @@ TERMS AND CONDITIONS connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee. - END OF TERMS AND CONDITIONS =========================== @@ -4354,7 +4263,7 @@ state the exclusion of warranty; and eac General Public License for more details. You should have received a copy of the GNU General Public License - along with this program. If not, see `http://www.gnu.org/licenses/'. + along with this program. If not, see . Also add information on how to contact you by electronic and paper mail. @@ -4363,11 +4272,11 @@ mail. notice like this when it starts in an interactive mode: PROGRAM Copyright (C) YEAR NAME OF AUTHOR - This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'. This is free software, and you are welcome to redistribute it - under certain conditions; type `show c' for details. + under certain conditions; type 'show c' for details. - The hypothetical commands `show w' and `show c' should show the + The hypothetical commands 'show w' and 'show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an "about box". @@ -4375,14 +4284,14 @@ use an "about box". You should also get your employer (if you work as a programmer) or school, if any, to sign a "copyright disclaimer" for the program, if necessary. For more information on this, and how to apply and follow -the GNU GPL, see `http://www.gnu.org/licenses/'. +the GNU GPL, see . The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, -please read `http://www.gnu.org/philosophy/why-not-lgpl.html'. +please read .  File: cssc.info, Node: GNU Free Documentation License, Next: BSD Code, Prev: Copying, Up: Top @@ -4393,7 +4302,7 @@ GNU Free Documentation License Version 1.3, 3 November 2008 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. - `http://fsf.org/' + Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. @@ -4418,21 +4327,21 @@ GNU Free Documentation License free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless - of subject matter or whether it is published as a printed book. - We recommend this License principally for works whose purpose is + of subject matter or whether it is published as a printed book. We + recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, - that contains a notice placed by the copyright holder saying it - can be distributed under the terms of this License. Such a notice + that contains a notice placed by the copyright holder saying it can + be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member - of the public is a licensee, and is addressed as "you". You - accept the license if you copy, modify or distribute the work in a - way requiring permission under copyright law. + of the public is a licensee, and is addressed as "you". You accept + the license if you copy, modify or distribute the work in a way + requiring permission under copyright law. A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with @@ -4450,12 +4359,12 @@ GNU Free Documentation License regarding them. The "Invariant Sections" are certain Secondary Sections whose - titles are designated, as being those of Invariant Sections, in - the notice that says that the Document is released under this - License. If a section does not fit the above definition of - Secondary then it is not allowed to be designated as Invariant. - The Document may contain zero Invariant Sections. If the Document - does not identify any Invariant Sections then there are none. + titles are designated, as being those of Invariant Sections, in the + notice that says that the Document is released under this License. + If a section does not fit the above definition of Secondary then it + is not allowed to be designated as Invariant. The Document may + contain zero Invariant Sections. If the Document does not identify + any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice @@ -4466,27 +4375,27 @@ GNU Free Documentation License A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document - straightforwardly with generic text editors or (for images - composed of pixels) generic paint programs or (for drawings) some - widely available drawing editor, and that is suitable for input to - text formatters or for automatic translation to a variety of - formats suitable for input to text formatters. A copy made in an - otherwise Transparent file format whose markup, or absence of - markup, has been arranged to thwart or discourage subsequent - modification by readers is not Transparent. An image format is - not Transparent if used for any substantial amount of text. A - copy that is not "Transparent" is called "Opaque". + straightforwardly with generic text editors or (for images composed + of pixels) generic paint programs or (for drawings) some widely + available drawing editor, and that is suitable for input to text + formatters or for automatic translation to a variety of formats + suitable for input to text formatters. A copy made in an otherwise + Transparent file format whose markup, or absence of markup, has + been arranged to thwart or discourage subsequent modification by + readers is not Transparent. An image format is not Transparent if + used for any substantial amount of text. A copy that is not + "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, - SGML or XML using a publicly available DTD, and - standard-conforming simple HTML, PostScript or PDF designed for - human modification. Examples of transparent image formats include - PNG, XCF and JPG. Opaque formats include proprietary formats that - can be read and edited only by proprietary word processors, SGML or - XML for which the DTD and/or processing tools are not generally - available, and the machine-generated HTML, PostScript or PDF - produced by some word processors for output purposes only. + SGML or XML using a publicly available DTD, and standard-conforming + simple HTML, PostScript or PDF designed for human modification. + Examples of transparent image formats include PNG, XCF and JPG. + Opaque formats include proprietary formats that can be read and + edited only by proprietary word processors, SGML or XML for which + the DTD and/or processing tools are not generally available, and + the machine-generated HTML, PostScript or PDF produced by some word + processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the @@ -4524,8 +4433,8 @@ GNU Free Documentation License may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you - distribute a large enough number of copies you must also follow - the conditions in section 3. + distribute a large enough number of copies you must also follow the + conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. @@ -4539,12 +4448,11 @@ GNU Free Documentation License these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The - front cover must present the full title with all words of the - title equally prominent and visible. You may add other material - on the covers in addition. Copying with changes limited to the - covers, as long as they preserve the title of the Document and - satisfy these conditions, can be treated as verbatim copying in - other respects. + front cover must present the full title with all words of the title + equally prominent and visible. You may add other material on the + covers in addition. Copying with changes limited to the covers, as + long as they preserve the title of the Document and satisfy these + conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit @@ -4552,40 +4460,39 @@ GNU Free Documentation License adjacent pages. If you publish or distribute Opaque copies of the Document - numbering more than 100, you must either include a - machine-readable Transparent copy along with each Opaque copy, or - state in or with each Opaque copy a computer-network location from - which the general network-using public has access to download - using public-standard network protocols a complete Transparent - copy of the Document, free of added material. If you use the - latter option, you must take reasonably prudent steps, when you - begin distribution of Opaque copies in quantity, to ensure that - this Transparent copy will remain thus accessible at the stated - location until at least one year after the last time you - distribute an Opaque copy (directly or through your agents or - retailers) of that edition to the public. + numbering more than 100, you must either include a machine-readable + Transparent copy along with each Opaque copy, or state in or with + each Opaque copy a computer-network location from which the general + network-using public has access to download using public-standard + network protocols a complete Transparent copy of the Document, free + of added material. If you use the latter option, you must take + reasonably prudent steps, when you begin distribution of Opaque + copies in quantity, to ensure that this Transparent copy will + remain thus accessible at the stated location until at least one + year after the last time you distribute an Opaque copy (directly or + through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of - the Document well before redistributing any large number of - copies, to give them a chance to provide you with an updated - version of the Document. + the Document well before redistributing any large number of copies, + to give them a chance to provide you with an updated version of the + Document. 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you - release the Modified Version under precisely this License, with - the Modified Version filling the role of the Document, thus - licensing distribution and modification of the Modified Version to - whoever possesses a copy of it. In addition, you must do these - things in the Modified Version: + release the Modified Version under precisely this License, with the + Modified Version filling the role of the Document, thus licensing + distribution and modification of the Modified Version to whoever + possesses a copy of it. In addition, you must do these things in + the Modified Version: A. Use in the Title Page (and on the covers, if any) a title - distinct from that of the Document, and from those of - previous versions (which should, if there were any, be listed - in the History section of the Document). You may use the - same title as a previous version if the original publisher of - that version gives permission. + distinct from that of the Document, and from those of previous + versions (which should, if there were any, be listed in the + History section of the Document). You may use the same title + as a previous version if the original publisher of that + version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in @@ -4615,31 +4522,30 @@ GNU Free Documentation License I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new - authors, and publisher of the Modified Version as given on - the Title Page. If there is no section Entitled "History" in - the Document, create one stating the title, year, authors, - and publisher of the Document as given on its Title Page, - then add an item describing the Modified Version as stated in - the previous sentence. + authors, and publisher of the Modified Version as given on the + Title Page. If there is no section Entitled "History" in the + Document, create one stating the title, year, authors, and + publisher of the Document as given on its Title Page, then add + an item describing the Modified Version as stated in the + previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for - previous versions it was based on. These may be placed in - the "History" section. You may omit a network location for a - work that was published at least four years before the - Document itself, or if the original publisher of the version - it refers to gives permission. + previous versions it was based on. These may be placed in the + "History" section. You may omit a network location for a work + that was published at least four years before the Document + itself, or if the original publisher of the version it refers + to gives permission. K. For any section Entitled "Acknowledgements" or "Dedications", - Preserve the Title of the section, and preserve in the - section all the substance and tone of each of the contributor + Preserve the Title of the section, and preserve in the section + all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. - L. Preserve all the Invariant Sections of the Document, - unaltered in their text and in their titles. Section numbers - or the equivalent are not considered part of the section - titles. + L. Preserve all the Invariant Sections of the Document, unaltered + in their text and in their titles. Section numbers or the + equivalent are not considered part of the section titles. M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. @@ -4652,11 +4558,11 @@ GNU Free Documentation License If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no - material copied from the Document, you may at your option - designate some or all of these sections as invariant. To do this, - add their titles to the list of Invariant Sections in the Modified - Version's license notice. These titles must be distinct from any - other section titles. + material copied from the Document, you may at your option designate + some or all of these sections as invariant. To do this, add their + titles to the list of Invariant Sections in the Modified Version's + license notice. These titles must be distinct from any other + section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various @@ -4665,15 +4571,15 @@ GNU Free Documentation License definition of a standard. You may add a passage of up to five words as a Front-Cover Text, - and a passage of up to 25 words as a Back-Cover Text, to the end - of the list of Cover Texts in the Modified Version. Only one - passage of Front-Cover Text and one of Back-Cover Text may be - added by (or through arrangements made by) any one entity. If the - Document already includes a cover text for the same cover, - previously added by you or by arrangement made by the same entity - you are acting on behalf of, you may not add another; but you may - replace the old one, on explicit permission from the previous - publisher that added the old one. + and a passage of up to 25 words as a Back-Cover Text, to the end of + the list of Cover Texts in the Modified Version. Only one passage + of Front-Cover Text and one of Back-Cover Text may be added by (or + through arrangements made by) any one entity. If the Document + already includes a cover text for the same cover, previously added + by you or by arrangement made by the same entity you are acting on + behalf of, you may not add another; but you may replace the old + one, on explicit permission from the previous publisher that added + the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to @@ -4683,8 +4589,8 @@ GNU Free Documentation License You may combine the Document with other documents released under this License, under the terms defined in section 4 above for - modified versions, provided that you include in the combination - all of the Invariant Sections of all of the original documents, + modified versions, provided that you include in the combination all + of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. @@ -4711,20 +4617,20 @@ GNU Free Documentation License documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the - rules of this License for verbatim copying of each of the - documents in all other respects. + rules of this License for verbatim copying of each of the documents + in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert - a copy of this License into the extracted document, and follow - this License in all other respects regarding verbatim copying of - that document. + a copy of this License into the extracted document, and follow this + License in all other respects regarding verbatim copying of that + document. 7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other - separate and independent documents or works, in or on a volume of - a storage or distribution medium, is called an "aggregate" if the + separate and independent documents or works, in or on a volume of a + storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this @@ -4769,8 +4675,8 @@ GNU Free Documentation License However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) - provisionally, unless and until the copyright holder explicitly - and finally terminates your license, and (b) permanently, if the + provisionally, unless and until the copyright holder explicitly and + finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. @@ -4782,33 +4688,33 @@ GNU Free Documentation License after your receipt of the notice. Termination of your rights under this section does not terminate - the licenses of parties who have received copies or rights from - you under this License. If your rights have been terminated and - not permanently reinstated, receipt of a copy of some or all of - the same material does not give you any rights to use it. + the licenses of parties who have received copies or rights from you + under this License. If your rights have been terminated and not + permanently reinstated, receipt of a copy of some or all of the + same material does not give you any rights to use it. - 10. FUTURE REVISIONS OF THIS LICENSE + 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See - `http://www.gnu.org/copyleft/'. + . Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been - published (not as a draft) by the Free Software Foundation. If - the Document does not specify a version number of this License, - you may choose any version ever published (not as a draft) by the - Free Software Foundation. If the Document specifies that a proxy - can decide which future versions of this License can be used, that + published (not as a draft) by the Free Software Foundation. If the + Document does not specify a version number of this License, you may + choose any version ever published (not as a draft) by the Free + Software Foundation. If the Document specifies that a proxy can + decide which future versions of this License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Document. - 11. RELICENSING + 11. RELICENSING "Massive Multiauthor Collaboration Site" (or "MMC Site") means any World Wide Web server that publishes copyrightable works and also @@ -4838,7 +4744,6 @@ GNU Free Documentation License site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing. - ADDENDUM: How to use this License for your documents ==================================================== @@ -4855,7 +4760,7 @@ notices just after the title page: Free Documentation License''. If you have Invariant Sections, Front-Cover Texts and Back-Cover -Texts, replace the "with...Texts." line with this: +Texts, replace the "with...Texts." line with this: with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts @@ -4866,9 +4771,9 @@ combination of the three, merge those tw situation. If your document contains nontrivial examples of program code, we -recommend releasing these examples in parallel under your choice of -free software license, such as the GNU General Public License, to -permit their use in free software. +recommend releasing these examples in parallel under your choice of free +software license, such as the GNU General Public License, to permit +their use in free software.  File: cssc.info, Node: BSD Code, Next: Glossary, Prev: GNU Free Documentation License, Up: Top @@ -4876,28 +4781,25 @@ File: cssc.info, Node: BSD Code, Next: BSD Code ******** -The program `sccs', its source code, and its accompanying -documentation are covered by the following license:- +The program 'sccs', its source code, and its accompanying documentation +are covered by the following license:- Copyright (C) 1998, 1999 - Free Software Foundation, Inc. All rights reserved. + Free Software Foundation, Inc. All rights reserved. Copyright (c) 1980, 1993 - The Regents of the University of California. All rights - reserved. + The Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - 3. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written @@ -4906,22 +4808,22 @@ documentation are covered by the followi THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A - PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS - OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR + CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED - AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT - LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN - ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE - POSSIBILITY OF SUCH DAMAGE. + USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + SUCH DAMAGE. The original version of the copyright notice above dates from 1993, as you can see. However, since that time a change has been made to the BSD license by UCB itself. This change is described on the following letter, which is available on the BSD FTP site in the file -`README.Impt.License.Change' :- +'README.Impt.License.Change' :- July 22, 1999 @@ -4949,9 +4851,8 @@ letter, which is available on the BSD FT Director, Office of Technology Licensing University of California, Berkeley - - This change has been made to the file `COPYING.bsd' which -accompanies the BSD-derived code. + This change has been made to the file 'COPYING.bsd' which accompanies +the BSD-derived code.  File: cssc.info, Node: Glossary, Next: Concept Index, Prev: BSD Code, Up: Top @@ -4971,23 +4872,25 @@ body The actual data within the version-controlled file is called the "body", though this is also sometimes used to refer to that part of the SCCS history file that contains data from the body of the - controlled file (that is, information _from_ the file as opposed - to information _about_ the file). + controlled file (that is, information _from_ the file as opposed to + information _about_ the file). branching + Multiple lines of development are called branches; a branch is created by editing a version of a file which already has a derived - version (e.g. editing version 1.2 when version 1.3 already exists). + version (e.g. editing version 1.2 when version 1.3 already + exists). checkin comment - The `delta' program asks for a checkin comment; this is a comment + The 'delta' program asks for a checkin comment; this is a comment which summarised the nature of the change which has just been made to the file. controlled file This is the (working copy of a) file which is version-controlled - with an SCCS history file (that is, a file which is managed by - SCCS or CSSC). + with an SCCS history file (that is, a file which is managed by SCCS + or CSSC). d-file *Note Filenames::. @@ -5003,8 +4906,8 @@ delta table contents of the file at that version). excluded delta - An excluded delta is one which was specified with the `-x' option - to `get'. See *note Options for `get': get options. + An excluded delta is one which was specified with the '-x' option + to 'get'. See *note Options for 'get': get options. g-file See _gotten file_. @@ -5019,37 +4922,37 @@ history file contents of a file, the file in which this historical information is recorded is called the "history file". Sometimes there are known as "s-files" or "archives" (though "archive" is more often - used in relation to the `ar' and `tar' utilities). + used in relation to the 'ar' and 'tar' utilities). ignored delta - An ignored delta is one which was specified with the `-g' option - to `delta'. *Note Options for `delta': delta options. + An ignored delta is one which was specified with the '-g' option to + 'delta'. *Note Options for 'delta': delta options. included delta - An included delta is one which was specified with the `-i' option - to `get'. See *note Options for `get': get options. + An included delta is one which was specified with the '-i' option + to 'get'. See *note Options for 'get': get options. keyword It is sometimes useful to include information in the gotten file - about what its version number is and so on. Since this - information changes with each revision of the file, it makes sense - for SCCS (or CSSC) to keep track of this information and place it - in the gotten file accordingly. If a file is checked out for - editing, placeholders can be edited into the file which; these are - later expanded when the file is checked out read-only. See *note - Keyword Substitution::. The same name is also sometimes used for - the argument following the `-d' option for `prs'. See *note Data - Keywords for the `-d' option of `prs': Data Keywords. + about what its version number is and so on. Since this information + changes with each revision of the file, it makes sense for SCCS (or + CSSC) to keep track of this information and place it in the gotten + file accordingly. If a file is checked out for editing, + placeholders can be edited into the file which; these are later + expanded when the file is checked out read-only. See *note Keyword + Substitution::. The same name is also sometimes used for the + argument following the '-d' option for 'prs'. See *note Data + Keywords for the '-d' option of 'prs': Data Keywords. level The second component of the _SID_. MR number - Modification Request numbers; if the `v' flag is set in the SCCS - file, you will be prompted for "MR numbers" when you check in a - new revision. These are not used internally by CSSC but may be - used to link changes to external things (for example bug report - numbers). *Note Options for `delta': delta options. + Modification Request numbers; if the 'v' flag is set in the SCCS + file, you will be prompted for "MR numbers" when you check in a new + revision. These are not used internally by CSSC but may be used to + link changes to external things (for example bug report numbers). + *Note Options for 'delta': delta options. p-file *Note Filenames::. @@ -5068,9 +4971,9 @@ sequence number The "sequence number" is a decimal number used within the SCCS history file to identify a particular revision (or delta) of the file. These numbers are normally not user-visible (except in the - output of `prt' and `prs'). These are sometimes referred to as a - "seqno" in order to distinguish them from the fourth component of - a SID. + output of 'prt' and 'prs'). These are sometimes referred to as a + "seqno" in order to distinguish them from the fourth component of a + SID. s-file The SCCS history file is sometimes referred to as the _s-file_. @@ -5078,20 +4981,20 @@ s-file SID Each revision of a file controlled with an SCCS history file is - identified by a "SID". This is a series of numbers separated by + identified by a "SID". This is a series of numbers separated by dots. A complete SID always has either two components (for - revisions which lie on the trunk) or four components (for - revisions that lie on a branch). Examples are 1.1, 1.2 (which - both lie on the trunk), 1.3.1.1, 1.3.1.2 (which both lie on a - branch) and 1.3.2.1 (which lies on a different branch). The four - components of the SID are, left to right, the _release_, the - _level_, the _branch_ and the _sequence number_. See also - _sequence number_, above. + revisions which lie on the trunk) or four components (for revisions + that lie on a branch). Examples are 1.1, 1.2 (which both lie on + the trunk), 1.3.1.1, 1.3.1.2 (which both lie on a branch) and + 1.3.2.1 (which lies on a different branch). The four components of + the SID are, left to right, the _release_, the _level_, the + _branch_ and the _sequence number_. See also _sequence number_, + above. trunk The trunk consists of those deltas within a history file which do not lie on branches; trunk revisions have only two components in - their SID. Normally these are the main sequence of changes to the + their SID. Normally these are the main sequence of changes to the file. x-file @@ -5117,26 +5020,26 @@ Concept Index * Authorisation: admin. (line 18) * backing out of changes: rmdel. (line 6) * Binary files: admin. (line 29) -* BitKeeper <1>: Incompatibilities. (line 14) -* BitKeeper <2>: BitKeeper. (line 6) -* BitKeeper <3>: Delta Table. (line 108) -* BitKeeper <4>: Checksum Line. (line 20) -* BitKeeper <5>: Validation Warnings. (line 31) -* BitKeeper <6>: Flags. (line 25) * BitKeeper: admin. (line 118) +* BitKeeper <1>: Flags. (line 23) +* BitKeeper <2>: Validation Warnings. (line 31) +* BitKeeper <3>: Checksum Line. (line 20) +* BitKeeper <4>: Delta Table. (line 108) +* BitKeeper <5>: BitKeeper. (line 6) +* BitKeeper <6>: Incompatibilities. (line 14) * branch number: delta. (line 10) -* Branching <1>: branches. (line 6) * Branching: Flags. (line 11) -* BSD <1>: BSD Code. (line 6) +* Branching <1>: branches. (line 6) * BSD: Overview. (line 21) +* BSD <1>: BSD Code. (line 6) * Buffer overflows: Known Problems. (line 11) * bug-fixing released code: branches. (line 6) * bugs: Problems. (line 6) * cdc: cdc. (line 6) * censoring revisions: rmdel. (line 6) * change delta commentary: cdc. (line 6) -* change summary: sccsdiff. (line 6) * Change summary: prt. (line 6) +* change summary: sccsdiff. (line 6) * changes, checking in: delta. (line 6) * checking in changes: delta. (line 6) * checking in new revisions: delta. (line 6) @@ -5146,9 +5049,9 @@ Concept Index * checksum: admin. (line 55) * comb: comb. (line 6) * comment, changing: cdc. (line 6) -* Comments about CSSC: Problems. (line 24) +* Comments about CSSC: Problems. (line 23) * committing changes: delta. (line 6) -* Concurrent editing: Flags. (line 31) +* Concurrent editing: Flags. (line 28) * Contributing test cases: Writing new test cases. (line 6) * creating SCCS files: admin. (line 6) @@ -5168,8 +5071,8 @@ Concept Index * ekko: echo_nonl. (line 6) * Emacs: Interface. (line 6) * Eric Allman: Overview. (line 21) -* Extensions <1>: The Good News. (line 12) * Extensions: CSSC Extensions. (line 6) +* Extensions <1>: The Good News. (line 12) * Failures during multiple-file processing: Missing Features. (line 12) * Flags: Flags. (line 6) * forking: branches. (line 6) @@ -5186,20 +5089,25 @@ Concept Index * interface: Interface. (line 6) * invoking: Invoking CSSC Programs. (line 6) -* Keyword Substitution <1>: Validation Warnings. (line 39) -* Keyword Substitution <2>: Keyword Substitution. +* Keyword Substitution: Flags. (line 27) +* Keyword Substitution <1>: Flags. (line 62) +* Keyword Substitution <2>: Flags. (line 67) +* Keyword Substitution <3>: Flags. (line 70) +* Keyword Substitution <4>: Flags. (line 79) +* Keyword Substitution <5>: get options. (line 59) +* Keyword Substitution <6>: get options. (line 111) +* Keyword Substitution <7>: Keyword Substitution. (line 6) -* Keyword Substitution <3>: get options. (line 60) -* Keyword Substitution: Flags. (line 30) -* Known bugs: Missing Features. (line 27) +* Keyword Substitution <8>: Validation Warnings. (line 39) +* Known bugs: Missing Features. (line 26) * level number: delta. (line 10) -* Line length <1>: Unemulated Features. (line 23) -* Line length <2>: CSSC Extensions. (line 12) +* Line length: Maximum Line Length. (line 6) +* Line length <1>: Limitations of diff. (line 6) +* Line length <2>: Configuration. (line 6) * Line length <3>: SCCS Version Differences. (line 12) -* Line length <4>: Configuration. (line 6) -* Line length <5>: Limitations of diff. (line 6) -* Line length: Maximum Line Length. (line 6) +* Line length <4>: CSSC Extensions. (line 12) +* Line length <5>: Unemulated Features. (line 23) * locking revisions for update: get. (line 6) * maintainer: Problems. (line 6) * Making branches: Flags. (line 11) @@ -5210,28 +5118,28 @@ Concept Index (line 6) * MySC: Overview. (line 21) * new versions: get. (line 6) -* obsolete releases: Flags. (line 60) +* obsolete releases: Flags. (line 52) * Oops, it didn't compile: rmdel. (line 6) * overview: Overview. (line 6) -* p-file: get options. (line 38) -* Pipes <1>: Unemulated Features. (line 9) +* p-file: get options. (line 37) * Pipes: CSSC Extensions. (line 20) +* Pipes <1>: Unemulated Features. (line 9) * problems: Problems. (line 6) * prs: prs. (line 6) * prt: prt. (line 6) -* Questions about CSSC: Problems. (line 24) +* Questions about CSSC: Problems. (line 23) * Race conditions: Known Problems. (line 13) * release number: delta. (line 10) * Restricting access to history files: admin. (line 18) * retrieving previous revisions: get. (line 6) * Reverting to where you were before you broke it: unget. (line 6) -* Revision summary: prt. (line 6) * revision summary: prs. (line 6) +* Revision summary: prt. (line 6) * rmdel: rmdel. (line 6) * Ross Ridge: Overview. (line 21) * sact: sact. (line 6) * sccs: sccs. (line 6) -* SCCS ID: what. (line 26) +* SCCS ID: what. (line 25) * sccs-admin: admin. (line 6) * sccs-cdc: cdc. (line 6) * sccs-comb: comb. (line 6) @@ -5246,30 +5154,34 @@ Concept Index * sccs-unget: unget. (line 6) * sccs-val: val. (line 6) * sccsdiff: sccsdiff. (line 6) -* SCO <1>: SCCS Version Differences. - (line 47) -* SCO <2>: Executable File Support. +* SCO: Flags. (line 37) +* SCO <1>: Executable File Support. (line 17) -* SCO: Flags. (line 44) +* SCO <2>: SCCS Version Differences. + (line 47) +* SCO <3>: SCCS Version Differences. + (line 77) * Security problems: Known Problems. (line 11) * sequence number: delta. (line 10) * Setuid execution, why not to do it: Known Problems. (line 27) * SID: delta. (line 10) -* Simultaneous editing: Flags. (line 31) -* Solaris <1>: SCCS Version Differences. - (line 23) -* Solaris <2>: Global Flags Section. +* Simultaneous editing: Flags. (line 28) +* Solaris: Flags. (line 79) +* Solaris <1>: Global Flags Section. (line 34) -* Solaris: Flags. (line 94) +* Solaris <2>: SCCS Version Differences. + (line 23) +* Solaris <3>: SCCS Version Differences. + (line 73) * success function for test scripts: success. (line 6) -* Suggestions for the improvement of CSSC: Problems. (line 24) +* Suggestions for the improvement of CSSC: Problems. (line 23) * Summary of changes to a history file: prt. (line 6) * Summary of SCCS file: prs. (line 6) * Sun Microsystems, Inc.: Year 2000 Issues. (line 13) * test suite: Testing. (line 6) * testing: Running the tests. (line 6) +* time travel: get options. (line 20) * time travel <1>: Validation Warnings. (line 21) -* time travel: get options. (line 21) * undoing revisions: rmdel. (line 6) * unget: unget. (line 6) * val: val. (line 6) @@ -5278,110 +5190,117 @@ Concept Index * VC-mode: Interface. (line 6) * Version identifiers: Keyword Substitution. (line 6) -* Warning messages: Missing Features. (line 21) +* Warning messages: Missing Features. (line 20) * what: what. (line 6) * Whodunit: prs. (line 6) * X/Open: Year 2000 Issues. (line 13) -* Year 2000 <1>: Year 2000 Issues. (line 6) -* Year 2000 <2>: prt options. (line 34) -* Year 2000 <3>: Data Keywords. (line 97) -* Year 2000 <4>: prs options. (line 11) -* Year 2000 <5>: Keyword Substitution. - (line 24) -* Year 2000: get options. (line 21) +* Year 2000: get options. (line 20) +* Year 2000 <1>: Keyword Substitution. + (line 21) +* Year 2000 <2>: Keyword Substitution. + (line 26) +* Year 2000 <3>: Keyword Substitution. + (line 33) +* Year 2000 <4>: Keyword Substitution. + (line 35) +* Year 2000 <5>: prs options. (line 11) +* Year 2000 <6>: Data Keywords. (line 96) +* Year 2000 <7>: Data Keywords. (line 135) +* Year 2000 <8>: prt options. (line 34) +* Year 2000 <9>: Year 2000 Issues. (line 6)  Tag Table: -Node: Top847 -Node: Overview2527 -Node: Interface3727 -Node: Invoking CSSC Programs4210 -Node: admin5384 -Node: Flags10827 -Node: Modification Request Numbers14623 -Node: cdc16205 -Node: comb18476 -Node: delta18762 -Node: delta usage20372 -Node: delta options21333 -Node: get23959 -Node: get usage24596 -Node: get options25539 -Node: branches30125 -Node: Keyword Substitution32365 -Node: Included Excluded and Ignored deltas34741 -Node: help37525 -Node: prs38376 -Node: prs usage39585 -Node: prs options40204 -Node: Data Keywords42811 -Node: prt48139 -Node: prt usage48814 -Node: prt options49503 -Node: prt output53286 -Node: rmdel55589 -Node: sact56824 -Node: sccs58019 -Node: sccsdiff59384 -Node: unget60700 -Node: val61555 -Node: Options for val62368 -Node: Validation Warnings63533 -Node: Return Value65860 -Node: Paranoia66883 -Node: what68877 -Node: Filenames70573 -Node: File Format72672 -Node: File Format Overview73130 -Node: The Header73918 -Node: Checksum Line74236 -Node: Delta Table75114 -Node: Authorised User List81279 -Node: Global Flags Section82102 -Node: File Description83945 -Node: Example Header84632 -Node: The Body85645 -Node: Interoperability86529 -Node: Binary File Support88004 -Node: Executable File Support88984 -Node: BitKeeper90054 -Node: Maximum Line Length90824 -Node: Limitations of diff93584 -Node: Configuration95421 -Node: Bug-for-Bug95907 -Node: Incompatibilities97797 -Node: SCCS Version Differences98779 -Node: CSSC Extensions101987 -Node: Environment105818 -Node: Child Processes106308 -Node: Configuration Variables107539 -Node: Other Variables109117 -Node: Incomplete112669 -Node: Missing Features113028 -Node: Known Problems114951 -Node: Unemulated Features118119 -Node: Year 2000 Issues120213 -Node: The Good News121980 -Node: The Bad News124247 -Node: Year 2000 Summary125206 -Node: Testing126292 -Node: Running the tests126980 -Node: Writing new test cases131177 -Node: testing tests132925 -Node: docommand134155 -Node: remove136850 -Node: success137367 -Node: fail137659 -Node: echo_nonl138189 -Node: miscarry139081 -Node: real-thing139545 -Node: need-prt140485 -Node: Problems141520 -Node: Copying142821 -Node: GNU Free Documentation License180378 -Node: BSD Code205518 -Node: Glossary209041 -Node: Concept Index214393 +Node: Top758 +Node: Overview2435 +Node: Interface3634 +Node: Invoking CSSC Programs4108 +Node: admin5282 +Node: Flags10865 +Node: Modification Request Numbers14636 +Node: cdc16218 +Node: comb18487 +Node: delta18773 +Node: delta usage20382 +Node: delta options21342 +Node: get23969 +Node: get usage24606 +Node: get options25549 +Node: branches30135 +Node: Keyword Substitution32373 +Node: Included Excluded and Ignored deltas34730 +Node: help37514 +Node: prs38366 +Node: prs usage39575 +Node: prs options40195 +Node: Data Keywords42802 +Node: prt48128 +Node: prt usage48803 +Node: prt options49492 +Node: prt output53274 +Node: rmdel55498 +Node: sact56733 +Node: sccs57927 +Node: sccsdiff59292 +Node: unget60607 +Node: val61460 +Node: Options for val62273 +Node: Validation Warnings63438 +Node: Return Value65764 +Node: Paranoia66787 +Node: what68780 +Node: Filenames70475 +Node: File Format72562 +Node: File Format Overview73020 +Node: The Header73808 +Node: Checksum Line74126 +Node: Delta Table75003 +Node: Authorised User List81167 +Node: Global Flags Section81989 +Node: File Description83832 +Node: Example Header84519 +Node: The Body85532 +Node: Interoperability86417 +Node: Binary File Support87891 +Node: Executable File Support88871 +Node: BitKeeper89941 +Node: Maximum Line Length90706 +Node: Limitations of diff93466 +Node: Configuration95304 +Node: Bug-for-Bug95790 +Node: Incompatibilities97680 +Node: SCCS Version Differences98662 +Node: CSSC Extensions101865 +Node: Environment105690 +Node: Child Processes106180 +Node: Configuration Variables107410 +Node: Other Variables108986 +Node: Incomplete112537 +Node: Missing Features112896 +Node: Known Problems114816 +Node: Unemulated Features117981 +Node: Year 2000 Issues120067 +Node: The Good News121835 +Node: The Bad News124103 +Node: Year 2000 Summary125062 +Node: Testing126147 +Node: Running the tests126834 +Node: Writing new test cases131028 +Node: testing tests132777 +Node: docommand134006 +Node: remove136701 +Node: success137218 +Node: fail137509 +Node: echo_nonl138039 +Node: miscarry138931 +Node: real-thing139395 +Node: need-prt140335 +Node: Problems141369 +Node: Copying142669 +Node: GNU Free Documentation License180207 +Node: BSD Code205327 +Node: Glossary208838 +Node: Concept Index214194  End Tag Table debian/patches/series0000644000000000000000000000014712212711517012033 0ustar 01-groff.diff 02-gl-lib-gets 03-sys-types 04-fix-texinfo 99-info-update 05-unistd 06-gtest-death-tests debian/patches/03-sys-types0000644000000000000000000000263112204501511012731 0ustar Description: TODO: Put a short summary on the line above and replace this paragraph with a longer explanation of this change. Complete the meta-information with other relevant fields (see below for details). To make it easier, the information below has been extracted from the changelog. Adjust it or drop it. . cssc (1.3.0-1) unstable; urgency=low . * New upstream release. * Switched to source format "3.0 (quilt)". * Switched to debhelper 9. * Fix src/file.h not including sys/types.h before using git_t. * Hack gl/lib/stdio.h not to cause build failure on "gets" token. Author: Yann Dirson --- The information above should follow the Patch Tagging Guidelines, please checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here are templates for supplementary fields that you might want to add: Origin: , Bug: Bug-Debian: http://bugs.debian.org/ Bug-Ubuntu: https://launchpad.net/bugs/ Forwarded: Reviewed-By: Last-Update: --- cssc-1.3.0.orig/src/file.h +++ cssc-1.3.0/src/file.h @@ -31,6 +31,7 @@ #define CSSC__FILE_H__ #include "filelock.h" +#include enum create_mode { CREATE_EXCLUSIVE = 001,