Suffix interpretation of directories no longer needed

[Home] [Back]
[No frames]

The original problem

In RCS for RiscOS v5.7.1.2, a lot of trouble was taken to let the system recognize the 'extension' of a workfile. This was needed because of the $Log$ keyword. When it expands, it will write extra lines in the workfile. These lines must be prefixed with a string which indicates that the line is a comment in that particular language.

To recognize the language, RCS on Unix reads the file extension. So a file main.c would be a C source file, loop.s would be an assembler source file, etc.

File extensions on RiscOS are, for historical reasons, handled in a very different way. A directory is used to indicate the kind of source file. So a file on Unix called hop/main.c is called hop.c.main on RiscOS.

In order to be able to recognize this extension directory on RiscOS, the file names on the command line must include the directory. A side-effect is that the RCS directory where the RCS file is searched will be one directory up. Internally the translation goes:
Command line: ci -Z hop.c.main
Translated to Unix style by roname(): hop/main.c
Corresponding RCS file: hop/RCS/main.c
Translated to RiscOS style by UnixLib: hop.RCS.c.main
roname() is a routine I wrote specially for programs ported using UnixLib. It is designed to do the reverse of the filename translation that UnixLib does. UnixLib will translate Unix-style filenames in a program to RiscOS-style names which are passed to the operating system. roname() accepts RiscOS-style filenames and translates them into Unix-style names for internal use in the program. The -Z option of the commands controls whether roname() is called or not.

The new situation

After the release of RCS for RiscOS v5.7.1.2 it was discovered that GNU RCS v5.7 no longer needs the file extension to determine the prefix for the expansion of the $Log$ keyword. It simply copies the string that precedes the keyword itself. Makes sense when you think about it.

For backwards compatibility they still maintain the comment field in the RCS file in the old way. This field is however no longer used in the actual expansion.

A description of this change, along with many others, can be found in the NEWS file supplied with the GNU sources.

What does this mean for you?

It is no longer needed to keep the RCS files one level up for those source files that have an extension-like directory.

To change the behaviour of the current issue of RCS for RiscOS (v5.7.1.2), set the environment variable UnixFS$sfix to an empty string. 

*Set UnixFS$sfix ""
A good place to do this is in the RCSstart file.

Caveat

Setting the environment variable will also influence the behaviour of other programs compiled using UnixLib.

The future

Future versions of RCS for RiscOS will by default ignore the extension-type directories and search the RCS file in an RCS directory which is on the same level as the workfile for all kinds of files. Backwards compatibility will be controlled by an environment variable (something like RCS$sfix)
For questions, remarks, suggestions, comments etc. see the contacts page
[Home] [Back]
File identification: 
$Id: suffixes.html 1.3 2003/11/26 17:56:09 erikgrnh Exp $