[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue TRUENAME-SYNTAX-ONLY
- To: cl-cleanup@sail.stanford.edu
- Subject: issue TRUENAME-SYNTAX-ONLY
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Mon, 12 Sep 88 15:23:28 MDT
Here, at Moon's suggestion, is a formal proposal on something I
brought up earlier in connection with issue PATHNAME-SYNTAX-ERROR-TIME.
It is a separate issue since it can stand on its own regardless of which
(if any) of the proposals for PATHNAME-SYNTAX-ERROR-TIME is adopted, but
with a slight modification it could also supplant thos proposals and "fix"
the same problem.
-Sandra
Issue: TRUENAME-SYNTAX-ONLY
References: CLtL p. 413-414
Issue PATHNAME-SYNTAX-ERROR-TIME
Category: ENHANCEMENT, CLARIFICATION
Edit History: V1, Sandra Loosemore, 12 Sep 1988
Problem Description:
Filename syntax under VMS does not provide a syntactic distinction
between device names and logical names which may include other
pathname components. This causes particular problems when a pathname
including a logical name is passed to MERGE-PATHNAMES, since the
implementation may or may not expand the logical name to find the
"hidden" pathname components it includes. Although the function
TRUENAME performs file-name translation, as currently defined it can
only be used for this purpose if the pathname is a complete file
specification for an existing file, since it will signal an error
otherwise.
Other operating systems may have similar problems. For example, some
Lisps which run under Unix (notably PSL) use shell variables or
environment variables to serve the same purpose as logical names under
VMS.
Proposal TRUENAME-SYNTAX-ONLY:ADD:
(1) Add a keyword argument :SYNTAX-ONLY to the function TRUENAME. If
this argument is NIL or not supplied, an error is signalled if an
appropriate file cannot be located within the file systm for the given
pathname. Otherwise, TRUENAME signals an error only if the pathname
has illegal syntax for its specified host; it may not signal an error
if the file does not exist, if the pathname is not a complete file
specification, or if an attempt to create the file would fail for some
other reason (such as a nonexistent directory). TRUENAME applies any
file-name translations performed by the file system and returns the
"true name" of the specified file as a pathname.
(2) Clarify that functions OPEN, RENAME-FILE, DELETE-FILE, PROBE-FILE,
FILE-WRITE-DATE, FILE-AUTHOR, LOAD, and DIRECTORY perform the same
syntax-checking and file-name translation on their arguments as
TRUENAME.
(3) Clarify that coercion of a stream to a pathname (either implicitly
or by a call to the function PATHNAME) returns a pathname representing
the "true name" of the file. However, neither implicit nor explicit
coercion of strings to pathnames causes file-name translation to be
performed.
(4) Clarify that file-name translation on pathnames is not performed
under any other circumstances except those listed above.
Rationale:
This proposal gives the user explicit control over when logical names
are expanded. Other alternatives would be to require translation to
be performed automatically at pathname coercion time or within
MERGE-PATHNAMES. Both of these alternatives are unsatisfactory
because correct translation of the logical name depends on the host
and may not be performed correctly on a partial pathname.
Current Practice:
Vax Lisp under VMS expands logical names by default. (In
MERGE-PATHNAMES? I no longer have access to this implementation.)
Lucid Common Lisp does not, and provides no mechanism for expanding
logical names.
Cost to implementors:
Minor. VMS provides an RMS system call to perform the necessary
translation and syntax checking; this is also performed by default by
the system call which opens a file. Implementations running under
file systems which do not support any concept of logical names need
only perform a syntax check on the pathname within TRUENAME.
Cost to users:
None. This is a compatible change.
Benefits:
A portable mechanism for dealing with logical names is provided.
Discussion:
This proposal leaves open the possibility that syntax errors in
pathnames might also be detected at other times, such as at pathname
coercion time (see issue PATHNAME-SYNTAX-ERROR-TIME). However, it
would also be reasonable to restrict checking for syntax errors to the
same places that file name translation is applied.
-------