[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Masinter.pa: Issue: Pathname-subdirectory-list]


     ----- Begin Forwarded Messages -----

Return-Path: <@SAIL.STANFORD.EDU:Masinter.pa@Xerox.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 15 JUL 87 13:32:06 PDT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jul 87  13:29:01 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 15 JUL 87 13:27:05 PDT
Date: 15 Jul 87 13:24 PDT
 From: Masinter.pa
Subject: Issue: Pathname-subdirectory-list
To: cl-cleanup@sail.stanford.edu
cc: Ghenis.pasa
Message-ID: <870715-132705-3165@Xerox>

This arrived in my mailbox before the X3J13 meeting. While I suspect
there may be some alternative proposals, and perhaps some other
important related issues, this seems like a good way to introduce the
topic.

!

ISSUE: (PATHNAME-SUBDIRECTORY-LIST)

REFERENCES: CLtL pages 409 - 418

CATEGORY: ADDITION
  
EDIT HISTORY: Version 1 by Ghenis.pasa@Xerox.com, 06/18/87

PROBLEM DESCRIPTION:

It is impossible to write PORTABLE code that can produce a pathname
based on directory plus SUBDIRECTORY information. If the directory used
is not a root, then the string provided must contain OS-specific
separators. This defeats the purpose of having an abstraction like
pathname. Specifying a subdirectory RELATIVE to the current default is
possible but also inconvenient and non-portable.

This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.


PROPOSAL (PATHNAME-SUBDIRECTORY-LIST:ALLOW): 

Add a :SUBDIRECTORIES field to pathnames, to store a list of strings.

The string form of a pathname can be obtained by using the appropriate
OS-specific separator and end-delimiters.
Require global variables called LISP:*HOST-OS-ALIST* and
LISP:*DEFAULT-OS* to provide the information needed to assemble
namestrings correctly


