| Previous | Contents | Index |
The following example and explanation shows how to use the HP C RTL time functions to print the current time:
#include <stdio.h>
#include <time.h>
main ()
{
time_t t;
t = time((time_t)0);
printf ("The current time is: %s\n",asctime (localtime (&t)));
}
|
This example:
OpenVMS Version 8.3 and higher provides Open Group compliant symbolic link support and POSIX pathname processing support. This support will help partners and customers who port UNIX and LINUX applications to OpenVMS or who use a UNIX style development environment to reduce the application development costs and complexity previously associated with such porting efforts.
Although this support is present, it does not guarantee 100% compatibility of UNIX files on OpenVMS systems. There may be some cases where developers still need to make modifications to UNIX or LINUX applications when porting them to OpenVMS.
The following OpenVMS features are provided to support symbolic links and POSIX pathname processing:
A POSIX pathname is a non-empty character string consisting of 0 or more filenames, separated by a / (the path delimiter). The path delimiter can be the first or last character of a pathname and is also the separator between filenames. Multiple consecutive delimiters are valid and are equivalent to a single delimiter (except in the reserved special case of a pathname beginning with exactly two delimiters).
POSIX filenames can consist of all ASCII characters except
/
(the path delimiter) and NUL, which is used as a string terminator in
many APIs. (On OpenVMS systems, POSIX filenames are also currently
restricted to not contain the
?
or
*
character.) A filename is sometimes referred to as a pathname
component.
12.1.1 POSIX Pathname Interpretation
If the pathname begins with a / , it is considered to be an absolute pathname, and pathname processing begins at the device and directory specified by the POSIX root (see Section 12.5 for the method to define the root).
If the pathname does not begin with a / , it is considered to be a relative pathname, and pathname processing begins with the current directory.
See Section 12.6 for how OpenVMS interprets the current directory.
12.1.1.1 The POSIX Root Directory
The POSIX root directory is a directory that is used in pathname resolution for absolute pathnames.
The root directory, is the top-most node of the hierarchy, and has itself as its parent directory. The pathname of the root directory is / , and the parent directory of the root directory is / .
See Section 12.5 for defining the POSIX root on OpenVMS.
12.1.1.2 Symbolic Links
A symbolic link is a special kind of file that points to another file. It is a directory entry that associates a filename with a text string that is interpreted as a POSIX pathname when accessed by certain services. Most operations that access a symbolic link are rerouted to the object to which the text contents refer; if that object does not exist, the operation fails. A symbolic link is implemented on OpenVMS as a file of organization SPECIAL and type SYMBOLIC_LINK.
A symbolic link can specify an absolute pathname or a relative pathname. The relative path in a symbolic link is relative to the location of the link. For example, a symbolic link whose content begins with the path " .. " refers to its parent directory. If the symbolic link is moved to another directory, it refers to its new parent directory.
See Section 12.2 for symbolic link usage on OpenVMS.
12.1.1.3 Mount Points
A mount point is a location (in fact, a directory) where a file system is attached. The UNIX term file system is essentially equivalent to the OpenVMS concept of a disk volume. After a mount point is established, any contents of the original directory are inaccessible.
Mount points do not persist across reboots.
See Section 12.7 for establishing mount points on OpenVMS.
12.1.1.4 Reserved Filenames . and ..
There are two reserved POSIX filenames:
. (the current directory)
.. (the parent directory)
On UNIX systems, a special file is associated with a particular hardware device or other resource of the computer system. The operating system uses character special files, sometimes called device files, to provide I/O access to specific character devices.
Special files, at first glance, appear to be just like ordinary files, in that they:
However, there is an important difference between the two: an ordinary file is a logical grouping of data recorded on disk, whereas a special file corresponds to a device entity. Examples are:
Only the null special file (
/dev/null
) is supported. This file is created during the GNV configuration
procedure. Data written on the null special file is discarded. Reads
from a null special file always return 0 bytes.
12.1.2 Using POSIX Pathnames with OpenVMS Interfaces
POSIX compliant pathnames can be passed to most OpenVMS applications, utilities, and APIs.
The existing DCL convention of doubling any quote character that is in a quoted string has been adopted.
Also, in order to avoid constraints on future use of quoted strings for pathnames (for example, to support another syntactic variation, such as Windows-compatible names), the leading tag ^UP^ is required on the quoted pathname to identify it as a POSIX pathname.
So, for example, /a/b/c becomes "^UP^/a/b/c" and /a/b"/c becomes "^UP^/a/b""/c" .
Throughout the remainder of this chapter, the term POSIX
pathname refers to the unmodified pathname (for example,
/a/b/c
) and quoted pathname refers to our quoted, tagged pathname
(for example,
"^UP^/a/b/c"
).
12.1.2.1 Special Considerations with POSIX Filenames
When a user creates a file on OpenVMS using a POSIX filename, it would be ideal if the filename viewed as an OpenVMS filename were the same. For example, when a user asks to create a file with POSIX filename a.b , OpenVMS could create a file with the name a.b; (where ; represents the file version).
But because one of the components of an OpenVMS filename is the file type (consisting of at least a period), POSIX filenames without a period cannot be mapped in as direct a fashion (for example, POSIX filename a cannot be mapped to OpenVMS filename a; ). The reasonable solution is for OpenVMS to append a period (representing a null file-type field) so that POSIX filename a becomes OpenVMS filename a.;
Note that OpenVMS appends a period (or null type) even to a POSIX filename that itself ends in a period. This is necessary to distinguish POSIX filenames a. and a from each other.
Furthermore, OpenVMS directories have a type and version of .DIR;1 . When a directory of POSIX filename a is created on OpenVMS, it is created with an OpenVMS filename of a.DIR;1 . And because a.DIR is a valid POSIX filename, it needs to be distinguished from a directory with POSIX filename a residing in the same directory. So OpenVMS adds a period (or null type) to POSIX filenames ending in .DIR (so a file with POSIX filename a.DIR becomes a.DIR.; ).
Keeping the above rules in mind, the following are POSIX filenames that are unmodified on OpenVMS, except for adding a version:
POSIX filename OpenVMS name Type Version Displayed by DIR as
-------------- ------------ ---- ------- -------------------
a.b a .b ; a.b;
a.b; a .b; ; a.b;;
a.b;2 a .b;2 ; a.b;2;
|
The following are examples of POSIX filenames that end with a period (.) or .DIR and, therefore, have a period appended when creating the OpenVMS filename:
POSIX filename OpenVMS name Type Version Displayed by DIR as
-------------- ------------ ---- ------- -------------------
a a . ; a.;
a. a. . ; a^..;
a.. a.. . ; a^.^..;
a.b. a.b. . ; a^.b^..;
a.DIR a.DIR . ; a^.DIR.;
|
Finally, OpenVMS will add .DIR;1 to the end of any POSIX directory:
POSIX filename OpenVMS name Type Version Displayed by DIR as
-------------- ------------ ---- ------- -------------------
a a .DIR ;1 a.DIR;1
a.dir a.dir .DIR ;1 a^.dir.DIR;1
a. a. .DIR ;1 a^..DIR;1
|
All POSIX filenames that contain the
*
or
?
characters are unmappable. This is an open issue to be addressed in a
future release of OpenVMS.
12.1.2.2 Special Considerations with OpenVMS Filenames
When mapping OpenVMS filenames to POSIX filenames (a feature provided by C RTL function readdir ), the following rules apply:
If the OpenVMS filename ends in .DIR;1 and the type of a file is a directory, then .DIR;1 is removed. For all other files, the ending semi-colon and version number are removed from the OpenVMS filename.
If the OpenVMS filename ends in a period, the period is removed.
All OpenVMS filenames that contain the / or NUL characters are unmappable and, therefore, not returned to the caller.
OpenVMS directories ..DIR;1 and ...DIR;1 are unmappable because their corresponding POSIX filenames would be the special filenames . and .. .
OpenVMS file
.
is unmappable because the resulting POSIX filename would be a NULL
string.
12.2 Using Symbolic Links
There are several ways to create a symbolic link:
The following examples show how to create and access symbolic links using DCL commands:
| #1 |
|---|
$ create/symlink="a/b.txt" link_to_b.txt
$
$ dir/date link_to_b.txt
Directory DKB0:[TEST]
link_to_b.txt -> a/b.txt
27-MAY-2005 09:45:15.20
|
This example creates the symbolic link file link_to_b.txt with contents equal to the specified text string representing the pathname to which the symbolic link points, a/b.txt . Note that a/b.txt may or may not exist.
| #2 |
|---|
$ type link_to_b.txt
%TYPE-W-OPENIN, error opening DKB0:[TEST]LINK_TO_B.TXT; as input
-RMS-E-FNF, file not found
|
To access the file referenced in a symbolic link, specify the symbolic link name on the command. The TYPE command error message in this example indicates that the file a/b.txt , referenced through the symbolic link link_to_b.txt created in the first example, does not exist.
| #3 |
|---|
$ create link_to_b.txt
This is a text file.
Exit
$ dir [.a]
Directory DKB0:[TEST.A]
b.txt;1
$
$ type link_to_b.txt
This is a text file.
$
|
This example creates the missing file b.txt through the link, assuming subdirectory [.a] exists. If [.a] does not exist, you must create it first; the above CREATE command will create only the file, not any subdirectories specified in the pathname.
Alternatively, you can create the file in the standard way, without using the link:
$ create [.a]b.txt This is a text file. Exit $Once the referenced file exists, the TYPE command through the symbolic link is successful.
You can create a symbolic link within the GNV bash shell with the ln utility:
bash$ ln -s filename slinkname |
Most utilities and commands that reference slinkname are redirected so that they act on filename. Some commands, such as ls , are symbolic link-aware, and show information about the link itself (such as its contents).
A link can be removed with the rm command (which cannot be made to follow the link and remove what it points to).
The examples that follow show how to manage symbolic links through GNV POSIX commands as compared with DCL commands.
| #1 |
|---|
From GNV:
bash$ cd /symlink_example
bash$ echo This is a test. > text
bash$ cat text
This is a test.
bash$ ln -s text LINKTOTEXT
bash$
From DCL:
$ set def DISK$XALR:[PSX$ROOT.symlink_example]
$ create text.
This is a test.
Exit
$ type text.
This is a test.
$ create/symlink="text" LINKTOTEXT
|
This example creates a symbolic link called LINKTOTEXT that points to a text file called text .
| #2 |
|---|
From GNV:
bash$ cat LINKTOTEXT
This is a test.
bash$
From DCL:
$ type LINKTOTEXT.
This is a test.
$
|
This example displays the contents of the text file using the symbolic link.
| #3 |
|---|
From GNV:
bash$ ls
LINKTOTEXT text
bash$ ls -l
total 1
lrwxr-x--- 1 SYSTEM 1 4 May 12 08:41 LINKTOTEXT -> text
-rw-r----- 1 SYSTEM 1 16 May 12 08:40 text
bash$
From DCL:
$ DIR
Directory DISK$XALR:[PSX$ROOT.symlink_example]
LINKTOTEXT.;1 text.;1
Total of 2 files.
$ DIR/DATE
Directory DISK$XALR:[PSX$ROOT.symlink_example]
LINKTOTEXT.;1 -> /symlink_example/text
12-MAY-2005 08:46:31.40
text.;1 12-MAY-2005 08:43:47.53
Total of 2 files.
$
|
This example displays the content of a symbolic link. Notice that when you do an ls or a DIR using switches that show any file attribute, then the content of the symbolic link is also displayed.
| #4 |
|---|
From GNV:
bash$ rm text
bash$ cat LINKTOTEXT
cat: linktotext: i/o error
bash$ rm LINKTOTEXT
From DCL:
$ DEL text.;1
$ TYPE LINKTOTEXT.
%TYPE-W-OPENIN, error opening DISK$XALR:[PSX$ROOT.symlink_example]LINKTOTEXT.;1
as input
-RMS-E-ACC, ACP file access failed
-SYSTEM-F-FILNOTACC, file not accessed on channel
$ DEL LINKTOTEXT.;1
$
|
This example deletes files.
The following sections describe POSIX-compliant pathname and symbolic
link support in the C RTL.
12.3.1 DECC$POSIX_COMPLIANT_PATHNAMES Feature Logical
In order for a POSIX-compliant user to have consistency between the pathnames stored in symbolic links and the pathnames used as input to C RTL functions, the C RTL provides a feature logical, DECC$POSIX_COMPLIANT_PATHNAMES, to allow an application to present POSIX-compliant pathnames to any C RTL function that accepts a pathname.
By default DECC$POSIX_COMPLIANT_PATHNAMES is disabled, and the usual C RTL behavior prevails. Notice that this disabled mode includes interpretation of pathnames as UNIX style specifications and uses rules that are different and unrelated to POSIX-compliant pathname processing.
To disable DECC$POSIX_COMPLIANT_PATHNAMES when necessary, DEFINE it to 0 or "DISABLE":
$ DEFINE DECC$POSIX_COMPLIANT_PATHNAMES 0 |
To enable DECC$POSIX_COMPLIANT_PATHNAMES, set it to one of the following values:
| 1 | All pathnames are designated as POSIX style. |
| 2 | Pathnames that end in " : " or contain any of the bracket characters " []<> ", and that can be successfully parsed by the SYS$FILESCAN service, are designated as OpenVMS style. Otherwise, they are designated as POSIX style. |
| 3 | The pathnames " . " and " .. ", or pathnames that contain " / " are designated as POSIX style. Otherwise, they are designated as OpenVMS style. |
| 4 | All pathnames are designated as OpenVMS style. |
With DECC$POSIX_COMPLIANT_PATHNAMES thus enabled, the C RTL examines pathnames to determine if they should be designated as POSIX style or OpenVMS style, following rules determined by the value assigned to DECC$POSIX_COMPLIANT_PATHNAMES.
For example, to designate all pathnames as POSIX-compliant:
$ DEFINE DECC$POSIX_COMPLIANT_PATHNAMES 1 |
When the C RTL designates a pathname as POSIX style, it does not convert a POSIX pathname it receives into an OpenVMS file specification; instead, it converts the POSIX pathname into the quoted pathname format (previously described) and allows RMS to process the pathname as it would process a pathname found in a symbolic link.
Under OpenVMS, the C RTL has historically provided additional functionality to UNIX programs: if a filename (or pathname) was given with an initial slash (/), and the C RTL could not find the named file under the root, it would attempt to translate the name immediately following the slash as a logical name or a device name. For example, the filename /SYS$COMMON/SYSEXE/DCL.EXE refers to DCL.EXE in SYS$COMMON:[SYSEXE]. Another example: /$1$DKA500 refers to the device $1$DKA500:. With DECC$POSIX_COMPLIANT_PATHNAMES defined, the C RTL no longer does this, because these are not POSIX names. Some older OpenVMS applications may depend on this older format. If you run such applications, you may want to place either symbolic links or mount points under the root to allow such filenames to continue to work. |
When DECC$POSIX_COMPLIANT_PATHNAMES is defined, the following C RTL feature logicals are ignored:
DECC$ARGV_PARSE_STYLE
DECC$DISABLE_POSIX_ROOT
DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION
DECC$EFS_CASE_PRESERVE
DECC$EFS_CASE_SPECIAL
DECC$EFS_CHARSET
DECC$EFS_NO_DOTS_IN_DIRNAME
DECC$ENABLE_TO_VMS_LOGNAME_CACHE
DECC$FILENAME_UNIX_NO_VERSION
DECC$FILENAME_UNIX_ONLY
DECC$FILENAME_UNIX_REPORT
DECC$NO_ROOTED_SEARCH_LISTS
DECC$READDIR_DROPDOTNOTYPE
DECC$READDIR_KEEPDOTDIR
DECC$RENAME_ALLOW_DIR
DECC$RENAME_NO_INHERIT
DECC$UNIX_PATH_BEFORE_LOGNAME
| Previous | Next | Contents | Index |