381 lines
29 KiB
HTML
381 lines
29 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue PATHNAME-WILD Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss266_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss267.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss268_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss266_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss267.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss268_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue PATHNAME-WILD Writeup</H2>
|
|
|
|
<PRE><B>Status:</B> Passed, as amended, Jun 89 X3j13<P>
|
|
<B>Issue:</B> <A HREF="iss267.htm">PATHNAME-WILD</A><P>
|
|
<B>Forum:</B> Cleanup<P>
|
|
<B>References:</B> Pathnames (pp410-413)<P>
|
|
Related issues: <A HREF="iss257.htm">PATHNAME-COMPONENT-VALUE</A>, <A HREF="iss259.htm">PATHNAME-LOGICAL</A><P>
|
|
<B>Category:</B> ADDITION<P>
|
|
<B>Edit history:</B> 21-Jul-88, Version 1 by Pitman<P>
|
|
06-Oct-88, Version 2 by Pitman<P>
|
|
9-May-89, Version 3 by Moon (small fixes)<P>
|
|
10-May-89, Version 4 by Moon (add two more functions)<P>
|
|
13-May-89, Version 5 by Moon (minor cleanups, add clarification)<P>
|
|
19-Jun-89, Version 6 by Moon (revise based on extensive<P>
|
|
discussion in the cleanup subcommittee; rewrite<P>
|
|
the description of <A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> so it is<P>
|
|
possible to understand it)<P>
|
|
23-Jun-89, Version 7 by Moon (simplify <A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A><P>
|
|
based on last minute discussion of logical pathnames)<P>
|
|
2-Jul-89, Version 8 by Masinter (T -> True as per Jun89 X3J13)<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
Some file systems <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> more complex conventions for wildcards than<P>
|
|
simple component-wise wildcards (:WILD). For example,<P>
|
|
<P>
|
|
"F*O" might mean:<P>
|
|
- a normal three character name<P>
|
|
- a three-character name, with the middle char wild<P>
|
|
- at least a two-character name, with the middle 0 or more chars wild<P>
|
|
- a wild match spanning multiple directories<P>
|
|
<P>
|
|
">foo>*>bar" might imply:<P>
|
|
- the middle directory is named "*"<P>
|
|
- the middle directory is :WILD<P>
|
|
- there may be zero or more :WILD middle directories<P>
|
|
- the middle directory name matches any one-letter name<P>
|
|
<P>
|
|
">foo>**>bar" might mean<P>
|
|
- the middle directory is named "**"<P>
|
|
- the middle directory is :WILD<P>
|
|
- there may be zero or more :WILD middle directories<P>
|
|
- the middle directory name matches any two-letter name<P>
|
|
<P>
|
|
Some file systems support even more complex wildcards, for example<P>
|
|
regular expressions.<P>
|
|
<P>
|
|
The CL <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> model does not specify a way to represent complex<P>
|
|
wildcards, which means, for example, that (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :NAME "F*O")<P>
|
|
cannot be recognized by portable code as containing a wildcard.<P>
|
|
<P>
|
|
Common Lisp provides only the first of these four common operations<P>
|
|
on wildcard pathnames:<P>
|
|
(1) Enumerate the set of existing files that match the pathname;<P>
|
|
this is provided by the <A REL=DEFINITION HREF="../Body/f_dir.htm#directory"><B>DIRECTORY</B></A> function.<P>
|
|
(2) Test whether a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> contains wildcards.<P>
|
|
(3) Test whether a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> matches a wildcard <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>.<P>
|
|
(4) Translate one <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> into another according to a mapping specified<P>
|
|
by a pair of wildcard pathnames.<P>
|
|
<P>
|
|
<B>Proposal (PATHNAME-WILD:NEW-FUNCTIONS):<P>
|
|
</B><P>
|
|
Introduce the following three functions:<P>
|
|
<P>
|
|
1. <A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> &optional field-key<P>
|
|
<P>
|
|
Tests a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> for the presence of wildcard components. If the first<P>
|
|
argument is not a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, string, or file stream an error of type<P>
|
|
<A REL=DEFINITION HREF="../Body/e_tp_err.htm#type-error"><B>TYPE-ERROR</B></A> is signalled.<P>
|
|
<P>
|
|
If no <field-key> is provided, or the <field-key> is <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>, the result is<P>
|
|
true if <pathname> has any wildcard components, <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> if <pathname> has none.<P>
|
|
If a non-null <field-key> is provided, it must be one of :HOST, :DEVICE,<P>
|
|
:DIRECTORY, :NAME, :TYPE, or :VERSION. In this case, the result is true<P>
|
|
if the indicated component of <pathname> is a wildcard, <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> if the<P>
|
|
component is not a wildcard. Note that not all implementations<P>
|
|
support wildcards in all fields, according to <A HREF="iss257.htm">PATHNAME-COMPONENT-VALUE</A>.<P>
|
|
<P>
|
|
<P>
|
|
2. <A REL=DEFINITION HREF="../Body/f_pn_mat.htm#pathname-match-p"><B>PATHNAME-MATCH-P</B></A> <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> wildcard<P>
|
|
<P>
|
|
true if <pathname> matches <wildcard>, otherwise <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>. The matching rules<P>
|
|
are implementation-defined but should be consistent with the<P>
|
|
<A REL=DEFINITION HREF="../Body/f_dir.htm#directory"><B>DIRECTORY</B></A> function. Missing components of <wildcard> default to :WILD.<P>
|
|
<P>
|
|
If either argument is not a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, string, or file stream an error<P>
|
|
of type <A REL=DEFINITION HREF="../Body/e_tp_err.htm#type-error"><B>TYPE-ERROR</B></A> is signalled. It is valid for <pathname> to be a<P>
|
|
wild pathname; a wildcard field in <pathname> will only match a<P>
|
|
wildcard field in <wildcard>, i.e. the function is not commutative.<P>
|
|
It is valid for <wildcard> to be a non-wild <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>.<P>
|
|
<P>
|
|
<P>
|
|
3. <A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> source from-wildcard to-wildcard &key<P>
|
|
<P>
|
|
Translates the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> <source>, which matches <from-wildcard>, into<P>
|
|
a corresponding <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> <result>, which matches <to-wildcard>, and<P>
|
|
returns <result>.<P>
|
|
<P>
|
|
The <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> <result> is <to-wildcard> with each wildcard or missing<P>
|
|
field replaced by a portion of <source>. A "wildcard field" is a<P>
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> component with a value of :WILD, a :WILD element of a<P>
|
|
list-valued directory component, or an implementation-defined portion<P>
|
|
of a component, such as the "*" in the complex wildcard string<P>
|
|
"foo*bar" that some implementations support. An implementation that<P>
|
|
adds other wildcard features, such as regular expressions, must define<P>
|
|
how <A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> extends to those features. A "missing field" is<P>
|
|
a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> component with a value of <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>.<P>
|
|
<P>
|
|
The portion of <source> that is copied into <result> is implementation<P>
|
|
defined. Typically it is determined by the user interface conventions<P>
|
|
of the file systems involved. Usually it is the portion of <source><P>
|
|
that matches a wildcard field of <from-wildcard> that is in the same<P>
|
|
position as the wildcard or missing field of <to-wildcard>. If there<P>
|
|
is no wildcard field in <from-wildcard> at that position, then usually<P>
|
|
it is the entire corresponding <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> component of <source>, or in<P>
|
|
the case of a list-valued directory component, the entire corresponding<P>
|
|
list element. For example, if the name components of <source>,<P>
|
|
<from-wildcard>, and <to-wildcard> are "gazonk", "gaz*", and "h*"<P>
|
|
respectively, then in most file systems, the wildcard fields of the<P>
|
|
name component of <from-wildcard> and <to-wildcard> are each "*", the<P>
|
|
matching portion of <source> is "onk", and the name component of<P>
|
|
<result> is "honk". However, the exact behavior of <A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A><P>
|
|
cannot be dictated by the Common Lisp language and must be allowed to<P>
|
|
vary, depending on the user interface conventions of the file systems<P>
|
|
involved.<P>
|
|
<P>
|
|
During the copying of a portion of <source> into <result>, additional<P>
|
|
implementation-defined translations of alphabetic case or file naming<P>
|
|
conventions might occur, especially when <from-wildcard> and<P>
|
|
<to-wildcard> are for different hosts.<P>
|
|
<P>
|
|
If any of the first three arguments is not a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, string, or file<P>
|
|
stream an error of type <A REL=DEFINITION HREF="../Body/e_tp_err.htm#type-error"><B>TYPE-ERROR</B></A> is signalled. It is valid for<P>
|
|
<source> to be a wild pathname; in general this will produce a wild<P>
|
|
result. It is valid for <from-wildcard> and/or <to-wildcard> to be<P>
|
|
non-wild pathnames. (<A REL=DEFINITION HREF="../Body/f_pn_mat.htm#pathname-match-p"><B>PATHNAME-MATCH-P</B></A> <source> <from-wildcard>) must<P>
|
|
be true or an error is signalled.<P>
|
|
<P>
|
|
There are no specified keyword arguments for <A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A>, but<P>
|
|
implementations are permitted to extend it by adding keyword arguments.<P>
|
|
There is one specified return value from TRANSLATE-PATHNAME;<P>
|
|
implementations are permitted to extend it by returning additional<P>
|
|
values.<P>
|
|
<P>
|
|
Implementation guideline: one file system performs this operation by<P>
|
|
examining each piece of the three pathnames in turn, where a piece is a<P>
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> component or a list element of a structured component such as<P>
|
|
a hierarchical directory. Hierarchical directory elements in<P>
|
|
<from-wildcard> and <to-wildcard> are matched by whether they are<P>
|
|
wildcards, not by depth in the directory hierarchy. If the piece in<P>
|
|
<to-wildcard> is present and not wild, it is copied into the result.<P>
|
|
If the piece in <to-wildcard> is :WILD or <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>, the piece in <source> is<P>
|
|
copied into the result. Otherwise, the piece is <to-wildcard> might be<P>
|
|
a complex wildcard such as "foo*bar" and the piece in <from-wildcard><P>
|
|
should be wild; the portion of the piece in <source> that matches the<P>
|
|
wildcard portion of the piece in <from-wildcard> replaces the wildcard<P>
|
|
portion of the piece in <to-wildcard> and the value produced is used in<P>
|
|
the result.<P>
|
|
<P>
|
|
4. Clarify that the functions <A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A> (and <A REL=DEFINITION HREF="../Body/m_w_open.htm#with-open-file"><B>WITH-OPEN-FILE</B></A>), <A REL=DEFINITION HREF="../Body/f_probe_.htm#probe-file"><B>PROBE-FILE</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_file_w.htm#file-write-date"><B>FILE-WRITE-DATE</B></A>, <A REL=DEFINITION HREF="../Body/f_file_a.htm#file-author"><B>FILE-AUTHOR</B></A>, and <A REL=DEFINITION HREF="../Body/f_tn.htm#truename"><B>TRUENAME</B></A> only accept non-wildcard<P>
|
|
pathnames and signal an error if given a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> for which<P>
|
|
<A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> returns true.<P>
|
|
<P>
|
|
5. Clarify that the functions <A REL=DEFINITION HREF="../Body/f_rn_fil.htm#rename-file"><B>RENAME-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_del_fi.htm#delete-file"><B>DELETE-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>, and<P>
|
|
<A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> have implementation-defined consequences when given a<P>
|
|
wildcard <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>. Each function might signal an error or might operate<P>
|
|
on all files that match the wildcard <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>.<P>
|
|
<P>
|
|
<P>
|
|
<B>Examples:<P>
|
|
</B><P>
|
|
;The following examples are not portable. They are written to run<P>
|
|
;with particular file systems and particular wildcard conventions.<P>
|
|
;Other implementations will behave differently. These examples are<P>
|
|
;intended to be illustrative, not to be prescriptive.<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :NAME :WILD)) => T<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :NAME :WILD) :NAME) => T<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :NAME :WILD) :TYPE) => <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A><P>
|
|
(<A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> (<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A> "S:>foo>**>")) => T ;Lispm<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> (<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A> :NAME "F*O")) => T ;Most places<P>
|
|
<P>
|
|
;This example assumes one particular set of wildcard conventions<P>
|
|
;Not all file systems will run this example exactly as written<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> RENAME-FILES (FROM TO)<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_dolist.htm#dolist"><B>DOLIST</B></A> (FILE (<A REL=DEFINITION HREF="../Body/f_dir.htm#directory"><B>DIRECTORY</B></A> FROM))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_rn_fil.htm#rename-file"><B>RENAME-FILE</B></A> FILE (<A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> FILE FROM TO))))<P>
|
|
(RENAME-FILES "/usr/me/*.lisp" "/dev/her/*.l")<P>
|
|
;Renames /usr/me/init.lisp to /dev/her/init.l<P>
|
|
(RENAME-FILES "/usr/me/pcl*/*" "/sys/pcl/*/")<P>
|
|
;Renames /usr/me/pcl-5-may/low.lisp to /sys/pcl/pcl-5-may/low.lisp<P>
|
|
;In some file systems the result might be /sys/pcl/5-may/low.lisp<P>
|
|
(RENAME-FILES "/usr/me/pcl*/*" "/sys/library/*/")<P>
|
|
;Renames /usr/me/pcl-5-may/low.lisp to /sys/library/pcl-5-may/low.lisp<P>
|
|
;In some file systems the result might be /sys/library/5-may/low.lisp<P>
|
|
(RENAME-FILES "/usr/me/foo.bar" "/usr/me2/")<P>
|
|
;Renames /usr/me/foo.bar to /usr/me2/foo.bar<P>
|
|
(RENAME-FILES "/usr/joe/*-recipes.text" "/usr/jim/cookbook/joe's-*-rec.text")<P>
|
|
;Renames /usr/joe/lamb-recipes.text to /usr/jim/cookbook/joe's-lamb-rec.text<P>
|
|
;Renames /usr/joe/pork-recipes.text to /usr/jim/cookbook/joe's-pork-rec.text<P>
|
|
;Renames /usr/joe/veg-recipes.text to /usr/jim/cookbook/joe's-veg-rec.text<P>
|
|
<P>
|
|
;This example assumes one particular set of wildcard conventions<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-name"><B>PATHNAME-NAME</B></A> (<A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> "foobar" "foo*" "*baz")) => "barbaz"<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-name"><B>PATHNAME-NAME</B></A> (<A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> "foobar" "foo*" "*")) => "foobar"<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-name"><B>PATHNAME-NAME</B></A> (<A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> "foobar" "*" "foo*")) => "foofoobar"<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-name"><B>PATHNAME-NAME</B></A> (<A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> "bar" "*" "foo*")) => "foobar"<P>
|
|
<P>
|
|
;Using Unix syntax and the wildcard conventions used by the<P>
|
|
;particular version of Unix on which I tried this:<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A><P>
|
|
(<A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> "/usr/dmr/hacks/frob.l"<P>
|
|
"/usr/d*/hacks/*.l"<P>
|
|
"/usr/d*/backup/hacks/backup-*.*"))<P>
|
|
=> "/usr/dmr/backup/hacks/backup-frob.l"<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A><P>
|
|
(<A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> "/usr/dmr/hacks/frob.l"<P>
|
|
"/usr/d*/hacks/fr*.l"<P>
|
|
"/usr/d*/backup/hacks/backup-*.*"))<P>
|
|
=> "/usr/dmr/backup/hacks/backup-ob.l"<P>
|
|
<P>
|
|
;This is similar to the above example but uses two different hosts,<P>
|
|
;U: which is a Unix and V: which is a VMS. Note the translation<P>
|
|
;of file type and alphabetic case conventions.<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A><P>
|
|
(<A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> "U:/usr/dmr/hacks/frob.l"<P>
|
|
"U:/usr/d*/hacks/*.l"<P>
|
|
"V:SYS$DISK:[D*.BACKUP.HACKS]BACKUP-*.*"))<P>
|
|
=> "V:SYS$DISK:[DMR.BACKUP.HACKS]BACKUP-FROB.LSP"<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A><P>
|
|
(<A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> "U:/usr/dmr/hacks/frob.l"<P>
|
|
"U:/usr/d*/hacks/fr*.l"<P>
|
|
"V:SYS$DISK:[D*.BACKUP.HACKS]BACKUP-*.*"))<P>
|
|
=> "V:SYS$DISK:[DMR.BACKUP.HACKS]BACKUP-OB.LSP"<P>
|
|
<P>
|
|
;This example presumes background information described in <A HREF="iss259.htm">PATHNAME-LOGICAL</A><P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> TRANSLATE-LOGICAL-PATHNAME-1 (<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A> RULES)<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>LET</B></A> ((RULE (<A REL=DEFINITION HREF="../Body/f_assocc.htm#assoc"><B>ASSOC</B></A> <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A> RULES :TEST #'<A REL=DEFINITION HREF="../Body/f_pn_mat.htm#pathname-match-p"><B>PATHNAME-MATCH-P</B></A>)))<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_when_.htm#unless"><B>UNLESS</B></A> RULE (<A REL=DEFINITION HREF="../Body/a_error.htm#error"><B>ERROR</B></A> "No translation rule for ~A" <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A>))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A> (<A REL=DEFINITION HREF="../Body/f_firstc.htm#first"><B>FIRST</B></A> RULE) (<A REL=DEFINITION HREF="../Body/f_firstc.htm#second"><B>SECOND</B></A> RULE))))<P>
|
|
(TRANSLATE-LOGICAL-PATHNAME-1 "FOO:CODE;BASIC.LISP"<P>
|
|
'(("FOO:DOCUMENTATION;" "MY-UNIX:/doc/foo/")<P>
|
|
("FOO:CODE;" "MY-UNIX:/lib/foo/")<P>
|
|
("FOO:PATCHES;*;" "MY-UNIX:/lib/foo/patch/*/")))<P>
|
|
=> <A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>the</B></A> <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> MY-UNIX:/lib/foo/basic.l<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
1,2,3. These three functions <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> a standardized interface to the<P>
|
|
idiosyncratic wildcard functionality of each host file system.<P>
|
|
<P>
|
|
1. <A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> makes it possible to detect wild pathnames reliably and<P>
|
|
do something useful (give up, merge out the bothersome components, call<P>
|
|
<A REL=DEFINITION HREF="../Body/f_dir.htm#directory"><B>DIRECTORY</B></A> for a list of matching pathnames, etc.)<P>
|
|
<P>
|
|
2,3. <A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> is needed by many application programs that deal<P>
|
|
with wildcard pathnames. <A REL=DEFINITION HREF="../Body/f_pn_mat.htm#pathname-match-p"><B>PATHNAME-MATCH-P</B></A> and <A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> are<P>
|
|
needed by logical pathnames. The <A HREF="iss259.htm">PATHNAME-LOGICAL</A> proposal cannot be<P>
|
|
implemented without these features. Implementing <A HREF="iss259.htm">PATHNAME-LOGICAL</A> could<P>
|
|
involve adding additional capabilities to <A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A>, depending<P>
|
|
on the type of file system used, but those capabilities do not need to<P>
|
|
be in the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>.<P>
|
|
<P>
|
|
4. Since these functions return a value connected with one file, there<P>
|
|
is no meaningful way to extend them to work on wildcard pathnames. It<P>
|
|
seems best to specify that they signal an error, rather than leaving<P>
|
|
the consequences undefined.<P>
|
|
<P>
|
|
5. The consequences are proposed to be implementation-defined because<P>
|
|
current practice varies and no one wants to change.<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
Presumably no implementation supports the proposal exactly as stated.<P>
|
|
Symbolics Genera has had similar features under different names for many<P>
|
|
years:<P>
|
|
<P>
|
|
(SEND <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> :WILD-P) returns a value such as <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>, :NAME, :TYPE,<P>
|
|
etc., indicating the first wild field.<P>
|
|
<P>
|
|
(SEND <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> :NAME-WILD-P), (SEND <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> :DIRECTORY-WILD-P),<P>
|
|
etc. test individual fields.<P>
|
|
<P>
|
|
The :TRANSLATE-WILD-PATHNAME, :TRANSLATE-WILD-PATHNAME-REVERSIBLE, and<P>
|
|
:PATHNAME-MATCH messages resemble <A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A> and<P>
|
|
<A REL=DEFINITION HREF="../Body/f_pn_mat.htm#pathname-match-p"><B>PATHNAME-MATCH-P</B></A>.<P>
|
|
<P>
|
|
The Explorer also supports the messages :WILD-P (although it only<P>
|
|
returns <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> or T), :NAME-WILD-P, etc., :TRANSLATE-WILD-PATHNAME, and<P>
|
|
:PATHNAME-MATCH.<P>
|
|
<P>
|
|
Points 4 and 5 are current practice as far as the authors are aware.<P>
|
|
The Explorer permits <A REL=DEFINITION HREF="../Body/f_del_fi.htm#delete-file"><B>DELETE-FILE</B></A> on a wild <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, meaning to delete<P>
|
|
all files that match.<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
Many implementations probably have a substrate which is capable of this<P>
|
|
or something similar already. In such cases, it's a relatively small<P>
|
|
matter to add the proposed interface.<P>
|
|
<P>
|
|
Even in cases where an implementation doesn't have ready code, it's clearly<P>
|
|
better for the implementor to write that code once and for all than to ask<P>
|
|
each user of wildcards to write it.<P>
|
|
<P>
|
|
Since the detailed behavior is at the implementor's discretion, the cost<P>
|
|
is unlikely to be large. Some file systems will do all the work and the<P>
|
|
implementor need only <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> an interface to the file system or to a<P>
|
|
<A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> library routine. For other file systems the implementor has to<P>
|
|
write the actual matching and translation algorithms.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
None. This change is upward compatible.<P>
|
|
<P>
|
|
<B>Cost of Non-Adoption:<P>
|
|
</B><P>
|
|
Wild pathnames would continue to be mistaken for ordinary pathnames in<P>
|
|
many situations. User programs that deal with wildcard pathnames would<P>
|
|
have to operate on implementation-dependent representations and hence<P>
|
|
would not be easily portable.<P>
|
|
<P>
|
|
The biggest cost is that the logical pathnames proposal would be stymied.<P>
|
|
<P>
|
|
<B>Performance Impact:<P>
|
|
</B><P>
|
|
None.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
A more complete set of wildcard <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> operations. Portable user<P>
|
|
programs that deal with wildcard pathnames will be more consistent<P>
|
|
and reliable. A portable system construction tool can be written<P>
|
|
and the foundations are laid for a `logical <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>' facility<P>
|
|
(proposed separately in <A HREF="iss259.htm">PATHNAME-LOGICAL</A>).<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
This change would make some portable code less kludgey.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
There was some question about the name. The name PATHNAME-WILD-P<P>
|
|
suggests a ``slot'' of a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> (like <A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-host"><B>PATHNAME-HOST</B></A>),<P>
|
|
while <A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> suggests a type (like <A REL=DEFINITION HREF="../Body/f_in_stm.htm#input-stream-p"><B>INPUT-STREAM-P</B></A>).<P>
|
|
The committee was split on what to call it. Since it is more<P>
|
|
like a type than a slot, the name <A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> was chosen.<P>
|
|
<P>
|
|
It's been suggested that <A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> and <A REL=DEFINITION HREF="../Body/f_pn_mat.htm#pathname-match-p"><B>PATHNAME-MATCH-P</B></A> be allowed<P>
|
|
to return a value other than T to represent "truth", which would<P>
|
|
somehow encode some additional information.<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|