TEST CASE (desired behavior): 

	>(defparameter LISP:*HOST-OS-ALIST*
		'(("vmsvax" . "vms") ("unixvax" . "unix"))

	>(defparameter LISP:*DEFAULT-OS* "msdos")

	>(defvar vmspath
		(make-pathname :host "vmsvax"
		 			:directory "smith"
		 			:sudirectories '("lisp") 
					:name "test"
		 			:type "lsp"))

	>(defvar localpath 
		(make-pathname :directory "smith" 			
					:sudirectories '("lisp")
 					:name "test"
 					:type "lsp"))

	>(namestring vmspath)
	"{vmsvax}[smith.lisp]test.lsp"

	>(namestring localpath)
	"c:\smith\lisp\test.lsp"


RATIONALE:

Pathnames are an abstraction meant to deal with the common notions in
file systems. Subdirectories exist in most operating systems. Common
Lisp must provide a standard way of dealing with subdirectories for
pathnames to be truly useful.


CURRENT PRACTICE:

CLtL acknowledges this problem and declares it to be a system dependent
issue.


ADOPTION COST:

This should be a simple addition to implement.


BENEFITS: 

Adding a :SUBDIRECTORIES field to pathnames would make the abstraction
completely system-independent. Relative pathnames could be trivially
specified by pathnames lacking a :DIRECTORY field.


CONVERSION COST: This is an upwards-compatible addition.


AESTHETICS:

Adding a :SUBDIRECTORIES field to pathnames would make the abstraction
completely system-independent.

DISCUSSION: >>Additional arguments, discussions, endorsements,
  testimonials, etc. should go here.<<



     ----- Next Message -----

Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 16 JUL 87 17:15:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 194405; Thu 16-Jul-87 20:14:29 EDT
Date: Thu, 16 Jul 87 20:14 EDT
 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: Pathname-subdirectory-list
To: Masinter.pa, Ghenis.pasa
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870715-132705-3165@Xerox>
Message-ID: <870716201416.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 15 Jul 87 13:24 PDT
    From: Masinter.pa@Xerox.COM

    PROBLEM DESCRIPTION:

    It is impossible to write PORTABLE code that can produce a pathname
    based on directory plus SUBDIRECTORY information. If the directory used
    is not a root, then the string provided must contain OS-specific
    separators. This defeats the purpose of having an abstraction like
    pathname. Specifying a subdirectory RELATIVE to the current default is
    possible but also inconvenient and non-portable.

    This problem is even worse for programs running on machines on a network
    that can retrieve files from multiple hosts, each using a different OS
    and thus a different subdirectory delimiter.

I agree with the problem description.  We've been dealing with heterogeneous
network for quite some time and have run into the same thing.

    PROPOSAL (PATHNAME-SUBDIRECTORY-LIST:ALLOW): 

    Add a :SUBDIRECTORIES field to pathnames, to store a list of strings.

Adding a new field as a way of solving this problem doesn't make sense.
Subdirectories are a structuring of the existing directory field, they are
not a new -independent- aspect of a pathname.

The solution to this problem that Symbolics has used for years works
quite well.  The directory is a structured field whose value is returned
as a list of strings, one string for each subdirectory level.  In
addition to strings, in our system we allow certain keywords in the
list, enumerated below.  Note that this general approach is the solution
suggested by CLtL itself, page 412 about 3/4 of the way down the page;
thus the only reason to change the language would be if we want to force
all implementations to use the same representation of structured
directories, which might be difficult if some implementation uses a
strange file system with a directory feature we haven't thought of.

When constructing a pathname, either a list of strings, or a single
string containing host-dependent delimiters, is accepted.  To retrieve a
string containing host-dependent delimiters, the existing
DIRECTORY-NAMESTRING function is used.

In case those keywords aren't self-evident, here are some examples. 
Vixen is a Unix, presumably everyone is familiar with Unix pathname
syntax.

(make-pathname :host "vixen"
	       :directory '("foo" "bar")) => #P"VIXEN:/foo/bar/"
(make-pathname :host "vixen"
	       :directory '(:relative "bar")) => #P"VIXEN:bar/"
(make-pathname :host "vixen"
	       :directory '(:relative :up "bar")) => #P"VIXEN:../bar/"
(make-pathname :host "vixen"
	       :directory '(:relative :up :up "bar")) => #P"VIXEN:../../bar/"
(make-pathname :host "vixen"
	       :directory '("foo" :wild "bar")) => #P"VIXEN:/foo/*/bar/"

I can't show you :wild-inferiors on Unix, because Unix is too simple
and elegant to have such useful features, so I'll use VMS:

(make-pathname :host "dumbo"
	       :directory '("foo" :wild "bar")) => #P"DUMBO:[foo.*.bar]"
(make-pathname :host "dumbo"
	       :directory '("foo" :wild-inferiors "bar")) => #P"DUMBO:[foo...bar]"

The name of the VMS host is not intended to be particularly pejorative, all of
our
Vaxes are named after flying critters.



     ----- Next Message -----

Return-Path: <@SAIL.Stanford.EDU:Masinter.pa@Xerox.COM>
Redistributed: xerox-cl-cleanupâ??.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 26 OCT 87 14:16:37 PST
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87  14:13:22 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 14:08:46 PST
Date: 26 Oct 87 14:55 PDT
 From: Masinter.pa
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST
In-reply-to: EWeaver.pa's message of Mon, 26 Oct 87 09:35 PST
To: cl-cleanup@sail.stanford.edu
cc: ibuki!dbp@labrea.stanford.edu
Message-ID: <871026-140846-2061@Xerox>

I had marked the issue PATHNAME-SUBDIRECTORY-LIST as withdrawn; I
thought Moon's point ("the only reason to change the language would be
if we want to force all implementations to use the same representation
of structured directories, which might be difficult if some
implementation uses a strange file system with a directory feature we
haven't thought of.") was compelling.

However, I think there is some advantage to encouraging some consistency
of practice for those systems which do have subdirectory structures... 

I'd recommend we postpone this issue for now...


     ----- End Forwarded Messages -----