;;; -*- Mode:gate; Fonts:(HL12 HL12I HL12B CPTFONTB HL12BI HL12B HL12I ) -*- =Node: 4Pathname Operations* =Text: 3PATHNAME OPERATIONS* This section documents the operations a user may send to a pathname object. Pathnames handle some additional operations that are only intended to be sent by the file system itself, and therefore are not documented here. Someone who wants to add a new host to the system would need to understand those internal operations. The operations on pathnames that actually operate on files are documented in 4(FILEACCESS-2)Pathname Operations That Access Files*. Certain pathname flavors, for specific kinds of hosts, allow additional special purpose operations. These are documented in 4(FILENAMES-3)Host File Systems Supported* in the section on the specific host type. 3:generic-pathname* 1Operation on 2pathname** Returns the generic pathname for the family of files of which this pathname is a member. See 4(FILENAMES-2)Generic Pathnames* for documentation on generic pathnames. 3:source-pathname* 1Operation on 2pathname** Returns the pathname for the source file in the family of files to which this pathname belongs. The returned pathname has 2:newest* as its version. If the file has been loaded in some fashion into the Lisp environment, then the pathname type is that which the user actually used. Otherwise, the conventional file type for source files is determined from the generic pathname. 3:primary-device* 1Operation on 2pathname** Returns the default device name for the pathname's host. This is used in generating the initial default pathname for a host. Operations dealing with wildcards. The character 3** in a namestring is a 1wildcard*. It means that the pathname is a really a pattern which specifies a set of possible filenames rather than a single filename. The matches any sequence of characters within a single component of the name. Thus, the component 2FOO** would match 2FOO*, 2FOOBAR*, 2FOOT*, or any other component starting with 2FOO*. Any component of a pathname can contain wildcards except the host; wild hosts are not allowed because a known host is required in order to know what flavor the pathname should be. If a pathname component is written in the namestring as just 3**, the actual component of the pathname instance is the keyword 2:wild*. Components which contain wildcards but are not simply a single wildcard are represented in ways subject to change. Pathnames whose components contain wildcards are called 1wild* pathnames. Wild pathnames useful in functions such as 2delete-file* for requesting the deletion of many files at once. Less obviously but more fundamentally, wild pathnames are required for most use of the function 2fs:directory-list*; an entire directory's contents are obtained by specifying a pathname whose name, type and version components are 2:wild*. 3:wild-p* 1Operation on 2pathname** Returns non-2nil* if this pathname contains any sort of wildcards. If the value is not 2nil*, it is a keyword, one of 2device*, 2:directory*, 2:name*, 2:type* and 2:version*, and it identifies the `first' component which is wild. 3:device-wild-p* 1Operation on 2pathname** 2t* if this pathname's device contains any sort of wildcards. 3:directory-wild-p* 1Operation on 2pathname** 3:name-wild-p* 1Operation on 2pathname** 3:type-wild-p* 1Operation on 2pathname** 3:version-wild-p* 1Operation on 2pathname** Similar, for the other components that can be wild. (The host cannot ever be wild.) 3:pathname-match* 1candidate-pathname* &optional 1(match-host-p* 1t)* 1Operation on 2pathname** Returns 2t* if 2candidate-pathname* matches the pathname on which the operation is invoked (called, in this context, the 1pattern pathname*). If the pattern pathname contains no wildcards, the pathnames match only if they are identical. This operation is intended in cases where wildcards are expected. Wildcard matching is done individually by component; the operation returns 2t* only if each component matches. Within each component, an occurrencs of 3** in pattern pathname's component can match any sequence of characters in 1candidate-pathname*'s component. Other characters, except for host-specific wildcards, must match exactly. 2:wild* as a component of the pattern pathname matches any component that 1candidate-pathname* may have. Note that if a component of the pattern pathname is 2nil*, 1candidate-pathname*'s component must be 2nil* also to match it. Most user programs that read pathnames and use them as patterns default unspecified components to 2:wild* first. Examples: 3(defvar pattern)* 3(defun test (str)* 3 (send pattern* 3 :pathname-match* 3 (parse-namestring str)))* 3(setq pattern* 3 (parse-namestring "OZ:*:*.TEXT.*"))* 3(test "OZ:A.TEXT") => t* 3(test "OZ:HAHA.TEXT.3") => t* 3(test "OZ:HAHA.TEXT.*") => t* 3(test "OZ:LOSE.TEXT") => nil* 3(setq pattern* 3 (parse-namestring "OZ:*:<*>A.TEXT*.5"))* 3(test "OZ:A.TEXT.5") => t* 3(test "OZ:A.TEXTTTT.5") => t* 3(test "OZ:A.TEXT") => nil* If 1match-host-p* is 2nil*, then the host components of the two pathnames are not tested. The result then depends only on the other components. 3:translate-wild-pathname* 1target-pattern* 1starting-data* &optional 1reversibleOperation on 2pathname** Returns a pathname corresponding to 1starting-data* under the mapping defined by the wild pathnames 1source-pattern*, which is the pathname this operation is invoked on, and 1target-pattern*, the argument. It is expected that 1starting-data* would match the source pattern under the 2:pathname-match* operation. 2:translate-wild-pathname* is used by functions such as 2copy-file* which use one wild pathname to specify a set of files and a second wild pathname to specify a corresponding filename for each file in the set. The first wild pathname would be used as the source-pattern and the second, specifying the name to copy each file to, would be passed as the 1target-pattern* pathname. Each component of the result is computed individually from the corresponding components of 1starting-data* and the pattern pathnames, using the following rules: 21)* If 1target-pattern*'s component is 2;wild*, then the result component is taken from 1starting-data*. 22)* Otherwise, each non-wild character in 1target-pattern*'s component is taken literally into the result. Each wild character in 1target-pattern*'s component is paired with a wild character in 1source-pattern*'s component, and thereby with the portion of 1starting-data*'s component which that matched. This portion of 1starting-data* appears in the result in place of the wild target character. Example: 3(setq source (fs:parse-pathname "OZ:PS:A*B*.*.*"))* 3(setq target (fs:parse-pathname "OZ:SS:<*>*LOSE*.*B.*"))* 3(send source :translate-wild-pathname target* 3 (fs:parse-pathname "OZ:PS:ALIBI.LISP.3"))* 3 => 1the pathname *OZ:SS:LILOSEI.LISPB.3* It is easiest to understand the mapping as being done in interchange case: the interchange components of the arguments are used and the results specify the interchange components of the value. The type component is slightly special; if the 1target-pattern* type is 2:wild*, the canonical type of 1starting-data* is taken and then interpreted according to the mappings of the target host. Example: 3(setq source (fs:parse-pathname "OZ:PS:A*.*.*"))* 3(setq target (fs:parse-pathname "U://usr//foo//b*.*"))* 3(send source :translate-wild-pathname target* 3 (fs:parse-pathname "OZ:PS:ALL.LISP"))* 3 => 1the pathname *U:/usr/foo/bll.l* If 1reversible* is non-2nil*, rule 1 is not used; rule 2 controls all mapping. This mode is used by logical pathname translation. It makes a difference when the target pattern component is 2:wild* and the source pattern component contains wildcards but is not simply 2:wild*. For example, with source and target pattern components 2BIG3*** and 3**, and starting data 2BIGGER*, the result is ordinarily 2BIGGER* by rule 1, but with reversible translation the result is 2GER*. Operations to get a path name string out of a pathname object: 3:string-for-printing* 1Operation on 2pathname** Returns a string that is the printed representation of the path name. This is the same as what you get if you 2princ* the pathname or take 2string* of it. 3:string-for-wholine* 1length* 1Operation on 2pathname** Returns a string like the 2:string-for-printing*, but designed to fit in 1length* characters. 1length* is a suggestion; the actual returned string may be shorter or longer than that. However, the who-line updater truncates the value to that length if it is longer. 3:string-for-editor* 1Operation on 2pathname** Returns a string that is the pathname with its components rearranged so that the name is first. The editor uses this form to name its buffers. 3:string-for-dired* 1Operation on 2pathname** Returns a string to be used by the directory editor. The string contains only the name, type, and version. 3:string-for-directory* 1Operation on 2pathname** Returns a string that contains only the device and directory of the pathname. It identifies one directory among all directories on the host. 3:string-for-host* 1Operation on 2pathname** Returns a string that is the pathname the way the host file system likes to see it. Operations to move around through a hierarchy of directories: 3:pathname-as-directory* 1Operation on 2pathname** Assuming that the file described by the pathname is a directory, return another pathname specifying that 1as* a directory. Thus, if sent to a pathname 2OZ:FOO.DIRECTORY*, it would return the pathname 2OZ:*. The name, type and version of the returned pathname are 2:unspecific*. 3:directory-pathname-as-file* 1Operation on 2pathname** This is the inverse of the preceding operation. It returns a pathname specifying as a file the directory of the original pathname. The name, type and version of the original pathname are ignored. The special symbol 2:root* can be used as the directory component of a pathname on file systems that have a root directory. Operations to manipulate the property list of a pathname: 3:get* 1property-name* &optional 1default-value* 1Operation on 2pathname** 3:getl* 1list-of-property-names* 1Operation on 2pathname** 3:putprop* 1value* 1property-name* 1Operation on 2pathname** 3:remprop* 1property-name* 1Operation on 2pathname** 3:plist* 1Operation on 2pathname** These manipulate the pathname's property list, and are used if you call the property list functions of the same names (see 4(MANLISTSTR-2)Property Lists*) giving the pathname as the first argument. Please read the paragraph on 4(FILENAMES-1)Pathnames* explaining the care you must take in using property lists of pathnames. =Node: 4Host File Systems Supported* =Text: 3HOST FILE SYSTEMS SUPPORTED* This section lists the host file systems supported, gives an example of the pathname syntax for each system, and discusses any special idiosyncracies. More host types may be added in the future. =Node: 4ITS* =Text: 3ITS* An ITS pathname looks like 2"1host*: 1device*: 1dir*; 1name* 1type-or-version*"*. The primary device is 2DSK:* but other devices such as 2ML:*, 2ARC:*, 2DVR:*, or 2PTR:* may be used. ITS does not exactly fit the virtual file system model, in that a file name has two components (FN1 and FN2) rather than three (name, type, and version). Consequently to map any virtual pathname into an ITS filename, it is necessary to decide whether the FN2 is the type or the version. The rule is that usually the type goes in the FN2 and the version is ignored; however, certain types (2LISP* and 2TEXT*) are ignored and instead the version goes in the FN2. Also if the type is 2:unspecific* the FN2 is the version. Given an ITS filename, it is converted into a pathname by making the FN2 the version if it is `<', `>', or a number. Otherwise the FN2 becomes the type. ITS pathnames allow the special version symbols 2:oldest* and 2:newest*, which correspond to `<' and `>' respectively. In every ITS pathname either the version or the type is 2:unspecific* or 2nil*; sometimes both are. When you create a new ITS pathname, if you specify only the version or only the type, the one not specified becomes 2:unspecific*. If both are specified, the version is 2:unspecific* unless the type is a normally-ignored type (such as 2LISP*) in which case the version is 2:newest* and the type is 2:unspecific* so that numeric FN2's are found. Each component of an ITS pathname is mapped to upper case and truncated to six characters. Special characters (space, colon, and semicolon) in a component of an ITS pathname can be quoted by prefixing them with right horseshoe () or equivalence sign (3*). Right horseshoe is the same character code in the Lisp Machine character set as control-Q in the ITS character set. An ITS pathname can have a structured name, which is a list of two strings, the FN1 and the FN2. In this case there is neither a type nor a version. An ITS pathname with an FN2 but no FN1 (i.e. a type and/or version but no name) is represented with the placeholder FN1 `3*', because ITS pathname syntax provides no way to write an FN2 without an FN1 before it. The ITS init file naming convention is 2"1homedir*; 1user* 1program*"*. 3fs:*its-uninteresting-types** 1Variable* The ITS file system does not have separate file types and version numbers; both components are stored in the ``FN2''. This variable is a list of the file types that are ``not important''; files with these types use the FN2 for a version number. Files with other types use the FN2 for the type and do not have a version number. The initial list is 3("LISP" "TEXT" nil :unspecific)* Some users may need to add to this list. 3:fn1* 1Operation on 2its-pathname** 3:fn2* 1Operation on 2its-pathname** These two operations return a string that is the FN1 or FN2 host-dependent component of the pathname. 3:type-and-version* 1Operation on 2pathname** 3:new-type-and-version* 1new-type* 1new-version* 1Operation on 2pathname** These two operations provide a way of pretending that ITS pathnames can have both a type and a version. They use the first three characters of the FN2 to store a type and the last three to store a version number. On an ITS-pathname, 2:type-and-version* returns the type and version thus extracted (not the same as the type and version of the pathname). 2:new-type-and-version* returns a new pathname constructed from the specified new type and new version. On any other type of pathname, these operations simply return or set both the type component and the version component. =Node: 4TOPS-20 [Twenex], Tenex, and VMS* =Text: 3TOPS-20 [TWENEX], TENEX, AND VMS* A pathname on TOPS-20 (better known as Twenex) looks like 1host3:*device3:<*directory3>*name3.*type3.*version* The primary device is 2PS:*. TOPS-20 pathnames are mapped to upper case. Special characters (including lower-case letters) are quoted with the circle-cross (3*) character, which has the same character code in the Lisp Machine character set as Control-V, the standard Twenex quoting character, in the ASCII character set. If you specify a period after the name, but nothing after that, then the type is 2:unspecific*, which translates into an empty extension on the TOPS-20 system. If you omit the period, you have allowed the type to be defaulted. TOPS-20 pathnames allow the special version symbols 2:oldest* and 2:newest*. In the string form of a pathname, these are expressed as `2.-2*', and as an omitted version. The directory component of a TOPS-20 pathname may be structured. The directory 2* is represented as the list 2("FOO" "BAR")*. The characters 2** and 2%* are wildcards that match any sequence of characters and any single character (within one pathname component), respectively. To specify a filename that actually contains a 2** or 2%* character, quote the character with 2*. When a component is specified with just a single 2**, the symbol 2:wild* appears in the pathname object. The TOPS-20 init file naming convention is 2"<1user*>1program*.INIT"*. When there is an attempt to display a TOPS-20 file name in the who-line and there isn't enough room to show the entire name, the name is truncated and followed by a center-dot character to indicate that there is more to the name than can be displayed. Tenex pathnames are almost the same as TOPS-20 pathnames, except that the version is preceeded by a semi-colon instead of a period, the default device is 2DSK* instead of 2PS*, and the quoting requirements are slightly different. VMS pathnames are basically like TOPS-20 pathnames, with a few complexities. The primary device is 2USRD$*. First of all, only alphanumeric characters are allowed in filenames (though 2$* and underscore can appear in device names). Secondly, a version number is preceded by `2;*' rather than by `2.*'. Thirdly, file types (called ``extensions'' in VMS terminology) are limited to three characters. Each of the system's canonical types has a special mapping for VMS pathnames, which is three characters long: 3:lisp  LSP :text  TXT :qfasl  QFS :midas  MID* 3:press  PRS :widths  WID :patch-directory  PDR* 3:qwabl  QWB :babyl  BAB :mail  MAI :xmail  XML* 3:init  INI :unfasl  UNF :output  OUT* =Node: 4TOPS-20 (Twenex), Tenex, and VMS* =Text: 3TOPS-20 (TWENEX), TENEX, AND VMS* A pathname on TOPS-20 (better known as Twenex) looks like 1host3:*device3:<*directory3>*name3.*type3.*version* The primary device is 2PS:*. TOPS-20 pathnames are mapped to upper case. Special characters (including lower-case letters) are quoted with the circle-cross (3*) character, which has the same character code in the Lisp Machine character set as Control-V, the standard Twenex quoting character, in the ASCII character set. If you specify a period after the name, but nothing after that, then the type is 2:unspecific*, which translates into an empty extension on the TOPS-20 system. If you omit the period, you have allowed the type to be defaulted. TOPS-20 pathnames allow the special version symbols 2:oldest* and 2:newest*. In the string form of a pathname, these are expressed as `2.-2*', and as an omitted version. The directory component of a TOPS-20 pathname may be structured. The directory 2* is represented as the list 2("FOO" "BAR")*. The characters 2** and 2%* are wildcards that match any sequence of characters and any single character (within one pathname component), respectively. To specify a filename that actually contains a 2** or 2%* character, quote the character with 2*. When a component is specified with just a single 2**, the symbol 2:wild* appears in the pathname object. The TOPS-20 init file naming convention is 2"<1user*>1program*.INIT"*. When there is an attempt to display a TOPS-20 file name in the who-line and there isn't enough room to show the entire name, the name is truncated and followed by a center-dot character to indicate that there is more to the name than can be displayed. Tenex pathnames are almost the same as TOPS-20 pathnames, except that the version is preceeded by a semi-colon instead of a period, the default device is 2DSK* instead of 2PS*, and the quoting requirements are slightly different. VMS pathnames are basically like TOPS-20 pathnames, with a few complexities. The primary device is 2USRD$*. First of all, only alphanumeric characters are allowed in filenames (though 2$* and underscore can appear in device names). Secondly, a version number is preceded by `2;*' rather than by `2.*'. Thirdly, file types (called ``extensions'' in VMS terminology) are limited to three characters. Each of the system's canonical types has a special mapping for VMS pathnames, which is three characters long: 3:lisp  LSP :text  TXT :qfasl  QFS :midas  MID* 3:press  PRS :widths  WID :patch-directory  PDR* 3:qwabl  QWB :babyl  BAB :mail  MAI :xmail  XML* 3:init  INI :unfasl  UNF :output  OUT* =Node: 4Unix and Multics Pathnames* =Text: 3UNIX AND MULTICS PATHNAMES* A Unix pathname is a sequence of directory or file names separated by slashes. The last name is the filename; preceding ones are directory names (but directories are files anyway). There are no devices or versions. Alphabetic case is significant in Unix pathnames, no case conversion is normally done, and lower case is the default. Therefore, components of solid upper or lower case are inverted in case when going between interchange form and raw form. (What the user types in a pathname string is the raw form.) Unix allows you to specify a pathname relative to your default directory by using just a filename, or starting with the first subdirectory name; you can specify it starting from the root directory by starting with a slash. In addition, you can start with `2..*' as a directory name one or more times, to refer upward in the hierarchy from the default directory. Unix pathnames on the Lisp Machine provide all these features too, but the canonicalization to a simple descending list of directory names starting from the root is done on the Lisp Machine itself when you merge the specified pathname with the defaults. If a pathname string starts with a slash, the pathname object that results from parsing it is called ``absolute''. Otherwise the pathname object is called ``relative''. In an absolute pathname object, the directory component is either a symbol (2nil*, 2:unspecific* or 2:root*), a string, or a list of strings. A single string is used when there is only one level of directory in the pathname. A relative pathname has a directory that is a list of the symbol 2:relative* followed by some strings. When the pathname is merged with defaults, the strings in the list are appended to the strings in the default directory. The result of merging is always an absolute pathname. In a relative pathname's string form, the string ``2..*'' can be used as a directory name. It is translated to the symbol 2:up* when the string is parsed. That symbol is processed when the relative pathname is merged with the defaults. Restrictions on the length of Unix pathnames require abbreviations for the standard Zetalisp pathname types, just as for VMS. On Unix the preferred mappings of all canonical types are one or two characters long. We give here the mappings in raw form; they are actually specified in interchange form. 3:lisp  l :text  tx :qfasl  qf :midas  md* 3:press  pr :widths  wd :patch-directory  pd* 3:qwabl  qw :babyl  bb :mail  ma :xmail  xm* 3:init  in :unfasl  uf :output  ot* The Multics file system is much like the Unix one; there are absolute and relative pathnames, absolute ones start with a directory delimiter, and there are no devices or versions. Alphabetic case is significant. There are differences in details. Directory names are terminated, and absolute pathnames begun, with the character `2>*'. The containing directory is referred to by the character `2<*', which is complete in itself. It does not require a delimiter. Thus, 2<BAR* refers to subdirectory 2FOO*, file 2BAR* in the superdirectory of the superdirectory of the default directory. The limits on filename sizes are very large, so the system canonical types all use their standard mappings. Since the mappings are specified as upper case, and then interpreted as being in interchange form, the actual file names on Multics contain lower case. =Node: 4Lisp Machine File Systems* =Text: 3LISP MACHINE FILE SYSTEMS* There are two file systems that run in the MIT Lisp Machine system. They have different pathname syntax. Both can be accessed either remotely like any other file server, or locally. The Local-File system uses host name 2LM* for the machine you are on. A Local-File system on another machine can be accessed using the name of that machine as a host name, provided that machine is known as a file server. The remainder of the pathname for the Local-File system looks like 2"1directory*; 1name*.1type*#1version*"*. There is no restriction on the length of names; letters are converted to upper case. Subdirectories are allowed and are specified by putting periods between the directory components, as in 2RMS.SUBDIR;*. The TOPS-20 pathname syntax is also accepted. In addition, if the flag 2fs:*lmfs-use-twenex-syntax** is non-2nil*, Local-File pathnames print out using TOPS-20 syntax. Note that since the printed representation of a pathname is cached, changing this flag's value does not change the printing of pathnames with existing representations. The Local-File system on the filecomputer at MIT has the host name 2FS*. The LMFILE system is primarily for use as a file server, unless you have 512k of memory. At MIT it runs on the filecomputer and is accessed remotely with host name 2FC*. The remainder of an LMFILE pathname looks like 2"1directory*; 1name* 1type*#1version*"*. However, the directory and name can be composed of any number of subnames, separated by backslashes. This is how subdirectories are specified. 2FOO;BAR\X* refers to the same file as 2FOO\BAR;X*, but the two ways of specifying the file have different consequences in defaulting, getting directory listings, etc. Case is significant in LMFILE pathnames; however, when you open a file, the LMFILE system ignores the case when it matches your pathname against the existing files. As a result, the case you use matters when you create or rename a file, and appears in directory listings, but it is ignored when you refer to an existing file, and you cannot have two files whose names differ only in case. When components are accessed in interchange form, they are always converted to upper case. =Node: 4Logical Pathnames* =Text: 3LOGICAL PATHNAMES* There is another kind of pathname that doesn't correspond to any particular file server. It is called a 1logical* pathname, and its host is called a logical host. Every logical pathname can be translated into a corresponding 1physical* pathname because each logical host records a corresponding actual (``physical'') host and rules for translating the other components of the pathname. The reason for having logical pathnames is to make it easy to keep bodies of software on more than one file system. An important example is the body of software that constitutes the Lisp Machine system. Every site has a copy of all of the sources of the programs that are loaded into the initial Lisp environment. Some sites may store the sources on an ITS file system, while others may store them on a TOPS-20. However, system software (including 2make-system*) wishes to be able to find a particular file independent of the name of the host a particular site stores it on, or even the kind of host it is. This is done by means of the logical host 2SYS*; all pathnames for system files are actually logical pathnames with host 2SYS*. At each site, 2SYS* is defined as a logical host, but translations are different at each site. For example, at MIT the source files are stored on the TOPS-20 system named OZ, so MIT's site file says that 2SYS* should translate to the host 2OZ*. Each logical host, such as 2SYS*, has a list of translations, each of which says how to map certain pathnames for that host into pathnames for the corresponding physical host. To translate a logical pathname, the system tests each of the logical host's translations, in sequence, to see if it is applicable. (If none is applicable, an error is signaled.) A translation consists of a pair of pathnames or namestrings, typically containing wildcards. Unspecified components in them default to 2:wild*. The 1from*-pathname of the translation is used to match against the pathname to be translated; if it matches, the corresponding 1to*-pathname is used to construct the translation, filling in its wild fields from the pathname being translated as in the 2:translate-wild-pathname* operation (). Most commonly the translations contain pathnames that have only directories specified, everything else wild. Then the other components are unchanged by translation. If the files accessed through the logical host are moved, the translations can be changed so that the same logical pathnames refer to the same files on their new physical host via physical pathnames changed to fit the restrictions and the conventions of the new physical host. Each translation is specified as a list of two strings. The strings are parsed into pathnames and any unspecified components are defaulted to 2:wild*. The first string of the pair is the source pattern; it is parsed with logical pathname syntax. The second string is the target pattern, and it is parsed with the pathname syntax for the specified physical host. For example, suppose that logical host 2FOO* maps to physical host 2BAR*, a Tops-20, and has the following list of translations: 3(("BACK;" "PS:")* 3 ("FRONT;* QFASL" "SS:*.QFASL")* 3 ("FRONT;" "PS:"))* Then all pathnames with host 2FOO* and directory 2BACK* translate to host 2BAR*, device 2PS* and directory 2* with name, type and version unchanged. All pathnames with host 2FOO*, directory 2FRONT* and type 2QFASL* translate to host 2BAR*, device 2SS*, directory 2* and type 2QFASL*, with name and version unchanged. All other pathnames with host 2FOO* and directory 2FRONT* map to host 2BAR*, device 2PS* and directory 2*, with name, type and version unchanged. Note that the first translation whose pattern matches a given pathname is the one that is used. Another site might define 2FOO*'s to map to a Unix host 2QUUX*, with the following translation list: 3(("BACK;" "//nd//foo//back//")* 3 ("FRONT;" "//nd//foo//front//"))* This site apparently does not see a need to store the 2QFASL* files in a separate directory. Note that the slashes are duplicated to quote them for Lisp; the actual namestrings contain single slashes as is usual with Unix. If the last translation's source pattern is entirely wild, it applies to any pathname not so far handled. Example: 3(("BACK;" "//nd//foo//back//")* 3 ("" "//nd//foo1//*//"))* Physical pathnames can also be 1back-translated* into the corresponding logical pathname. This is the inverse transformation of ordinary translation. It is necessary to specify which logical host to back translate for, as it may be that the same physical pathname could be the translation of different logical pathnames on different hosts. Use the 2:back-translated-pathname* operation, below. 3fs:add-logical-pathname-host* 1logical-host* 1physical-host* 1translations* 3fs:set-logical-pathname-host* 1logical-host* &key 1physical-host* 1translations* Both create a new logical host named 1logical-host*. Its corresponding physical host (that is, the host to which it should forward most operations) is 1physical-host*. 1logical-host* and 1physical-host* should both be strings. 1translations* should be a list of translation specifications, as described above. The two functions differ only in that one accepts positional arguments and the other accepts keyword arguments. Example: 3(add-logical-pathname-host "MUSIC" "MUSIC-10-A"* 3 '(("MELODY;" "SS:")* 3 ("DOC;" "PS:")))* This creates a new logical host called 2MUSIC*. An attempt to open the file 2MUSIC:DOC;MANUAL * 2TEXT 2* will be re-directed to the file 2MUSIC-10-A:PS:MANUAL.TEXT.2* (assuming that the host 2MUSIC-10-A* is a TOPS-20 system). 3fs:make-logical-pathname-host* 1name* Requests that the definition of logical host 1name* be loaded from a standard place in the file system: namely, the file 2SYS: SITE; 1name* TRANSLATIONS*. This file is loaded immediately with 2load*, in the 2fs* package. It should contain code to create the logical host; normally, a call to 2fs:set-logical-pathname-host* or 2fs:add-logical-pathname-host*, above. The same file is automatically reloaded, if it has been changed, at appropriate times: by 2load-patches*, and whenever site information is updated. 3:translated-pathname* 1Operation on 2fs:logical-pathname** Converts a logical pathname to a physical pathname. It returns the translated pathname of this instance, a pathname whose host component is the physical host that corresponds to this instance's logical host. If this operation is applied to a physical pathname, it simply returns that pathname unchanged. 3:back-translated-pathname* 1pathname* 1Operation on 2fs:logical-pathname** Converts a physical pathname to a logical pathname. 1pathname* should be a pathname whose host is the physical host corresponding to this instance's logical host. This returns a pathname whose host is the logical host and whose translation is 1pathname*. If 1pathname* is not the translation of any logical pathname on this instance's host, 2nil* is returned. Here is an example of how this would be used in connection with truenames. Given a stream that was obtained by opening a logical pathname, 3(send stream :pathname)* returns the logical pathname that was opened. 3(send stream :truename)* returns the true name of the file that is open, which of course is a pathname on the physical host. To get this in the form of a logical pathname, one would do 3(send (send stream :pathname)* 3 :back-translated-pathname* 3 (send stream :truename))* If this operation is applied to a physical pathname, it simply returns its argument. Thus the above example works no matter what kind of pathname was opened to create the stream. 3fs:unknown-logical-pathname-translation* (3fs:pathname-error* 3error*) 1Condition* This is signaled when a logical pathname has no translation. The condition instance supports the 2:logical-pathname* operation, which returns the pathname that was untranslatable. The proceed type 2:define-directory* is supported. It expects a single argument, a pathname or a string to be parsed into one. This defines the target pattern for a translation whose source pattern is the directory from the untranslatable pathname (and all else wild). Such a translation is added to the logical host, making it possible to translate the pathname. A logical pathname looks like 2"1host*: 1directory*; 1name* 1type* 1version*"*. There is no way to specify a device; parsing a logical pathname always returns a pathname whose device component is 2:unspecific*. This is because devices don't have any meaning in logical pathnames. The equivalence-sign character (2*) can be used for quoting special characters such as spaces and semicolons. The double-arrow character (`2*') can be used as a place-holder for components that are 2nil*, and the up-horseshoe (`2*') indicates 2:unspecific* (generic pathnames typically have 2:unspecific* as the type and the version). All letters are mapped to upper case unless quoted. The 2:newest*, 2:oldest*, and 2:wild* values for versions are written as `2>*', `2<*', and `2**' respectively. There isn't any init file naming convention for logical hosts; you can't log into them. The 2:string-for-host*, 2:string-for-wholine*, 2:string-for-dired*, and 2:string-for-editor* messages are all passed on to the translated pathname, but the 2:string-for-printing* is handled by the 2fs:logical-pathname* flavor itself and shows the logical name. =Node: 4Editor Buffer Pathnames* =Text: 3EDITOR BUFFER PATHNAMES* The hosts 2ED*, 2ED-BUFFER* and 2ED-FILE* are used in pathnames which refer to buffers in the editor. If you open such a pathname, you get a stream that reads or writes the contents of an editor buffer. The three host names differ only in the syntax of the pathname, and in how it is interpreted. The host 2ED* is followed by an abbreviation that should complete to the name of an existing editor buffer. For example, the pathname 2ED:FOO* could refer to the buffer 2FOO.LISP PS: OZ:*. The host 2ED-BUFFER* is followed by an exact buffer name. If there is no buffer with that name, one is created. This is most useful for creating a buffer. The host 2ED-FILE* is followed by an arbitrary pathname, including a host name. An 2ED-FILE* pathname refers to a buffer visiting that file. If necessary, the file is read into the editor. For example, 2ED-FILE: OZ: PS:FOO.LISP* would refer to the same buffer as 2ED: FOO*. The current default defaults are used in processing the pathname that follows 2ED-FILE*, when the pathname is parsed.