Interlisp.org
Replies: 6 comments 4 replies
-
|
A possible approach may be something like Peter Seibel's portable pathname library. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Yep. That's a way to do it. |
Beta Was this translation helpful? Give feedback.
-
|
This is one of the few things that changed between CLtL 2 and ANSI Common Lisp; see https://interlisp.org/clhs/Issues/iss263_w.htm |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Yes, that is clear, but how do you get a list out of the directory structure? You parse the string? |
Beta Was this translation helpful? Give feedback.
-
|
On 10 May 2026, at 11:45, Marco Antoniotti ***@***.***> wrote:Alas, the pathnames are not CL compliant. The culprit is the :directory component that is an opaque structure and not a list.
'some other object defined by the implementation to be a valid directory component.': so anything is valid there. I think make-pathname needs to accept a list, but pathname directory doesn't have to return one.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
F*CK! I did miss the glossary entry in the ANSI spec. |
Beta Was this translation helpful? Give feedback.
-
|
mail on pathname-subdirectory-list
On Sun, May 10, 2026 at 11:05 AM Marco Antoniotti ***@***.***> wrote:
F*CK! I did miss the glossary entry in the ANSI spec.
—
Reply to this email directly, view it on GitHub
<#2601 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIQTK6KFM6APMPB2UN6PH342DAEHAVCNFSM6AAAAACYX5QJZWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMOBXGE2DMMQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
*start*
03270 00024 USf
Return-Path: ***@***.******@***.***>
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: ***@***.***
cc: Ghenis.pasa
Message-ID: ***@***.***>
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 ***@***.***, 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.<<
*start*
03800 00024 USf
Return-Path: ***@***.***>
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 ***@***.***>
Subject: Issue: Pathname-subdirectory-list
To: Masinter.pa, Ghenis.pasa
cc: ***@***.***
In-Reply-To: ***@***.***>
Message-ID: ***@***.***>
Line-fold: No
Date: 15 Jul 87 13:24 PDT
From: ***@***.***
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.
*start*
02296 00024 USa
Return-Path: ***@***.******@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 26 OCT 87 09:41:59 PST
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 09:39:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 26 OCT 87 09:39:22 PST
Date: Mon, 26 Oct 87 09:35 PST
From: EWeaver.pa
Subject: [Moon: Issue: Pathname-subdirectory-list]
To: Masinter.pa, Ghenis.pasa
cc: LispCore^.PA, ***@***.***, ***@***.***, ***@***.***
Fcc: BD:>EWeaver>mail.babyl
In-Reply-To: The message of 23 Oct 87 15:37 PDT from Masinter.pa
Message-ID: ***@***.***>
Line-fold: no
Date: 23 Oct 87 15:37 PDT
From: Masinter.pa
----- Begin Forwarded Messages -----
Date: Thu, 16 Jul 87 20:14 EDT
From: David A. Moon ***@***.***>
Subject: Issue: Pathname-subdirectory-list
Date: 15 Jul 87 13:24 PDT
From: ***@***.***
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.
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....
I might add that Kyoto / Ibuki Common Lisp uses this system too, and it
makes it quite simple to write code which ports to implementations which
run on other file systems. One notable case was a test suite which was
written on Unix and moved to VMS with no trouble.
I highly recommend this technique.
-------
*start*
00499 00024 US
Date: 26 Oct 87 14:51 PDT
From: Masinter.pa
Subject: Re: [Moon: Issue: Pathname-subdirectory-list]
In-reply-to: EWeaver.pa's message of Mon, 26 Oct 87 09:35 PST
To: EWeaver.pa
cc: Masinter.pa, Ghenis.pasa, LispCore^.PA
I had thought this wasn't a "live" issue for CL-CLEANUP although it might be a good AR. On further reflection, it does seem like it might make it into the "specification" as an example. I'll try to write that up and send it to CL-CLEANUP.
Thanks,
Larry
*start*
01165 00024 USf
Return-Path: ***@***.******@***.***>
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: ***@***.***
cc: ***@***.***
Message-ID: ***@***.***>
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...
*start*
08491 00024 US
Date: 10 Jun 88 02:29 PDT
From: Masinter.pa
Subject: [Masinter.pa: Issue: Pathname-subdirectory-list]
To: ***@***.***
cc: Masinter.pa
----- Begin Forwarded Messages -----
Return-Path: ***@***.******@***.***>
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: ***@***.***
cc: Ghenis.pasa
Message-ID: ***@***.***>
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 ***@***.***, 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: ***@***.***>
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 ***@***.***>
Subject: Issue: Pathname-subdirectory-list
To: Masinter.pa, Ghenis.pasa
cc: ***@***.***
In-Reply-To: ***@***.***>
Message-ID: ***@***.***>
Line-fold: No
Date: 15 Jul 87 13:24 PDT
From: ***@***.***
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: ***@***.******@***.***>
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: ***@***.***
cc: ***@***.***
Message-ID: ***@***.***>
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 -----
*start*
08839 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 10 JUN 88 02:32:05 PDT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 02:31:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 02:30:12 PDT
Date: 10 Jun 88 02:29 PDT
From: Masinter.pa
Subject: [Masinter.pa: Issue: Pathname-subdirectory-list]
To: ***@***.***
cc: Masinter.pa
Message-ID: ***@***.***>
----- Begin Forwarded Messages -----
Return-Path: ***@***.******@***.***>
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: ***@***.***
cc: Ghenis.pasa
Message-ID: ***@***.***>
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 ***@***.***, 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: ***@***.***>
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 ***@***.***>
Subject: Issue: Pathname-subdirectory-list
To: Masinter.pa, Ghenis.pasa
cc: ***@***.***
In-Reply-To: ***@***.***>
Message-ID: ***@***.***>
Line-fold: No
Date: 15 Jul 87 13:24 PDT
From: ***@***.***
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: ***@***.******@***.***>
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: ***@***.***
cc: ***@***.***
Message-ID: ***@***.***>
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 -----
*start*
08383 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 05 JUL 88 11:58:20 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jul 88 11:56:38 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 428605; Tue 5-Jul-88 14:56:20 EDT
Date: Tue, 5 Jul 88 14:56 EDT
From: Kent M Pitman ***@***.***>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: ***@***.***
cc: ***@***.***, ***@***.***
Message-ID: ***@***.***>
Dan -- I know you were gonna do something on this. I wasn't sure what
your timeframe was. It's very important to us right now, though, so in
an effort to get something on the table, I wrote the following. I hope
this doesn't step on your toes, but rather makes your job a bit easier.
-kmp
-----
Issue: PATHNAME-SUBDIRECTORY-LIST
References: Pathnames (pp410-413), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417)
Category: CHANGE
Edit history: 18-Jun-87, Version 1 by ***@***.***
05-Jul-88, Version 2 by Pitman (major revision)
Status: For Internal Discussion
Related-Issues: PATHNAME-COMPONENT-CASE
Problem Description:
It is impossible to write portable code that can produce a pathname
in a subdirectory of a hierarchical file system. This defeats much of
the purpose of having an abstraction like pathname.
According to CLtL, only a string is a portable filler of the directory
slot, but in order to denote a subdirectory, the use of separators (such
as dots, slashes, or backslashes) would be necessary. The very fact that
such syntax varies from host to host means that although the
representation might be "portable", the code using that representation
is not 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.
Related problems:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO" while in other implementations because "." is not the
separator. To be safe, portable programs must avoid all potential
separators.
- Even in implementations where "." is the separator, "FOO.BAR" may be
recognized by some to mean the "BAR" subdirectory of "FOO" and by others
to mean `a seven letter directory with "." being a superquoted part of
its name'.
- In fact, CLtL does not even say for toplevel directories whether the
directory delimiters are a part. eg, is "foo" or "/foo" the directory
filler for a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or
"FOO" the directory filler for a VMS pathname "[FOO]ME.LSP"?
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
Allow a list to be a filler of a pathname. The car of the list may be either
of the symbols :ABSOLUTE or :RELATIVE.
If the car of the list is :RELATIVE, the rest of the list is the
implementation-dependent result of PARSE-NAMESTRING for file systems which
have relative pathnames. Unless some other proposal is submitted to clarify
the behavior of relative pathnames in merging, etc. that behavior is left
undefined.
If the car of the list is :ABSOLUTE, the rest of the list is a list of
strings each naming a single level of directory structure. The strings
should contain only the directory names themselves -- no separator
characters.
The spec (:ABSOLUTE) represents the root directory.
Clarify that if a string is used as a filler of a directory field in a
pathname, it should be the unadorned name of a toplevel directory.
Specifying a string, str, is equivalent to specifying the list
(:ABSOLUTE str).
In place of a string, at any point in the list, the symbol :WILD or
:WILD-INFERIORS may occur. These symbols may not be meaningful for all
operating systems, but may be useful on those operating systems which
do provide such mechanisms. They denote a full wildcard match of one
or several directory levels, respectively.
Test Case:
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
=> (:ABSOLUTE "FOO" "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
=> (:ABSOLUTE "foo" "bar")
or (:ABSOLUTE "FOO" "BAR") ;if PATHNAME-COMPONENT-CASE:CANONICALIZE passes
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
Rationale:
This would allow programs to usefully deal with hierarchical file systems,
which are by far the most common file system type.
Current Practice:
Symbolics Genera implements something very similar to this. [The main
difference is that in Genera, there is no :ABSOLUTE keyword at the head
of the list. This has been shown to cause some problems in dealing with
root directories. Genera represents the root directory by a keyword
symbol (rather than a list) because the list representation was not
adequately general.]
Cost to Implementors:
In principle, nothing about the implementation needs to change except
the treatment of the directory field by MAKE-PATHNAME and
PATHNAME-DIRECTORY. The internal representation can otherwise be left
as-is if necessary.
For implementations that choose to rationalize this representation
throughout their internals and any other implementation-specific
accessors, the cost will be necessarily higher.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Serious portability problems would continue to occur. Programmers would be
driven to the use of implementation-specific facilities because the need
for this is frequently impossible to ignore.
Benefits:
The serious costs of non-adoption would be avoided.
Aesthetics:
This representation of hierarchical pathnames is easy to use and quite
general. Users will probably see this as an improvement in the aesthetics.
Discussion:
This issue was raised a while back but no one was fond of the particular
proposal that was submitted. This is an attempt to revive the issue.
The original proposal, to add a :SUBDIRECTORIES field to a pathname, was
discarded because it imposed an unnatural distinction between a toplevel
directory and its subdirectories. Pitman's guess is the the idea was to
try to make it a compatible change, but since most programmers will
probably want to change from implementation-specific primitives to portable
ones anyway, that's probably not such a big deal. Also, there might have
been some programs which thought the change was compatible and ended up
ignoring important information (the :SUBDIRECTORIES field). Pitman thought
it would be better if people just accepted the cost of an incompatible
change in order to get something really pretty as a result.
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
Variations on this proposal, one or more of which could be factored in if
there were sufficient interest are:
- Flushing the idea of strings as fillers for this field require
implementations to always use a list.
- Relaxing the representation to allow the keyword :ABSOLUTE to
be optional in most cases (but required to represent the root).
- Never using :ABSOLUTE, but requiring that to represent the root
directory, you must use the symbol :ROOT as the filler for the
directory slot.
- Specifying that the representation is either a list of strings
or a list whose car is a keyword such as :RELATIVE or :ROOT.
- Specifying that any implementation-specific contents must be a
list which begins with a keyword other than ones defined by these
proposals. eg, (:OTHER implementation-specific-stuff).
*start*
01048 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 05 JUL 88 16:25:44 PDT
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 5 Jul 88 16:24:38 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00752; Tue, 5 Jul 88 19:22:10 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA20327; Tue, 5 Jul 88 19:26:23 EDT
Message-Id: ***@***.***>
To: Kent M Pitman ***@***.***>
Cc: ***@***.***
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
In-Reply-To: Your message of Tue, 05 Jul 88 14:56:00 -0400.
***@***.***>
Date: Tue, 05 Jul 88 19:26:21 EDT
From: Dan L. Pierson ***@***.***>
Actually, I was waiting for Chris Perdue who said in Boston that he
had a draft in review. Thanks for giving us all a kick.
dan
*start*
02067 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 08 JUL 88 05:46:35 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:45:30 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430369; Fri 8-Jul-88 08:45:15 EDT
Return-path: ***@***.***>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430096; 7 Jul 88 16:36:50 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ***@***.***>; Thu, 7 Jul 88 16:36:37 EDT
Received: by spt.entity.com (smail2.5); 7 Jul 88 16:09:32 EDT (Thu)
Date: 7 Jul 88 16:09:32 EDT (Thu)
From: ***@***.*** (Gail Zacharias)
To: ***@***.***
In-Reply-To: ***@***.***>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Message-Id: ***@***.***>
Resent-To: ***@***.***
Resent-From: Kent M Pitman ***@***.***>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: ***@***.***>
Date: Tue, 5 Jul 88 14:56 EDT
From: Kent M Pitman ***@***.***>
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
I think this is pointless. Why should there be special syntax for "*" but
not for "x*z"? It only gives you the ability to detect a small subset of
possible wildcard specs, and it only gives you the ability to construct
a small subset of wildcard specs (and there's nothing equivalent for even
this small subset within file names or types or devices). It's a hack, which
might get in the way of a more general solution. Why not just leave everything
as strings for now, and leave other data types for any possible less ad hoc
approaches to the wildcard issues.
*start*
01802 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 08 JUL 88 05:47:12 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:45:41 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430370; Fri 8-Jul-88 08:45:25 EDT
Return-path: ***@***.***>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430095; 7 Jul 88 16:36:39 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ***@***.***>; Thu, 7 Jul 88 16:36:27 EDT
Received: by spt.entity.com (smail2.5); 7 Jul 88 16:27:55 EDT (Thu)
Date: 7 Jul 88 16:27:55 EDT (Thu)
From: ***@***.*** (Gail Zacharias)
To: ***@***.***
In-Reply-To: ***@***.***>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Message-Id: ***@***.***>
Resent-To: ***@***.***
Resent-From: Kent M Pitman ***@***.***>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: ***@***.***>
The Macintosh has syntax for moving up the directory structure. This is
similar to Unix's "../", although unlike Unix where there's an explicit ".."
pseudo-component, on the Macintosh it's just syntax. In any case, I'd like to
see your proposal extended to allow representing upward motion. Otherwise it
needs to be made clear that counting the number of elements in the
subdirectory list doesn't necessarily say anything about the nesting level of
the directory (it's neither a lower nor an upper bound).
*start*
02408 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 08 JUL 88 05:46:34 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:45:56 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430371; Fri 8-Jul-88 08:45:35 EDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430107; Thu 7-Jul-88 16:43:50 EDT
Date: Thu, 7 Jul 88 16:43 EDT
From: Kent M Pitman ***@***.***>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: ***@***.***
cc: ***@***.***
In-Reply-To: ***@***.***>
Message-ID: ***@***.***>
Resent-To: ***@***.***
Resent-From: Kent M Pitman ***@***.***>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: ***@***.***>
Date: 7 Jul 88 16:27:55 EDT (Thu)
From: ***@***.*** (Gail Zacharias)
The Macintosh has syntax for moving up the directory structure. This is
similar to Unix's "../", although unlike Unix where there's an explicit ".."
pseudo-component, on the Macintosh it's just syntax. In any case, I'd like to
see your proposal extended to allow representing upward motion. Otherwise it
needs to be made clear that counting the number of elements in the
subdirectory list doesn't necessarily say anything about the nesting level of
the directory (it's neither a lower nor an upper bound).
If (CAR (PATHNAME-DIRECTORY ...)) yields (:ABSOLUTE . something), then
if (NOT (MEMBER :WILD-INFERIORS something)) then (LENGTH something) is
the absolute nesting level. If (MEMBER :WILD-INFERIORS something), then
I think (- (LENGTH something) (COUNT :WILD-INFERIORS something)) is a
lower bound on the nesting level.
The idea would be for all such funny syntaxes to be relegated to :RELATIVE.
The lispm represents relative pathnames like lispm's "<<foo>bar.lisp"
as (MAKE-PATHNAME :DIRECTORY (:RELATIVE :UP :UP "FOO") :NAME "BAR" :TYPE "LISP").
I'll have to study how it does merging before sending out a proposal, but
do you see any obvious problems with this notation?
*start*
03034 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 08 JUL 88 05:47:24 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:45:58 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430372; Fri 8-Jul-88 08:45:43 EDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430112; Thu 7-Jul-88 16:49:55 EDT
Date: Thu, 7 Jul 88 16:49 EDT
From: Kent M Pitman ***@***.***>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: ***@***.***
cc: ***@***.***
In-Reply-To: ***@***.***>
Message-ID: ***@***.***>
Resent-To: ***@***.***
Resent-From: Kent M Pitman ***@***.***>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: ***@***.***>
Date: 7 Jul 88 16:09:32 EDT (Thu)
From: ***@***.*** (Gail Zacharias)
Date: Tue, 5 Jul 88 14:56 EDT
From: Kent M Pitman ***@***.***>
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
I think this is pointless. Why should there be special syntax for "*" but
not for "x*z"? It only gives you the ability to detect a small subset of
possible wildcard specs, and it only gives you the ability to construct
a small subset of wildcard specs (and there's nothing equivalent for even
this small subset within file names or types or devices). It's a hack, which
might get in the way of a more general solution. Why not just leave everything
as strings for now, and leave other data types for any possible less ad hoc
approaches to the wildcard issues.
I'm not sure of this myself, but I've not studied the issue well enough.
Anyway, it is already institutionalized in that CL already permits :WILD
as a filler of a directory slot even though there might be internal star
matches.
I think the main intent is to allow a person to write a portable call
like (DIRECTORY (MAKE-PATHNAME :NAME "FOO" :TYPE :WILD :VERSION :WILD))
without worrying that "*" might not be the wildcard char in all systems.
It just occurred to me that you are (and I was) supposing that "*" is
what :WILD translates to, but in fact it might not be. I guess I think
it's defensible (albeit less elegant) to support this particular special
case because it does have broader application in portable programs.
Btw, even systems which support embedded "*" disagree as to its
treatment. In some (eg, ITS) the * matches exactly one char, while in
others (eg, Unix or Lispm), it matches any number of chars.
Interestingly, ITS agrees however that when "*" stands alone that it
matches a variable number of chars...
*start*
06307 00024 USa
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 08 JUL 88 05:48:03 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:46:11 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430373; Fri 8-Jul-88 08:45:51 EDT
Return-path: ***@***.***>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430344; 8 Jul 88 06:13:33 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ***@***.***>; Fri, 8 Jul 88 06:13:15 EDT
Received: by spt.entity.com (smail2.5); 8 Jul 88 05:55:05 EDT (Fri)
Date: 8 Jul 88 05:55:05 EDT (Fri)
From: ***@***.*** (Gail Zacharias)
To: ***@***.***
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
In-Reply-To: ***@***.***>,
***@***.***>
Message-Id: ***@***.***>
Resent-To: ***@***.***
Resent-From: Kent M Pitman ***@***.***>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: ***@***.***>
Date: Thu, 7 Jul 88 16:49 EDT
From: Kent M Pitman ***@***.***>
Anyway, it is already institutionalized in that CL already permits :WILD
as a filler of a directory slot even though there might be internal star
matches.
Oops, you're right, I forgot all about this. "Never mind".
Date: Thu, 7 Jul 88 16:43 EDT
From: Kent M Pitman ***@***.***>
If (CAR (PATHNAME-DIRECTORY ...)) yields (:ABSOLUTE . something), then
if (NOT (MEMBER :WILD-INFERIORS something)) then (LENGTH something) is
the absolute nesting level.
I don't think (member :wild-inferiors ...) is sufficient. What about
implementations that allow more than one way to specify multi-level inferiors
(e.g. something along the lines of "x**y"). Such implementations can pick one
pattern to be represented by :WILD-INFERIORS, but they can't replace *every*
multi-level pattern with :WILD-INFERIORS without losing information. So
there's no implementation-independent way of getting an upper bound (or more
generally of knowing for certain whether a given component is wild or not).
It might be better for the subdirectory list to be just a list of <whatever>'s,
and provide predicates for testing components for wildness and/or
multi-levelness. (:WILD and :WILD-INFERIORS could still be required to be
recognized on input). I think :UP might just be a keyword, since I can't
imagine there being more than one way of moving up. But maybe this should
be a predicate as well just in case.
Another possibility might be for a component to be either a string
or a list (string . properties), where properties would be things like
:WILD, :RESTRICTED-WILD, :MULTI-LEVEL, :UP. A plain string means it's
a simple (non-wild) component.
If (MEMBER :WILD-INFERIORS something), then
I think (- (LENGTH something) (COUNT :WILD-INFERIORS something)) is a
lower bound on the nesting level.
The idea would be for all such funny syntaxes to be relegated to :RELATIVE.
I think then that you're overloading :ABSOLUTE to mean both rooted and
canonicalized. A unix name like "/foo/bar/../baz/" is fully rooted even
though it contains some relative motion within it. It's functionally (in the
file system) fully equivalent to "/foo/baz/", but it might not be equivalent
programmatically (i.e. it might intentionally appear in the middle of some
pathname-manipulating algorithm). Just on general principle, if a user says
"/foo/bar/../baz/", I would not feel comfortable with the loss of information
inherent in *automatically* reducing that to "/foo/baz/" at the pathname
level. I think of this as a TRUENAME-level action.
In fact, a TRUENAME-like function, say STANDARDIZE-PATHNAME, which didn't
actually require the file (or the directory) to exist, but just did as much
canonicalization as possible, might solve some of these problems. We (Coral)
have an internal function like that, it expands lisp-defined logical names and
removes syntactically redundant subdirectory motion (as well as any unnecessary
quoting). It's useful. Handling subdirectory structures is much simpler if
you can get the system to standardize them for you first.
One more observation, about the :ABSOLUTE/:RELATIVE distinction. The Macintosh
has a hierarchical file system, and relative pathnames, but it doesn't have a
root directory. Pathnames are rooted at the device, sort of like twenex
(except twenex doesn't really deal with relative pathnames. Maybe VMS is a
better analogy). Anyhow what this means is that being absolute or relative is
not a property of the directory alone, it's a property of the device/directory
pair. This isn't really a big deal, as I'm sure we can come up with some set
of conventions, but it does seem like it would introduce unnecessary conceptual
hair for our non-jet-setting users (i.e. Mac folks who don't really know from
other file systems). I think I would prefer the following option from your
discussion section, as being less intrusive for hierarchical file systems
without a root directory:
- Never using :ABSOLUTE, but requiring that to represent the root
directory, you must use the symbol :ROOT as the filler for the
directory slot.
I interpret this to mean that on unix, "foo/bar/" would be ("foo" "bar")
while "/foo/bar/" would be (:ROOT "foo" "bar"). With that interpretation,
I would also:
. state that this is the convention for output from pathname accessors, and
that using it on input to constructors may be non-portable (it would
signal an error in file systems without a root directory)
. state that the presence of :ROOT (probably?) means the pathname is absolute,
but the converse is not necessarily true (in particular it's false in file
systems without a root directory).
. add a predicate which takes a pathname and tells you if the pathname
as a whole is absolute (i.e. independent of any "current directory").
*start*
01723 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 08 JUL 88 10:30:36 PDT
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Jul 88 10:28:30 PDT
Received: by labrea.stanford.edu; Fri, 8 Jul 88 10:28:04 PDT
Received: from bhopal.lucid.com by edsel id AA06008g; Fri, 8 Jul 88 10:21:41 PDT
Received: by bhopal id AA15658g; Fri, 8 Jul 88 10:21:40 PDT
Date: Fri, 8 Jul 88 10:21:40 PDT
From: Jim McDonald ***@***.***>
Message-Id: ***@***.***>
To: ***@***.***
Cc: ***@***.***, ***@***.***
In-Reply-To: Gail Zacharias's message of 8 Jul 88 05:55:05 EDT (Fri) ***@***.***>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
> I think :UP might just be a keyword, since I can't
> imagine there being more than one way of moving up.
Assume you are using some version of un*x, and that /foo/b1/b2 is a
symbolic link to directory /foo/a1/a2/a3.
Then using csh, after cd /foo/b1/b2/.., pwd will show /foo/a1/a2,
but using bsh, after cd /foo/b1/b2/.., pwd will show /foo/b1.
I.e., if you are trying to emulate the behavior of csh, you must wait
until the truename is resolved before knowing where :UP will lead you.
In Lucid Common Lisp for the Sun-3, I get the following behavior,
assuming /u/jlm/b1/b2 is a symbolic link to ../a1/a2/a3, and all the
relevant directories actually exist:
> (cd "/u/jlm/")
#P"/u/jlm/"
> (setq aa (pathname "b1/b2/.."))
#P"b1/b2/.."
> (cd aa)
#P"/u/jlm/a1/a2/"
>
The moral is that (not (eq :UP :UNDO)).
jlm
*start*
01567 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 11 JUL 88 11:01:14 PDT
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Jul 88 10:59:32 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ***@***.***>; Mon, 11 Jul 88 13:57:24 EDT
Received: by spt.entity.com (smail2.5); 11 Jul 88 10:37:26 EDT (Mon)
To: ***@***.***
Cc: ***@***.***, ***@***.***
In-Reply-To: Jim McDonald's message of Fri, 8 Jul 88 10:21:40 PDT ***@***.***>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Message-Id: ***@***.***>
Date: 11 Jul 88 10:37:26 EDT (Mon)
From: ***@***.*** (Gail Zacharias)
Date: Fri, 8 Jul 88 10:21:40 PDT
From: Jim McDonald ***@***.***>
> I think :UP might just be a keyword, since I can't
> imagine there being more than one way of moving up.
...
Then using csh, after cd /foo/b1/b2/.., pwd will show /foo/a1/a2,
but using bsh, after cd /foo/b1/b2/.., pwd will show /foo/b1.
Right you are. Of course Unix doesn't have any syntax which would allow the
pathname itself to specify which variant it wants, but some other system
might. So this does show that it would be unwise to assume that every
implementation would be able to represent all upward motion in pathnames with
a single token such as :UP.
*start*
01013 00024 USa
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 22 JUL 88 10:04:36 PDT
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88 10:01:27 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA26844; Fri, 22 Jul 88 11:00:59 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA02402; Fri, 22 Jul 88 11:00:56 MDT
From: ***@***.*** (Sandra J Loosemore)
Message-Id: ***@***.***>
Date: Fri, 22 Jul 88 11:00:55 MDT
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: Kent M Pitman ***@***.***>
Cc: ***@***.***
In-Reply-To: Kent M Pitman ***@***.***>, Tue, 5 Jul 88 14:56 EDT
I've never had any need for this functionality and am not convinced it
is really that important. However, I don't have any strenuous
objections to the content of the proposal.
-Sandra
-------
*start*
01423 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 19 SEP 88 16:36:53 PDT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Sep 88 16:36:17 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 19 SEP 88 16:23:42 PDT
Date: 19 Sep 88 16:23 PDT
From: masinter.pa
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST, PATHNAME-COMPONENT-CASE,
PATHNAME-WILD
To: ***@***.***
Message-ID: ***@***.***>
I think it might be worthwhile to organize the pathname issues by operating
system, e.g., What's the right way for CL to talk to Unix-like file systems? To
Mac-like file systems? To VMS-like file systems?
At least for PATHNAME-COMPONENT-CASE, PATHNAME-CANONICAL-LIST, PATHNAME-WILD,
PATHNAME-TYPE-SPECIFIC.
There seem to be more PATHNAME issues than file-naming conventions. Further, it
seems more important to reach convergence within an operating system than across
them; for example, there's no good reason why the 7 different CLs available for
various UNIX systems should treat file names differently, or those within the
Mac world should treat those names differently. If we can get convergence among
implementors of CL within OS classes, we might well be able to sort out which
things are really different because the host OS is different?
What do you think?
*start*
02347 00024 USa
Return-Path: ***@***.***>
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by Xerox.COM ; 19 SEP 88 16:57:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462037; Mon 19-Sep-88 19:57:12 EDT
Date: Mon, 19 Sep 88 19:56 EDT
From: David A. Moon ***@***.***>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST, PATHNAME-COMPONENT-CASE,
PATHNAME-WILD
To: masinter.pa
cc: ***@***.***
In-Reply-To: ***@***.***>
Message-ID: ***@***.***>
Line-fold: No
Date: 19 Sep 88 16:23 PDT
From: ***@***.***
I think it might be worthwhile to organize the pathname issues by operating
system, e.g., What's the right way for CL to talk to Unix-like file systems?
What do you think?
I think that focussing the pathname issues by using specific operating
systems as examples is a great idea. I think that prescribing in the
Common Lisp spec how specific operating systems are to be treated is
possibly a good idea, but has some potential problems -- it makes the
Common Lisp spec dependent on specific operating systems that might
change out from under it; it might overspecify something that should
have been left to the discretion of implementors, in overreaction to the
present situation; it might encourage users to write nonportable
programs by paying attention only to the part of the spec for the
operating system they happened to develop on, ignoring the more general
portability concerns. These problems are not fatal if handled right.
I'm certain that handling each operating system in isolation, with no
coherency among them, is a recipe for disaster. It could increase
portability among multiple implementations on a single operating system,
but further damage portability between differing operating systems.
Unless you believe that no operating system but Unix will survive,
this would be doing no service to the users of Common Lisp.
I think this implies that you can't duck the PATHNAME-COMPONENT-CASE
issue so easily: you can't just say that each operating system can make
an individual choice.
Whether this will go over politically is difficult to judge. It didn't
work at all in 1983-4.
*start*
00867 00024 US
Date: 19 Sep 88 17:03 PDT
From: masinter.pa
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST, PATHNAME-COMPONENT-CASE, PATHNAME-WILD
In-reply-to: David A. Moon ***@***.***>'s message of Mon, 19 Sep 88 19:56 EDT
To: David A. Moon ***@***.***>
cc: masinter.pa
I agree that having the ANSI or ISO standard for Common Lisp talk about operating systems that are not themselves ANSI or ISO standards is a bad idea. However, an informal agreement among implementors for current operating systems would benefit the community, and would also help us sort out the real issues. I had suggested it as a process: discuss each operating system in isolation, and then attempt to find the common ground among the operating-system-specific proposals. (For "operating system" read "file naming convention").
*start*
01745 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 23 NOV 88 15:42:49 PST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Nov 88 15:39:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 NOV 88 15:34:13 PST
Date: 23 Nov 88 15:33 PST
From: masinter.pa
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: ***@***.***
Message-ID: ***@***.***>
I'd suggest we pare down the proposal PATHNAME-SUBDIRECTORY-LIST and allow
practice to follow: allow a list to be a filler of a pathname. Pathnames
are "relative" in an implementation dependent manner (maybe they're
relative to ROOT). And some implementations may accept and return special
keywords or lists of (keyword string) instead of components for the
DIRECTORY component of a pathname, we recommend:
:ABSOLUTE (allowable at the head) meaning to start at the "root" of the
file system
:WILD (allowable anywhere)
:WILD-INFERIORS
:UP
For example, in Unix systems, "/a/b/c/" might parse to (:absolute "a" "b"
"c") while in VMS "[a..b]" might parse to ("A" :wild-inferiors "B").
I think we should say that conformal programs that deal with pathnames must
'expect' those results back from (PATHNAME-DIRECTORY ...) but not require
implementations to return simple strings, instead making it "advisory".
This allows us to write a standard that talks about Unix even though there
isn't an ANSI standard for Unix, and let users know what to expect, even
though it isn't absolutely required for conformance because we can't
imagine all of the possible keywords that might map onto host file systems.
What do you think?
*start*
00930 00024 US
Return-Path: ***@***.***>
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by Xerox.COM ; 23 NOV 88 15:55:37 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 497569; Wed 23-Nov-88 18:56:08 EST
Date: Wed, 23 Nov 88 18:56 EST
From: Kent M Pitman ***@***.***>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: masinter.pa
cc: ***@***.***
In-Reply-To: ***@***.***>
Message-ID: ***@***.***>
The discussion on :UP shows that we don't understand it well enough to
be including it in any proposal which claims to be stripped down. I need
more time to study this issue and would like to postpone dealing with it
until after the letter ballot, instead targeting a mailing in time for
an in-person vote in January.
*start*
01078 00024 US
Return-Path: ***@***.***>
Redistributed: xerox-cl-cleanup^.pa
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 23 NOV 88 15:56:59 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Nov 88 15:56:16 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 497569; Wed 23-Nov-88 18:56:08 EST
Date: Wed, 23 Nov 88 18:56 EST
From: Kent M Pitman ***@***.***>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: masinter.pa
cc: ***@***.***
In-Reply-To: ***@***.***>
Message-ID: ***@***.***>
The discussion on :UP shows that we don't understand it well enough to
be including it in any proposal which claims to be stripped down. I need
more time to study this issue and would like to postpone dealing with it
until after the letter ballot, instead targeting a mailing in time for
an in-person vote in January.
*start*
02421 00024 USa
Return-Path: ***@***.***>
Received: from multimax.encore.com ([192.5.63.14]) by Xerox.COM ; 28 NOV 88 11:23:26 PST
Received: by multimax.encore.com (5.59/25-eef)
id AA03611; Mon, 28 Nov 88 14:22:10 EST
Date: Mon, 28 Nov 88 14:22:10 EST
From: Joe Boykin ***@***.***>
Message-Id: ***@***.***>
To: masinter.pa
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Dan Pierson sent me the following which he received from you:
> I'd suggest we pare down the proposal PATHNAME-SUBDIRECTORY-LIST and allow
> practice to follow: allow a list to be a filler of a pathname. Pathnames
> are "relative" in an implementation dependent manner (maybe they're
> relative to ROOT). And some implementations may accept and return special
> keywords or lists of (keyword string) instead of components for the
> DIRECTORY component of a pathname, we recommend:
>
> :ABSOLUTE (allowable at the head) meaning to start at the "root" of the
> file system
>
> :WILD (allowable anywhere)
> :WILD-INFERIORS
> :UP
>
>
> For example, in Unix systems, "/a/b/c/" might parse to (:absolute "a" "b"
> "c") while in VMS "[a..b]" might parse to ("A" :wild-inferiors "B").
>
> I think we should say that conformal programs that deal with pathnames must
> 'expect' those results back from (PATHNAME-DIRECTORY ...) but not require
> implementations to return simple strings, instead making it "advisory".
>
> This allows us to write a standard that talks about Unix even though there
> isn't an ANSI standard for Unix, and let users know what to expect, even
> though it isn't absolutely required for conformance because we can't
> imagine all of the possible keywords that might map onto host file systems.
FYI: There is an ANSI standard for UNIX, it was developed by the POSIX
P1003.1 group under the sponsorship of the IEEE Computer Societies
Technical Committee on Operating Systems. The standard was a "trial
use" standard for approximately two years and was recently (Aug 22,
1988) approved as a full IEEE/ANSI standard. Draft 12 of P1103.1 has
also been an interim FIPS (Federal Information Processing Standard) for
approximately a year.
Among other things, POSIX includes a definition of a pathname.
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Yes. Thanks. But the question remains. How do I get ? |
Beta Was this translation helpful? Give feedback.
-
|
i've lost track of where we are on this. Perhaps with all of the background now, you might restate what problem you want to solve? Are you having trouble connecting pathnames to files? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi
I am fooling around with Medley and I was entertaining the idea to port
some Common Lisp to it.
Apart the problem of figuring out how to "edit" "files" (but that's my
problem; I will bother you guys about this later on), there was the initial
problem of the wrong package used by CL:LOAD (which, I understand, can be
fixed) and, above all there is the issue of
(make-pathname :directory '(:absolute "foo" "bar"))
not working (even for CLtL2). make-pathname must accept that :directory
argument.
In reverse, it is not clear to me how to obtain the (:absolute "foo" "bar")
from the object returned by pathname-directory.
I am sure that, in general, there is a lot of CLtL2-fying to be done, not
to speak of ANSI-fying.
All the best
Marco
…On Mon, May 25, 2026 at 7:33 PM Larry Masinter ***@***.***> wrote:
i've lost track of where we are on this. Perhaps with all of the
background now, you might restate what problem you want to solve? Are you
having trouble connecting pathnames to files?
Or just looking for a project to help out?
—
Reply to this email directly, view it on GitHub
<#2601?email_source=notifications&email_token=AAD5SWWDN5MHBYOAW5F6AZ344R7WRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZQGUZDKOJTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17052593>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD5SWTV5J6HUZWFKJO57K344R7WRAVCNFSM6AAAAACYX5QJZWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMBVGI2TSMY>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Marco Antoniotti
Somewhere over the Rainbow
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi
I got the crazy idea to port another old thing to Interlisp CL.
Alas, the pathnames are not CL compliant. The culprit is the
:directorycomponent that is an opaque structure and not a list.Question: how would you build a "layer" on top of - at least - the pathnames? That is, what would you do (apart from building a full ANSICL package etc etc.)
Thanks
MA
Beta Was this translation helpful? Give feedback.
All reactions