Here we go again. More CMUCL/ACL pathname differences.
robert_...@yahoo.com
The translation is:
(setf (logical-pathname-translations "lisp")
`(("source;**;*" ,(make-pathname :directory
'(:absolute "home" "rmiles"
"code" "lisp"
"source" :wild-inferiors)
:name :wild
:type "lisp"))
("source;**;*.*" ,(make-pathname :directory
'(:absolute "home" "rmiles"
"code" "lisp"
"source" :wild-inferiors)
:name :wild
:type "lisp"))))
For CMUCL:
* (translate-logical-pathname "lisp:source;foo")
#p"/home/rmiles/code/lisp/source/foo.lisp"
For ACL:
USER(14): (translate-logical-pathname "lisp:source;foo")
#p"/home/rmiles/code/lisp/source/foo"
The hyperspec doesn't go into great detail about :wild-inferiors so I don't
know if ACL's behavior is in violation of the standard or not. Anyways,
someone posted a way to do what I want that happens to work with both ACL and
CMUCL. If there was a standard defined way to do it, it would be nice, but
there isn't. And I can live with the current way that does work with both
that depends on implementation-defined behavior.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Sunil Mishra
> Sunil's example works on CMUCL, but fails on ACL.
I'd venture then to say that ACL is broken. The translation process ought
to use everything in the translation as a default, if not specified in the
logical pathname. The first translation instructs Lisp to use "lisp" as the
default type, if not supplied. The second instructs it to use "lisp" as the
type, no matter what is supplied. I believe this is obvious in the spec,
though I don't have the time right now to dig up the relevant quotes.
> The hyperspec doesn't go into great detail about :wild-inferiors so I don't
> know if ACL's behavior is in violation of the standard or not. Anyways,
> someone posted a way to do what I want that happens to work with both ACL and
> CMUCL. If there was a standard defined way to do it, it would be nice, but
> there isn't. And I can live with the current way that does work with both
> that depends on implementation-defined behavior.
:wild-inferiors instructs lisp to apply the pathname translation to all
subdirectories, not just the current directory. It ought not affect how the
type is handled. It is a general pathname construct in lisp, not just for
logical pathnames. For example,
(directory "/**/*.lisp")
should generate a list of every lisp file on your hard drive.
Sunil
robert_...@yahoo.com
Sunil Mishra <smi...@whizzy.cc.gatech.edu> wrote:
> For example,
>
> (directory "/**/*.lisp")
>
> should generate a list of every lisp file on your hard drive.
Ha ha! This (sorta) works on ACL but fails on CMUCL. Will this stupid pathname
inconsistency crap ever end?
Erik Naggum
| Will this stupid pathname inconsistency crap ever end?
only if you want it to. CMUCL is freeware, so you fix it. Franz Inc
engineers may want to satisfy real customer needs. present your case in
a bug report. perhaps I can fix it if I feel like it, but I don't
generally feel like helping people who don't give me an impression of
being satisfied if whatever they were complaining about does get fixed.
so, what would it take for you stop calling it "inconsistency crap"? do
you have a clear idea what every single piece of the pathname stuff
should do? if not, if somebody fixes one thing and you stumble upon
another problem, would you come back with another "inconsistency crap"
complaint? what if your complaints are themselves inconsistent?
#:Erik
robert_...@yahoo.com
I would have liked if the Common Lisp pathname stuff didn't leave so much to
the implementation. For example, how do you find out portably whether or not
a pathname is a valid logical pathname namestring without possibly signalling
an error (calling translate-logical-pathname on it would do the trick but if
it's not valid you get an error)? How do you find out portably if a supplied
physical pathname namestring is a directory or a file? There is no
`directory-p'. How do you portably map all files with an unspecified type to
default type? How do you portably list all files and directories recursively
from a given point? All of these features are provided natively to nearly
every file system around and a portable API to these features that every file
system has could have been implemented but instead we have what I think is
total crap.
I'd love to use CL instead of PERL or the 50% solution for scripting but I
have to use PERL or SH as the glue between the CL modules e.g:
#!/bin/sh
lisp -eval '(load ...)'
So that I have real filesytem control.
No Erik, I don't want you to waste your time fixing anything. It's beyond
fixing. I remember someone mentioning that Genera had a truly sophisticated
portable file-system API but it was deemed too complex for inclusion into
Common Lisp. Maybe someone should get the documentation for the API and then
make an implementation for it that can with some work run on all the major
systems and thus allow it's use to be pervasive and then provide a "Naggum"
license for it that makes it free for non-commercial use and allows
reasonable licensing negotiations for unrestricted commercial use while
ensuring that one standard is maintained. How about you, Erik?
What's going on with the language specification anyways? Is there going to be
another revision or ANSI update in a few years? Could this crap get fixed
then?
Yes, if what I'm bitching about gets fixed then I'll be truly satisfied.
Other than this filesystem crap CL is the greatest language there is. I've
seen plenty of moaning over equal lately but it hasn't bothered me (yet...).
Christopher R. Barry
> I would have liked if the Common Lisp pathname stuff didn't leave so
> much to the implementation. For example, how do you find out
> portably whether or not a pathname is a valid logical pathname
> namestring without possibly signalling an error (calling
> translate-logical-pathname on it would do the trick but if it's not
> valid you get an error)? How do you find out portably if a supplied
> physical pathname namestring is a directory or a file? There is no
> `directory-p'.
With some work, this situation could be remedied:
(defun directory-p (path)
"If PATH is a directory then return it's truename, else return NIL."
(let ((directory-delimeter
#+UNIX "/"
#+WINDOWS "\\" ;FIXME: In *features* for WinXX?
#+MCL ":" ;FIXME: Make work for any Macintosh CL.
#+GENERA ">" ;FIXME: Delete me if this is correct.
))
;; PROBE-FILE will return a truename if an argument with a
;; trailing pathname delimeter is a directory, else NIL.
(probe-file
;; If the file already has a trailing delimiter don't append
;; another one to it, else append it.
(if (string-equal (subseq (namestring path)
(1- (length (namestring path))))
directory-delimeter)
path
(concatenate 'string (namestring path) directory-delimeter)))))
Can people with non-unix implementations make the above work right?
One thing that would be nice is if the above function could take
logical pathname arguments but for reasons cited in the previous
article this is not possible to do portably and I think it would take
a lot of work. I'd like to have a LOGICAL-PATHNAME-P so that I could
know that the argument I pass to TRANSLATE-LOGICAL-PATHNAME won't give
an error. Anyone got a flash of insight as to how to implement this?
> How do you portably map all files with an unspecified type to
> default type? How do you portably list all files and directories
> recursively from a given point?
The above DIRECTORY-P should hopefully be portable across all major
implementations soon and with that you could do this.
Christopher
Rainer Joswig
> robert_...@yahoo.com writes:
>
> > I would have liked if the Common Lisp pathname stuff didn't leave so
> > much to the implementation. For example, how do you find out
> > portably whether or not a pathname is a valid logical pathname
> > namestring without possibly signalling an error (calling
> > translate-logical-pathname on it would do the trick but if it's not
> > valid you get an error)? How do you find out portably if a supplied
> > physical pathname namestring is a directory or a file? There is no
> > `directory-p'.
>
> With some work, this situation could be remedied:
>
> (defun directory-p (path)
MCL provides CCL:DIRECTORYP .
DIRECTORYP pathname
[Function]
returns true if pathname represents a directory. An error is signalled if
pathname is not a pathname.
> One thing that would be nice is if the above function could take
> logical pathname arguments
CCL:DIRECTORYP works with logical pathnames.
CL-HTTP defines www-utils:pathname-directory-p .
Christopher R. Barry
[...]
> CL-HTTP defines www-utils:pathname-directory-p .
Indeed. In
./acl/server/unix.lisp
./cmucl/server/unix.lisp
./lcl/server/unix.lisp
./lispm/server/lispm.lisp
./lw/server/unix.lisp
./mcl/server/mcl.lisp
It seems that there is a specific extension for testing for a pathname
directory in every CL. It's nice to have this CL-HTTP code that gives
you a common interface to all of them.
Christopher
jon....@totient.demon.co.uk
object and #f"/home/jon/example.lisp" type macro reader. Also, all the normal
file io (unlink etc) commands worked, the file permissions were easily
accessible and settable. Also there were functions for symlinks and
directories. The functions had a unix type flavour but were portable across
to win32 platforms. Perhaps Harley can elucidate further? Maybe we should
port this type of interface, as an alternative.
Jon
PS Any chance of a glibc (libc6) port of Talk for linux?
Nick Levine
> "If PATH is a directory then return its truename, else return NIL."
> (let ((directory-delimeter
> #+UNIX "/"
> #+WINDOWS "\\"
> #+GENERA ">"
> ))
> (probe-file
> (if (string-equal (subseq (namestring path)
> (1- (length (namestring path))))
> directory-delimeter)
> path
> (concatenate 'string (namestring path) directory-delimeter)))))
>
> Can people with non-unix implementations make the above work right?
I checked this with Lispworks (version 4.1 on Windows) and it works as-is. Also
checked with Lispworks on Unix and Liquid CL, again your code works as-is.
> One thing that would be nice is if the above function could take
> logical pathname ... I'd like to have a LOGICAL-PATHNAME-P so that I could
> know that the argument I pass to TRANSLATE-LOGICAL-PATHNAME won't give
> an error. Anyone got a flash of insight as to how to implement this?
Probably by knowing the internal function each implementation uses?
#+lispworks system::logical-pathname-p ; tested in 4.1 releases
#+liquid liquid::logical-pathname-p ; from next release
Hope this helps.
- nick
Erik Naggum
| I would have liked if the Common Lisp pathname stuff didn't leave so much
| to the implementation.
so you want more access to the native file system, is that it? that's OK
-- every Common Lisp programmer does that, and gets it. what _I_ don't
get is why you are surprised that you cannot do this _portably_. Common
Lisp is not a Unix language, nor a Bill Gates "innovation". it predates
both, see? at the time Common Lisp was defined file systems far superior
to what we are used to were the norm, and they differed greatly amongst
themselves. the Bill Gates "innovation" doesn't differ from Unix except
in stupid details like / vs \, so it's easy for someone today to think
that he should have access to all these things. the fact is: he has, but
not in the COMMON-LISP package.
| For example, how do you find out portably whether or not a pathname is a
| valid logical pathname namestring without possibly signalling an error
| (calling translate-logical-pathname on it would do the trick but if it's
| not valid you get an error)?
you are confusing pathnames and namestrings. that's a particularly
stupid thing to do considering your clamoring about how crappy the stuff
you obviously don't understand is. your particular case is pretty damn
easy: call PARSE-NAMESTRING, if the result is of type LOGICAL-PATHNAME,
it was a valid logical pathname namestring. of course, you catch parsing
errors with a simple IGNORE-ERRORS wrapper around that call.
| How do you find out portably if a supplied physical pathname namestring
| is a directory or a file?
again, you call PARSE-NAMESTRING. then you see if FILE-NAMESTRING is NIL.
| There is no `directory-p'.
oh, you mean whether a Unix filename really names a directory? well,
this is one of the great mysteries of Unix. originally, you could use
`cat' on a directory and look at the bytes. you can no longer do that.
Unix's very famous "everything is a file" concept has broken down, but
not quite. on other operating systems, you had to specify a different
pathname to get at the actual directory file, it wasn't just a matter of
using a different operation on the same pathname. Unix's simplicity has
fooled you into believing something that simply does not _portably_ hold
and now you blame Common Lisp for it. how fucking intelligent of you.
| How do you portably map all files with an unspecified type to default
| type?
so you've had a little problem here. let's solve that problem for you,
provided that you want it solved and don't just want an eternal excuse.
some other whining losers who have posted here don't really want their
solutions solved, they want something to whine about, so they can go back
to write in Perl. all they need is an _excuse_ not to go Common Lisp,
and latching onto some stupid little thing that isn't "portable" is
enough for them to discard Common Lisp entirely. pretty amazing, really,
and probably worth a PhD in psychology.
| How do you portably list all files and directories recursively from a
| given point?
well, what have you tried? show us. why did it fail?
| All of these features are provided natively to nearly every file system
| around and a portable API to these features that every file system has
| could have been implemented but instead we have what I think is total
| crap.
the problem is primarily your attitude. this is a technical problem, so
it has technical solutions. getting it into the standard is a _separate_
issue.
| I'd love to use CL instead of PERL or the 50% solution for scripting but
| I have to use PERL or SH as the glue between the CL modules e.g:
|
| #!/bin/sh
| lisp -eval '(load ...)'
|
| So that I have real filesytem control.
so you're incompetent at using your Common Lisp system. how surprising.
| No Erik, I don't want you to waste your time fixing anything.
fixing things isn't a waste of time.
| It's beyond fixing.
you're not the person I'd trust with such a clear-cut technical answer.
you simply confuse politics with engineering, and that is not conducive
to either technical or political answers.
| I remember someone mentioning that Genera had a truly sophisticated
| portable file-system API but it was deemed too complex for inclusion into
| Common Lisp. Maybe someone should get the documentation for the API and
| then make an implementation for it that can with some work run on all the
| major systems and thus allow it's use to be pervasive and then provide a
| "Naggum" license for it that makes it free for non-commercial use and
| allows reasonable licensing negotiations for unrestricted commercial use
| while ensuring that one standard is maintained. How about you, Erik?
it isn't horribly difficult to write your own wrappers around the Unix
file system cruft and make it portable for _your_ code. your fixation
with having somebody else do it for you is _really_ digusting.
I actually have all I need in Allegro CL, so I have no urgent need to do
this in the first place. however, I have been working on various pieces
in what should become a Common Lisp "wrapper" for all the insanely
non-portable cruft in the various Unixes, not much different from what
Perl has done for Unix in principle, only this time in a programming
language and with a spec. I call it CLUNIX, pronounced "clue? nix!".
| What's going on with the language specification anyways? Is there going
| to be another revision or ANSI update in a few years? Could this crap
| get fixed then?
look, dude, you are in serious need of attitude readjustment. you don't
get people to work on anything, and especially not for free, if you call
what they do "crap". reserve expressions of your attitude problem till
_after_ you have worked on some of this stuff yourself and have been
turned down for stupid reasons.
| Yes, if what I'm bitching about gets fixed then I'll be truly satisfied.
I see no evidence of that, since you haven't even bothered to learn to
use your existing Common Lisp system. so even if I fix this, I don't
_expect_ you to sit down and learn how to use it properly, but still come
back with whining complaints.
| Other than this filesystem crap CL is the greatest language there is.
and when we fix the filesystem crap, you'll whine about something else
you'll call crap, too, I'm sure. there are lots of flaws and problems in
any environment. your moral stature is measured by whether you have a
constructive element to what you do, and whether somebody else can get at
that constructive element and suggest things you can do. if constructive
suggestions don't work, there is legitimate cause to believe you have no
constructive element at all, and therefore must be treated as destructive.
until next time, your homework assignment is to write a specification for
the file system interface you want. I will call it crap without reading
it, in the spirit of your treatment of the CL pathname system. then we
can discuss it "openly". and finally, we send it all to Scott Adams.
#:Erik
Erik Naggum
| I'd like to have a LOGICAL-PATHNAME-P so that I could know that the
| argument I pass to TRANSLATE-LOGICAL-PATHNAME won't give an error.
| Anyone got a flash of insight as to how to implement this?
(defun logical-pathname-p (pathname)
(typep pathname 'logical-pathname))
chances are the function already exists if PATHNAME and LOGICAL-PATHNAME
are both structures defined with DEFSTRUCT, and you just need APROPOS to
find it. there's nothing inherently evil in using non-exported functions
or functions not in the COMMON-LISP package. you just need to know what
you are doing. that's never a bad thing.
#:Erik
Harley Davis
>object and #f"/home/jon/example.lisp" type macro reader. Also, all the
normal
>file io (unlink etc) commands worked, the file permissions were easily
>accessible and settable. Also there were functions for symlinks and
>directories. The functions had a unix type flavour but were portable across
>to win32 platforms. Perhaps Harley can elucidate further? Maybe we should
>port this type of interface, as an alternative.
One of ILOG Talk's primary goals was to simplify the integration of Lisp
programs with C/C++ programs on de facto standard platforms. This led us to
decde that ILOG Talk's file subsystem would be based largely on Posix; it
included the following functions:
;;; Filename functions
(make-filename <string>) -> <filename>
#f"string" -> <filename>
(filenamep <object>) -> boolean
(string <filename>) -> <string>
(basename <filename> optional: extension) -> <filename>
(extension <filename>) -> <string>
(dirname <filename>) -> <filename>
(device <filename>) -> <string> ; for Windows...
(merge-filenames <filename> <filename> optional: suffix) -> <filename>
;;; File operations, based on Posix
(access <filename> optional: modes) -> boolean ; modes is a list of R_OK,
etc.
(getcwd) -> <filename> ; setf'able
(mkdir <filename>) -> <filename>
(rmdir <filename>) -> <filename>
(rename <filename> <filename>) -> <filename> ; mv arg1 arg2
(tmpnam) -> <filename> ; a gensym for files
(unlink <filename>) -> <filename> ; rm arg1
;;; Functions based on stat()...
(file-ino <filename>) -> <int> ; inode - almost works on NT
(file-dev <filename>) -> <int> ; device - this + inode uniquely identifies
file
(file-nlink <filename>) -> <int> ; # of physical links to a file
(file-size <filename>) -> <int> ; bytes in a file
(file-atime <filename>) -> <time> ; last access time
(file-ctime <filename>) -> <time> ; creation time
(file-mtime <filename>) -> <time> ; modification time
(file-type <filename>) -> <symbol> ; S_ISDIR, S_ISFIFO, etc. based on Posix
macros
;;; Symbolic link stuff - not derived from Posix but quite important.
(file-link-p <filename>) -> boolean
(readlink <filename>) -> <filename> ; follow the link
;;; Etc.
(copy-file <filename> <filename> optional: appendp) -> <filename> ; cp arg1
arg2
(path) -> <list> of <filename> ; used in following fns; setfable
(which <string> optional: <string>) ; searches in path for basename and
optional extension
in-directory: ; used in Talk's "for" macro to loop through files in a
directory
Talk also included a bunch of stream operations based on Posix, including
fopen and the printf family as well as select() and a full set of socket and
pipe functions. Everything was ported between Unix and Windows. We never
considered other platforms as very important in our deliberations.
I thought it was cool, anyway.
-- Harley
>Jon
>PS Any chance of a glibc (libc6) port of Talk for linux?
You'll have to ask Bruno Haible (hai...@ilog.fr), who's taking care of that
stuff. I'm quite distant from it now.
Tim Bradshaw
> What's going on with the language specification anyways? Is there going to be
> another revision or ANSI update in a few years? Could this crap get fixed
> then?
> Yes, if what I'm bitching about gets fixed then I'll be truly satisfied.
> Other than this filesystem crap CL is the greatest language there is. I've
> seen plenty of moaning over equal lately but it hasn't bothered me (yet...).
Well, one way of helping it get fixed would be if people who find it a
problem tried to come up with a proposed set of changes (which should
be upwards compatible) which would make things better, and then making
them available for other people to comment on. That's really a much
better approach than just saying `this is crap'. If people want the
language to improve then acting positively like this is a good way of
helping that happen. Of course it's also a much *harder* approach
than just whinging, because it often turns out that these things are
pretty hard to get right.
--tim
Christopher R. Barry
> * cba...@2xtreme.net (Christopher R. Barry)
> | I'd like to have a LOGICAL-PATHNAME-P so that I could know that the
> | argument I pass to TRANSLATE-LOGICAL-PATHNAME won't give an error.
> | Anyone got a flash of insight as to how to implement this?
>
> (defun logical-pathname-p (pathname)
> (typep pathname 'logical-pathname))
>
USER(8): (defun logical-pathname-p (pathname)
(typep pathname 'logical-pathname))
LOGICAL-PATHNAME-P
USER(9): (logical-pathname-p "sys:hosts.cl")
NIL
USER(10): (translate-logical-pathname "sys:hosts.cl")
#p"/usr/local/acl5/hosts.cl"
CL-HTTP has a way that works really well though.
Christopher
Lyman S. Taylor
Christopher R. Barry <cba...@2xtreme.net> wrote:
>USER(9): (logical-pathname-p "sys:hosts.cl")
^^^^^^^^^^^^^^
This is a string (or a simple-array of characters).
Not a pathname.
USER(18): (make-pathname :host "sys" :name "hosts" :type "cl" )
#p"sys:hosts.cl"
USER(19): (typep * 'logical-pathname )
T
The #P in front means it is a pathname. You can use write the literal
pathname to #p"sys.hosts.cl"
Fortunately, the translate-logical-pathname function can do a implicit
conversion to an actual pathname.
--
Lyman S. Taylor "Twinkie Cream; food of the Gods"
(ly...@cc.gatech.edu) Jarod, "The Pretender"
Christopher R. Barry
> In article <877lusu...@2xtreme.net>,
> Christopher R. Barry <cba...@2xtreme.net> wrote:
>
> >USER(9): (logical-pathname-p "sys:hosts.cl")
> ^^^^^^^^^^^^^^
>
> This is a string (or a simple-array of characters).
> Not a pathname.
Whoops.... Thanks, I've been bitten by this issue before and should
have learned by now. (It was the other way around, I wrote code that
assumed that a pathname passed to it was a of type SIMPLE-ARRAY of
CHARACTER, and taking the length of #P"sys:hosts.cl" won't work).
Christopher
Erik Naggum
| (typep pathname 'logical-pathname))
| LOGICAL-PATHNAME-P
why do you expect a string to be a pathname?
do you expect (null "()") to return true, too?
#:Erik
Christopher R. Barry
> * cba...@2xtreme.net (Christopher R. Barry)
> | USER(8): (defun logical-pathname-p (pathname)
> | (typep pathname 'logical-pathname))
> | LOGICAL-PATHNAME-P
> | USER(9): (logical-pathname-p "sys:hosts.cl")
> | NIL
>
> why do you expect a string to be a pathname?
>
Because in practice most of the time it doesn't make a difference for
many of the functions if their argument is logical-pathname or a
SIMPLE-STRING of type CHARACTER that denotes a logical-pathname
namestring (if that's even the proper terminology).
USER(22): (pathname-host "lisp:code;foo")
"lisp"
I've gotten into the bad habit of using them interchangably, but now
I'm less assuming. I find there are many pitfalls like this in this
huge language (or small language with huge standard library if that's
how you prefer to look at it).
> do you expect (null "()") to return true, too?
Hmm... no. Maybe (null (read-from-string "()")) though.
Christopher
vnik...@poboxes.com
> | argument I pass to TRANSLATE-LOGICAL-PATHNAME won't give an error.
> | Anyone got a flash of insight as to how to implement this?
>
> (typep pathname 'logical-pathname))
Isn't (something like) LOGICAL-PATHNAME-NAMESTRING-P really
what is needed? That's not so trivial.
On a related issue:
Wasn't it Erik Naggum who wrote that ACL has #L precisely
because sometimes one wants to force a namestring to be
parsed as a logical pathname.
By the way, would (PROBE-FILE "foo/.") do the directory-p
test in a Unix CL? (And in a Microsoft environment, I _think_
probing "foo\\con" might work, at least it did with some
versions of MSDOS.)
Have a nice day or night,
Vassil.
Vassil Nikolov <vnik...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
vnik...@poboxes.com
Nick Levine <ni...@harlequin.co.uk> wrote:
> > (defun directory-p (path)
> > "If PATH is a directory then return its truename, else return NIL."
> > (let ((directory-delimeter
> > #+UNIX "/"
> > #+WINDOWS "\\"
> > #+MCL ":"
> > #+GENERA ">"
> > ))
> > (probe-file
> > (if (string-equal (subseq (namestring path)
> > (1- (length (namestring path))))
> > directory-delimeter)
> > path
> > (concatenate 'string (namestring path) directory-delimeter)))))
> >
> > Can people with non-unix implementations make the above work right?
Instead of introducing OS dependence (with all those #+ delimiters),
I'd rather parse the namestring, then, if the filename+filetype
components are not empty, would make a new pathname object with
file{name,type} nil and the original file{name,type} appended
to the pathname-directory list.
In CL, manipulating pathnames is _not_ about manipulating strings
(unless the implementation of PARSE-NAMESTRING is broken, which
normally it isn't) but about manipulating pathname structures
in a (rather) OS-independent way.
Erik Naggum
| many of the functions if their argument is logical-pathname or a
| SIMPLE-STRING of type CHARACTER that denotes a logical-pathname
| namestring (if that's even the proper terminology).
the technical term is pathname designator. I love designators, myself,
but I go out of my way to read the specification and know when I'm using
a designator and when I'm using the real object, specifically by knowing
what types the function _really_ takes. I think this is much easier than
having to deal with the obvious problems resulting from confusing a type
with the set of types of designators for that type.
| I've gotten into the bad habit of using them interchangably, but now I'm
| less assuming.
you should be able to, most of the time, but when you ask for specific
details about the _type_, you can no longer assume that some function
will magically "know" that you want what it might designate to some other
function. "lisp:code;fun" is a string and nothing but a string. a
string is a pathname designator and functions that expect a pathname will
accept a string to make your life easier. when this designator business
makes people's lives harder, it's time for those people to stop using
them and go back to using the real object types and to read the spec to
see what kind of argument types the functions they call actually take.
I think good Common Lisp programmers implement designators to make their
own lives easier, too, but it takes a little extra effort in the code to
be able to handle designators, but I'd imagine that some macro or other
would take care of these things.
| I find there are many pitfalls like this in this huge language (or small
| language with huge standard library if that's how you prefer to look at
| it).
one man's convenience is another man's pitfall, obviously, but it's not
something that happens by random. you chose to ignore the specification
and stumble ahead with whatever "works". that's how pitfalls are made.
| > do you expect (null "()") to return true, too?
|
| Hmm... no. Maybe (null (read-from-string "()")) though.
I expect you see the need to call PARSE-NAMESTRING on the string, too.
#:Erik
Erik Naggum
| Isn't (something like) LOGICAL-PATHNAME-NAMESTRING-P really
| what is needed? That's not so trivial.
sigh.
(defun logical-pathname-namestring-p (namestring)
(typep (ignore-errors (parse-namestring namestring)) 'logical-pathname))
| On a related issue:
| Wasn't it Erik Naggum who wrote that ACL has #L precisely
| because sometimes one wants to force a namestring to be
| parsed as a logical pathname.
care to share the intermediate assumptions and/or your conclusions that
might tie this unrelated "issue" to something? I actually think you're
missing something really fundamental to parsing namestrings, and it would
be a boon for everyone if you would realize it and try to understand,
especially for me if you are going to continue to post "related issues"
that aren't but which inexplicably refer to something I have said which
you obviously didn't understand, either.
#:Erik
Erik Naggum
| Instead of introducing OS dependence (with all those #+ delimiters), I'd
| rather parse the namestring, then, if the filename+filetype components
| are not empty, would make a new pathname object with file{name,type} nil
| and the original file{name,type} appended to the pathname-directory list.
that was _almost_ code.
(defun pathname-as-directory (pathname)
(setq pathname (pathname pathname))
(let ((filename (file-namestring pathname)))
(if filename
(make-pathname :defaults pathname
:directory (append (pathname-directory pathname)
(list filename))
:name nil :type nil :version nil)
pathname)))
#:Erik
vnik...@poboxes.com
Erik Naggum <er...@naggum.no> wrote:
> * vnik...@poboxes.com
> | Instead of introducing OS dependence (with all those #+ delimiters), I'd
> | rather parse the namestring, then, if the filename+filetype components
> | are not empty, would make a new pathname object with file{name,type} nil
> | and the original file{name,type} appended to the pathname-directory list.
>
> that was _almost_ code.
My father liked to say on similar occasions, sapienti sat.
(I got my weakness for Latin from him.)
> (defun pathname-as-directory (pathname)
> (setq pathname (pathname pathname))
> (let ((filename (file-namestring pathname)))
> (if filename
> (make-pathname :defaults pathname
> :directory (append (pathname-directory pathname)
> (list filename))
> :name nil :type nil :version nil)
> pathname)))
Precisely. (Sorry for getting the indentation screwed.)
I like it so much when the language provides the appropriate
primitives (like FILE-NAMESTRING in this example).
>
> #:Erik
>
Have nice times,
Vassil.
vnik...@poboxes.com
> | what is needed? That's not so trivial.
>
> sigh.
>
> (defun logical-pathname-namestring-p (namestring)
> (typep (ignore-errors (parse-namestring namestring)) 'logical-pathname))
Oh well. From the description of PARSE-NAMESTRING in the
HyperSpec:
If thing is a string then the substring of thing bounded
by start and end is parsed into a pathname as follows:
(...) ;first three cases (about logical pathnames) omitted
* Otherwise, the parsing of thing is implementation-defined.
I.e. there are cases where it is implementation-defined whether
the namestring is interpreted as a logical pathname or as an
ordinary pathname. If you really insist, we could go into more
details (but please cc your postings to me as I'm never sure
I'll get to reading the newsgroup).
> | On a related issue:
> | Wasn't it Erik Naggum who wrote that ACL has #L precisely
> | because sometimes one wants to force a namestring to be
> | parsed as a logical pathname.
I guess the wording was inadequate. Second try:
Some namestrings can denote at the same time a logical
pathname and an ordinary one. Sometimes the programmer
may want to control or override the implementation's
choice of one interpretation over the other, for which
#P is not sufficient. Probably that was why ACL
introduced the #L reader syntax. (I don't use ACL
myself but I have learned from a posting by Erik Naggum
that ACL has that syntax.)
> care to share the intermediate assumptions and/or your conclusions that
See above.
> might tie this unrelated "issue" to something? I actually think you're
> missing something really fundamental to parsing namestrings, and it would
> be a boon for everyone if you would realize it and try to understand,
> especially for me if you are going to continue to post "related issues"
> that aren't but which inexplicably refer to something I have said which
> you obviously didn't understand, either.
^^^^^^^^^
I love this word. (In mathematics, if something isn't obvious,
it is elementary.)
Of course, there are probably many things I don't understand
(correctly), but I wish it were obvious which ones, at least to
myself...
Christopher R. Barry
> * vnik...@poboxes.com
> | Instead of introducing OS dependence (with all those #+ delimiters), I'd
> | rather parse the namestring, then, if the filename+filetype components
> | are not empty, would make a new pathname object with file{name,type} nil
> | and the original file{name,type} appended to the pathname-directory list.
>
> that was _almost_ code.
>
> (defun pathname-as-directory (pathname)
> (setq pathname (pathname pathname))
> (let ((filename (file-namestring pathname)))
> (if filename
> (make-pathname :defaults pathname
> :directory (append (pathname-directory pathname)
> (list filename))
> :name nil :type nil :version nil)
> pathname)))
>
> #:Erik
On CMU Common Lisp, this still works, but
* (pathname-as-directory #p"/home/")
#p"/home//"
(Not that it really matters, just aesthetics. A lot of the Debian
system scripts do this.)
Christopher
Erik Naggum
| I.e. there are cases where it is implementation-defined whether the
| namestring is interpreted as a logical pathname or as an ordinary
| pathname.
this is a false statement of fact.
(please call them "physical pathnames", not "ordinary pathname".
there's nothing extraordinary about a logical pathname.)
| Some namestrings can denote at the same time a logical pathname and an
| ordinary one.
insofar as a physical pathname file-namestring may contain any random
character, this is true, _but_, and this is the part that you should have
understood by now, it is then parsed as a _logical_ pathname. all that
says is that you may want to force a _physical_ pathname. there's no
syntax for that, by the way. if you want a file named "sys:foobar.lisp",
you have to call MAKE-PATHNAME yourself. so your stupid problem is only
a problem because you got the facts reversed.
| Sometimes the programmer may want to control or override the
| implementation's choice of one interpretation over the other, for which
| #P is not sufficient. Probably that was why ACL introduced the #L reader
| syntax. (I don't use ACL myself but I have learned from a posting by
| Erik Naggum that ACL has that syntax.)
what _is_ your beef with this? this is second time you stupidly bring
this up and it has _nothing_ to do with the issue at hand. you don't
understand why Allegro CL has #L, so you _assume_ a lot of bullshit about
it and draw insane conclusions. what does all that crap _do_ for you?
does all of this rest on what you assume into that unwarranted "probably"
of yours? are you really upset that Allegro CL has a #L syntax and all
of this insane drivel of yours is really trying to kick me or Allegro CL
for having something you don't have? is it pure envy? is it some mental
disorder? the realm of the rational is too small to contain your drivel.
here's the fact, if your brain is still capable of dealing with facts now
that the evidence is out that it cannot separate facts from assumptions:
#L calls LOGICAL-PATHNAME on the string following it. some _partial_
(i.e., strictly invalid) logical pathnames are assumed to be complete
with a null logical pathname host. this is useful in stuff like
#L"**;*.*", which is otherwise _not_ a logical pathname namestring, but
which is still forced into that in the context where you find it: which
is in setting up logical pathname translations.
the other use for #L is to be nice to the intelligent reader who doesn't
get confused by it and go off rambling like a moron, which you have done.
like designators, it's a service to people who know what they are doing.
life is not a tutorial, and if you are the kind of person to base your
life on guesses and unwarranted assumptions, it should hurt when your
guesses are wrong. just because it hasn't hurt so far doesn't mean you
have never made wrong guesses. more likely, nobody cared to tell you.
| See above.
it should have been clear that I wanted you to explain them, not make
_more_ unwarranted assumptions. damn it, don't you even _know_ when you
make assumptions?
| Of course, there are probably many things I don't understand (correctly),
| but I wish it were obvious which ones, at least to myself...
it would have been if you had paid attention.
#:Erik
Erik Naggum
|
| * (pathname-as-directory #p"/home/")
| #p"/home//"
huh? FILE-NAMESTRING of #p"/home/" is _not_ NIL in CMUCL?
#:Erik
Peter Van Eynde
It's "". I see nowhere a requirement for it to return NIL. It is allowed,
but not required I think.
Groetjes, Peter
--
It's logic Jim, but not as we know it. | pvan...@debian.org for pleasure,
"God, root, what is difference?",Pitr | pvan...@inthan.be for more pleasure!
Raymond Toy
Erik> * cba...@2xtreme.net (Christopher R. Barry)
Erik> | On CMU Common Lisp, this still works, but
Erik> |
Erik> | * (pathname-as-directory #p"/home/")
Erik> | #p"/home//"
Hmm, I get #p"/home/" as the answer.
Erik> huh? FILE-NAMESTRING of #p"/home/" is _not_ NIL in CMUCL?
On my version (file-namestring #p"/home/") returns "". A quick read of
CLHS says file-namestring returns a namestring. NIL is not a
namestring is it?
Ray
Felix Winkelmann
>
> ... you stupidly bring this up
> ... and draw insane conclusions.
> ... is it some mental disorder?
> ... if your brain is still capable of dealing with facts now that the
> evidence is out that it cannot separate facts from assumptions
> rambling like a moron, which you have done.
> ...
Why do you get so excited?
You don't have to take this personally.
Erik Naggum
| On my version (file-namestring #p"/home/") returns "". A quick read of
| CLHS says file-namestring returns a namestring. NIL is not a namestring
| is it?
ok, so I'm _extra_ annoyed by illiterates lately, but can you guys please
do me a f*cking favor and do your own homework, like looking for this
line in the standard or HyperSpec under FILE-NAMESTRING and friends:
namestring---a string or nil.
that's the return value from FILE-NAMESTRING.
it isn't reasonable to return a string from any of these functions when
the component or components in question are NIL.
or does CMUCL return "" from (pathname-name #p"/home/"), too? how about
(host-namestring #p"/home/") or (directory-namestring #p"foo.bar")?
#:Erik
Rob Warnock
+---------------
| ...or does CMUCL return "" from (pathname-name #p"/home/"), too?
| how about (host-namestring #p"/home/") or (directory-namestring #p"foo.bar")?
* (FILE-NAMESTRING #p"/home/")
""
* (pathname-name #p"/home/")
NIL
* (host-namestring #p"/home/")
"Unix"
* (directory-namestring #p"foo.bar")
""
*
-Rob
-----
Rob Warnock, 8L-855 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
Erik Naggum
| Why do you get so excited?
obviously, because I care. no, I don't have to care, either, but if I
didn't care, why the hell would I spend any time at all trying to learn
new stuff from others as well as help those who want to learn something I
know? since I do care, I think those who pretend to want to learn, but
really only want others to do their homework for them, are posting on
fraudulent terms. I don't think people should get away with fraud. I'm
sure you think it's none of your business, until _you_ get defrauded, but
then you'll expect somebody else to care about it, like the police or
whatever, but you can't take every fraud to the police, and if you don't
react to small fraud, you pave the way for big fraud.
I'm sure you don't understand any of this. why should _you_ care?
#:Erik
Erik Naggum
| * (FILE-NAMESTRING #p"/home/")
|
| ""
| * (pathname-name #p"/home/")
|
| NIL
| * (host-namestring #p"/home/")
|
| "Unix"
| * (directory-namestring #p"foo.bar")
|
| ""
I thought we already had the convention that the empty _list_ was
"nothing", but CMUCL apparently thinks its better to introduce typed
nothings, like empty strings, too. sigh.
so, fine, let's test for the empty string in CMUCL, instead. it gives
the function a distinctly Scheme-ish flavor as in (not (null? x)), but
what the heck, it's free software.
(if #+cmucl (< 0 (length file-namestring))
#-cmucl file-namestring
...)
the length test would work everywhere, but I want an empty string to be
_different_ from no string.
#:Erik
Felix Winkelmann
>
> I think those who pretend to want to learn, but
> really only want others to do their homework for them, are posting on
> fraudulent terms. I don't think people should get away with fraud.
>
I think you are a bit too fast in accusing people of fraud
who are just making suggestions or asking harmless questions.
Erik Naggum
| I think you are a bit too fast in accusing people of fraud who are just
| making suggestions or asking harmless questions.
feel free to volunteer all the information you want. why haven't you?
maybe it's because you don't care about that, either?
fraud -- an intentional perversion of truth for the purpose of inducing
another in reliance upon it to part with some valuable thing belonging to
him or to surrender a legal right. a false representation of a matter
of fact, whether by words or by conduct, by false or misleading
allegations, or by concealment of that which should have been disclosed,
which deceives and is intended to deceive another so that he shall act
upon to his legal injury. anything calculated to deceive, whether by a
single act or combination, or by suppression of truth, or suggestion or
what is false, whether it be by direct falsehood or innuendo, by speech
or silence, word of mouth or look or gesture.
that's Black's law dictionary introducing the concept.
I view time as a valuable asset, answering a question with technical
answers that any conscientious person would know are wrong as false
representation of a matter of act, and posting under false pretenses as
concealment of that which should have been disclosed. asking others to
help you when your real purpose is to avoid doing your homework, is
fraud. not making sure you know that what you have posted is correct,
yet make it appear that it is, is fraud. inducing somebody to help you
when you will not accept the responsibility of learning from it, is fraud.
in a world where information is becoming a currency, there are a lot of
counterfeiters who can't understand that what they are doing is wrong.
are you one of those? it looks that way from my point of view.
a dejanews search on your fairly unique name returns 5 messages. may I
ask why you get so excited about my article that you had to post your
message to begin with? you seem to care about meaningless issues, but
not about any serious issues related to this newsgroup or the Common Lisp
programming language at all. yet you have the right to question why
_others_ care? I think that is basically fraudulent of you, too.
#:Erik
Juanma Barranquero
Hash: SHA1
On 14 Jan 1999 12:58:47 -0500, Raymond Toy <t...@rtp.ericsson.se>
wrote:
>A quick read of CLHS says file-namestring returns a namestring.
>NIL is not a namestring is it?
"namestring" is defined a few lines below as "a string or nil".
/L/e/k/t/u
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.5.3i; see <http://www.pgpi.com>
iQA/AwUBNp777/4C0a0jUw5YEQKb2ACgkIBzJHkIIPJF3n1ivoLGuNIJ378AoMQs
6cw1K1lUgyj3/KaraPnfqhfj
=Q1vQ
-----END PGP SIGNATURE-----
vnik...@poboxes.com
Erik Naggum <er...@naggum.no> wrote:
> * vnik...@poboxes.com
> | I.e. there are cases where it is implementation-defined whether the
> | namestring is interpreted as a logical pathname or as an ordinary
> | pathname.
>
> this is a false statement of fact.
Is it true that in the case of
(parse-namestring "foo;bar.baz" nil (make-pathname :host nil
:device nil
:directory nil
:name nil
:type nil
:version nil))
(with a semicolon between foo and bar---no explicit host)
it is implementation-dependent if the string will be parsed
as a logical pathname namestring?
I said that the answer is yes (implementation-dependent);
if you say the answer is no, would you please demonstrate why not?
> (please call them "physical pathnames", not "ordinary pathname".
> there's nothing extraordinary about a logical pathname.)
Indeed, I should not have used `ordinary'; I should have used
`physical' (there was no misunderstanding though, was there).
> | Some namestrings can denote at the same time a logical pathname and an
> | ordinary one.
>
> insofar as a physical pathname file-namestring may contain any random
> character, this is true, _but_, and this is the part that you should have
> understood by now, it is then parsed as a _logical_ pathname. all that
> says is that you may want to force a _physical_ pathname. there's no
> syntax for that, by the way. if you want a file named "sys:foobar.lisp",
> you have to call MAKE-PATHNAME yourself. so your stupid problem is only
> a problem because you got the facts reversed.
There are two cases:
(1) X is parsed as a logical pathname namestring but the programmer
would like it to be parsed as a physical pathname namestring;
(2) X is parsed as a physical pathname namestring but the programmer
would like it to be parsed as a logical pathname namestring.
Above, you discuss (1), don't you? My concern, however, was with (2).
(Why did you write as if my concern was with (1)?)
(One more thing: although (1) is not my problem, it could well
be somebody's problem when namestrings are supplied to a program
from outside as data (at run-time). The one who supplies them
may want them to be treated as physical pathnames.)
> | Sometimes the programmer may want to control or override the
> | implementation's choice of one interpretation over the other, for which
> | #P is not sufficient. Probably that was why ACL introduced the #L reader
> | syntax. (I don't use ACL myself but I have learned from a posting by
> | Erik Naggum that ACL has that syntax.)
>
> what _is_ your beef with this? this is second time you stupidly bring
> this up and it has _nothing_ to do with the issue at hand. you don't
> understand why Allegro CL has #L, so you _assume_ a lot of bullshit about
> it and draw insane conclusions. what does all that crap _do_ for you?
>
> does all of this rest on what you assume into that unwarranted "probably"
> of yours? are you really upset that Allegro CL has a #L syntax and all
> of this insane drivel of yours is really trying to kick me or Allegro CL
> for having something you don't have? is it pure envy? is it some mental
On the contrary, I find it a good thing that ACL has #L.
What makes you ask if I am envious of ACL?
> disorder? the realm of the rational is too small to contain your drivel.
>
> here's the fact, if your brain is still capable of dealing with facts now
> that the evidence is out that it cannot separate facts from assumptions:
:-)
> #L calls LOGICAL-PATHNAME on the string following it. some _partial_
> (i.e., strictly invalid) logical pathnames are assumed to be complete
> with a null logical pathname host. this is useful in stuff like
> #L"**;*.*", which is otherwise _not_ a logical pathname namestring, but
Would you please explain why this is not a logical pathname namestring?
Is "foo;bar;baz.quux" a logical pathname namestring?
The syntax for logical pathname namestring makes the host part
optional.
> which is still forced into that in the context where you find it: which
> is in setting up logical pathname translations.
>
> the other use for #L is to be nice to the intelligent reader who doesn't
> get confused by it and go off rambling like a moron, which you have done.
:-)
One more thing:
In article <31252184...@naggum.no>,
Erik Naggum <er...@naggum.no> wrote:
> * vnik...@poboxes.com
> | Isn't (something like) LOGICAL-PATHNAME-NAMESTRING-P really
> | what is needed? That's not so trivial.
>
> sigh.
>
> (defun logical-pathname-namestring-p (namestring)
> (typep (ignore-errors (parse-namestring namestring)) 'logical-pathname))
Now, let me point out one reason why I say that is not so trivial.
PARSE-NAMESTRING needs a <host> and a <default-pathname> (not
supplied above) in order to do the right thing in all cases
when <namestring> should be parsed as a logical pathname namestring.
(This means that LOGICAL-PATHNAME-NAMESTRING-P may also need
additional arguments.)
Erik Naggum
| I said that the answer is yes (implementation-dependent);
| if you say the answer is no, would you please demonstrate why not?
this is entirely faulty reasoning. my point is that the case of the
logical pathname is defined and constrained in the standard. whatever is
left is a candidate for implementation-defined parsing as a physical
pathname, not as a logical pathname, since that has been exhaustively
defined. the case you have brought up is nowhere near the conditions for
parsing as a logical pathname. I have to ask you why you think this is a
valid example in the first place. NIL would have to be a logical host in
some implementations and not in others for this example to make sense, if
I read it right. that is clearly not a tenable position.
| There are two cases:
| (1) X is parsed as a logical pathname namestring but the programmer
| would like it to be parsed as a physical pathname namestring;
| (2) X is parsed as a physical pathname namestring but the programmer
| would like it to be parsed as a logical pathname namestring.
| Above, you discuss (1), don't you? My concern, however, was with (2).
| (Why did you write as if my concern was with (1)?)
because 2 is excluded by the standard and it doesn't make sense to
discuss settled issues. if you were not aware that it was settled,
that's a slightly different discussion than one where you assume it not
settled and want to discuss consequences of it not being settled.
| (One more thing: although (1) is not my problem, it could well be
| somebody's problem when namestrings are supplied to a program from
| outside as data (at run-time). The one who supplies them may want them
| to be treated as physical pathnames.)
true, and this has been what I've been trying to address, since the
reverse situation doesn't happen. it appears to me that a HOST argument
that is neither a logical host nor NIL should force parsing as a physical
pathname.
| Is "foo;bar;baz.quux" a logical pathname namestring?
no. (I assume that this is the crux of your argumentation.)
| The syntax for logical pathname namestring makes the host part optional.
no. the host is optional when _otherwise_ provided to PARSE-NAMESTRING.
all logical pathnames have a logical host as their host component. if it
is optional, it has to come from somewhere, it cannot be assumed, and it
cannot be NIL. physical pathnames, on the other hand, may have a NIL
host component.
| Now, let me point out one reason why I say that is not so trivial.
| PARSE-NAMESTRING needs a <host> and a <default-pathname> (not supplied
| above) in order to do the right thing in all cases when <namestring>
| should be parsed as a logical pathname namestring. (This means that
| LOGICAL-PATHNAME-NAMESTRING-P may also need additional arguments.)
the `default-pathname' argument defaults to *DEFAULT-PATHNAME-DEFAULTS*,
so that's more or less taken care of. if you intend to parse against a
particular logical host and take advantage of the then optional host
component, you ask a different question than "is this a logical pathname
namestring?" your question is now "is this a logical pathname namestring
for the given host?" in other words, you'll get a negative reply to all
logical pathname namestrings that have a host mismatch. I don't think
the function that returns that answer should be called LOGICAL-PATHNAME-
NAMESTRING-P. furthermore, I think PARSE-NAMESTRING is sufficient for
this more complicated case, and I see no reason why it is not sufficient
for the general case, which is why I think nobody has thought of making
it part of the standard.
you may find lower-level functions used to implement PARSE-NAMESTRING
that test for logical pathname namestring syntax if you look for them,
however. I'm not sure it's a good idea to call them from user code even
if you find them.
#:Erik
vnik...@poboxes.com
Erik Naggum wrote:
>
> * vnik...@poboxes.com
> | I said that the answer is yes (implementation-dependent);
> | if you say the answer is no, would you please demonstrate why not?
>
> this is entirely faulty reasoning. my point is that the case of the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Maybe; would you please respond to the issues (1)--(3) below?
> logical pathname is defined and constrained in the standard. whatever is
My point is: after it is decided that a string is a logical pathname
(and the respective logical host established), from that moment on all
is fully specified in the standard. I say, however, that the standard
gives some latitude to implementations regarding making the decision
_if_ a string is a logical pathname, in certain (perhaps non-typical)
cases---(1) and (2) below.
> left is a candidate for implementation-defined parsing as a physical
> pathname, not as a logical pathname, since that has been exhaustively
> defined. the case you have brought up is nowhere near the conditions for
> parsing as a logical pathname. I have to ask you why you think this is a
> valid example in the first place. NIL would have to be a logical host in
> some implementations and not in others for this example to make sense, if
> I read it right. that is clearly not a tenable position.
(1) What in the standard _forbids_ NIL from being a logical host?
My point is not whether it is perverse or not for NIL to be
a logical host. I just have not been able to find anything that
says, or from which it follows, that NIL cannot be a logical
host in any implementation ever. Can you identify such a place or
places in the standard?
(2) What in the standard forbids an implementation from having a
`default logical host of last resort' which would be used for
a parse when all other sources of a logical host for the parse
do not supply one? (`All other sources' are those that are
mentioned in the first three cases that define how parsing
is done when the <thing> argument to PARSE-NAMESTRING is a
string.)
(I have not been able to find a prohibition against having
such a default.)
(3) In my understanding of logical pathnames at least, parsing
a logical pathname namestring is a separate operation from
translating a logical pathname (although typically they
are performed immediately one after the other). Further, my
understanding is that a logical pathname namestring can be
parsed even without a logical host at hand (on the other hand,
translating one, of course, requires having a logical host).
I.e., having decided that it is a logical pathname namestring,
and applying the syntactic rules of such namestrings, I can
produce from "foo;bar;baz.quux" a structure like:
((:directory (:absolute "foo" "bar"))
(:name "baz")
(:type "quux"))
even in the absence of a logical host. (If you ask why I may
want to do that, one possible answer is for merging this with
another pathname.) Can you point me to a place in the standard
that proves that my understanding is incorrect?
(PARSE-NAMESTRING does parsing only without translating, does it
not?)
> | There are two cases:
> | (1) X is parsed as a logical pathname namestring but the programmer
> | would like it to be parsed as a physical pathname namestring;
> | (2) X is parsed as a physical pathname namestring but the programmer
> | would like it to be parsed as a logical pathname namestring.
> | Above, you discuss (1), don't you? My concern, however, was with (2).
> | (Why did you write as if my concern was with (1)?)
>
> because 2 is excluded by the standard and it doesn't make sense to
> discuss settled issues. if you were not aware that it was settled,
> that's a slightly different discussion than one where you assume it not
> settled and want to discuss consequences of it not being settled.
I hope I have made it clear of what I am aware. By responding
to (1)--(3) above, you may point me to something in the standard
of which I am not aware, or which I have failed to interpret in
the right way. But please point me to specific places in the
standard. You have stated your understanding of the matter; I am
asking about how this understanding follows from the standard.
> | (One more thing: although (1) is not my problem, it could well be
> | somebody's problem when namestrings are supplied to a program from
> | outside as data (at run-time). The one who supplies them may want them
> | to be treated as physical pathnames.)
>
> true, and this has been what I've been trying to address, since the
> reverse situation doesn't happen. it appears to me that a HOST
> that is neither a logical host nor NIL should force parsing as a physical
> pathname.
Yes. The programmer must heed the HyperSpec^1 and beware. If the
program
reads at run-time strings that serve as physical pathname namestrings,
and there are logical pathname translations defined and `active,'
PATHNAME should not be used on them as it provides too little control
on whether the namestring is taken to be a logical or a physical one,^2
so the program should call PARSE-NAMESTRING and supply a second
argument
(a physical <host>). If it happens that a logical host has the same
name as a physical host (and the naming of either is be beyond the
control of the programmer), tough luck...
_________________________________________
^1 in 19.1.1: `However, a conforming program can, if it is careful,
successfully manipulate user-supplied data which contains or refers
to non-portable namestrings.'
^2 unless, of course, it is guaranteed that PATHNAME always returns
a physical pathname from a namestring, but I cannot find such a
guarantee
in the standard
> | Is "foo;bar;baz.quux" a logical pathname namestring?
>
> no. (I assume that this is the crux of your argumentation.)
>
> | The syntax for logical pathname namestring makes the host part optional.
>
> no. the host is optional when _otherwise_ provided to PARSE-NAMESTRING.
> all logical pathnames have a logical host as their host component. if it
> is optional, it has to come from somewhere, it cannot be assumed, and it
> cannot be NIL. (...)
For translating a logical pathname, yes; but for parsing? Anyway,
if you respond to (1)--(3) above, then I would have no further
questions
on this.
> | Now, let me point out one reason why I say that is not so trivial.
> | PARSE-NAMESTRING needs a <host> and a <default-pathname> (not supplied
> | above) in order to do the right thing in all cases when <namestring>
> | should be parsed as a logical pathname namestring. (This means that
> | LOGICAL-PATHNAME-NAMESTRING-P may also need additional arguments.)
>
> the `default-pathname' argument defaults to *DEFAULT-PATHNAME-DEFAULTS*,
> so that's more or less taken care of. if you intend to parse against a
> particular logical host and take advantage of the then optional host
> component, you ask a different question than "is this a logical pathname
> namestring?" your question is now "is this a logical pathname namestring
> for the given host?" in other words, you'll get a negative reply to all
> logical pathname namestrings that have a host mismatch. I don't think
> the function that returns that answer should be called LOGICAL-PATHNAME-
> NAMESTRING-P. furthermore, I think PARSE-NAMESTRING is sufficient for
> this more complicated case, and I see no reason why it is not sufficient
> for the general case, which is why I think nobody has thought of making
> it part of the standard.
Indeed, it should have been made clear from the beginning if we are
talking about a function that _either_
(A) tests if a string is a logical pathname namestring with respect
to a _particular_ logical host, _or_ that
(B) tests if there _may_exist_ a logical host with respect to which
a string is a logical pathname namestring.
I still say that (B) is not so trivial. But it is not worth
arguing further (including about the name) unless the need for
such a function arises from a specific problem that we have at hand.
> you may find lower-level functions used to implement PARSE-NAMESTRING
> that test for logical pathname namestring syntax if you look for them,
> however. I'm not sure it's a good idea to call them from user code even
> if you find them.
As usual, if one knows what one is doing...
Have a nice day or night,
Vassil.
Erik Naggum
| (1) What in the standard _forbids_ NIL from being a logical host?
invalid reasoning. you must show where and how the standard _supports_
your position. in brief: its absence from the exhaustively specified set
of allowable logical hosts.
| (2) What in the standard forbids an implementation from having a
| `default logical host of last resort' which would be used for
| a parse when all other sources of a logical host for the parse
| do not supply one?
invalid reasoning. you must show where and how the standard _supports_
your position. in brief, there is no such thing in the standard, and if
there isn't, an implementation that has it, will in some way violate the
standard semantics.
| (3) In my understanding of logical pathnames at least, parsing a logical
| pathname namestring is a separate operation from translating a
| logical pathname (although typically they are performed immediately
| one after the other).
huh? they are _completely_ unrelated tasks. your "typically" does not
apply to any of the code I see that actually uses logical pathnames.
whence your observation?
| Further, my understanding is that a logical pathname namestring can
| be parsed even without a logical host at hand (on the other hand,
| translating one, of course, requires having a logical host).
whence this understanding? (it's false.)
| Can you point me to a place in the standard that proves that my
| understanding is incorrect?
invalid reasoning. you must show where the standard _supports_ your
position. places in the standard define what is correct. if there is no
place in the standard that proves it correct, _then_ it is incorrect.
therefore, there is no place in the standard that proves it incorrect.
the place that proves it incorrect is _outside_ of the standard, if
anywhere. it is the _absence_ of a place in the standard that proves it
correct that proves your proposition incorrect.
| (PARSE-NAMESTRING does parsing only without translating, does it not?)
I fail to see what is unclear about what it does. whence the uncertainty?
| I hope I have made it clear of what I am aware.
no. you apparently think that standards forbid things. they don't.
standards specify exhaustively what's valid and what all the valid stuff
means. everything else is forbidden. if you cannot find support for
your position in the standard, it is ipso facto not _standard_ behavior.
| By responding to (1)--(3) above, you may point me to something in the
| standard of which I am not aware, or which I have failed to interpret in
| the right way. But please point me to specific places in the standard.
| You have stated your understanding of the matter; I am asking about how
| this understanding follows from the standard.
my understanding of _any_ standard comes from having worked on half a
dozen fairly large standards from early draft through to publication, and
from owning copies of standards documents worth more than the average
annual income in Norway. put differently from above yet meaning exatly
the same thing, standards provide the axiomatic framework for a deductive
system of reasoning. definitions, requirements, semantic interpretation,
glossary, etc, are all working together to specify what the authors of
standard intends to be legal and what everything that it says is legal
shall mean. if you cannot reach a conclusion by deduction from what the
standard says is legal, it is _not_ legal. true statements that cannot
be proven are bugs. contradictions are bugs.
| If it happens that a logical host has the same name as a physical host
yeah, I can make out what this nonsense means, but why do I have to?
the less willing you are to use the terminology of the standard, the more
I'm inclined to think that you're fighting the terminology instead of
using it to enhance your understanding of the fairly extensive semantic
web that makes up a large document like the Common Lisp standard.
standards are about _precision_. I find it interminably boring to deal
with people who want the fruits of precision, yet show zero respect for
the foundations of such precision. a standard isn't a document where all
the difficult words are defined as "yeah, whatever", or "you know what I
mean". the effort that goes into writing (editing) a standard is truly
tremendous. in addition, Kent Pitman made this all available in a very
usable hypertext form so that nobody has any excuse _not_ to follow
glossary links and the like.
| ^2 unless, of course, it is guaranteed that PATHNAME always returns a
| physical pathname from a namestring, but I cannot find such a guarantee
| in the standard
PATHNAME returns a `pathname' object [function pathname]. a physical
pathname is a `pathname' that is not a `logical-pathname' [glossary].
the class precedence list for `logical-pathname' is (logical-pathname
pathname t) [system-class logical-pathname].
| For translating a logical pathname, yes; but for parsing?
I haven't been talking about translating. that's maximally irrelevant.
| Indeed, it should have been made clear from the beginning if we are
| talking about a function that _either_
| (A) tests if a string is a logical pathname namestring with respect
| to a _particular_ logical host, _or_ that
| (B) tests if there _may_exist_ a logical host with respect to which
| a string is a logical pathname namestring.
| I still say that (B) is not so trivial. But it is not worth
| arguing further (including about the name) unless the need for
| such a function arises from a specific problem that we have at hand.
what the fuck? you call LOGICAL-PATHNAME-TRANSLATIONS to learn if a
string names a logical host or not! how hard can this be?
| As usual, if one knows what one is doing...
do and know, or don't and learn.
#:Erik
--
SIGTHTBABW: a signal sent from Unix to its programmers at random
intervals to make them remember that There Has To Be A Better Way.
Raymond Toy
Erik> * Raymond Toy <t...@rtp.ericsson.se>
Erik> | On my version (file-namestring #p"/home/") returns "". A quick read of
Erik> | CLHS says file-namestring returns a namestring. NIL is not a namestring
Erik> | is it?
Erik> ok, so I'm _extra_ annoyed by illiterates lately, but can you guys please
Erik> do me a f*cking favor and do your own homework, like looking for this
Erik> line in the standard or HyperSpec under FILE-NAMESTRING and friends:
Erik> namestring---a string or nil.
Erik> that's the return value from FILE-NAMESTRING.
I admit that I only looked at these parts of CLHS:
Syntax:
...
file-namestring pathname => namestring
and
Description:
...
file-namestring returns just the name, type, and version components of pathname.
Since namestring was defined in the glossary, I didn't expect
namestring in this context to mean string or nil.
However, I can also read that CLHS says
These functions convert pathname into a namestring. The name
represented by pathname is returned as a namestring in an
implementation-dependent canonical form.
(I'm sure you knew this, but momentarily forgot.)
So CMUCL can return whatever it feels like.
I do agree, however, that since pathname-name is NIL in this case,
NIL would be a good answer instead of the empty-string.
Ray
vnik...@poboxes.com
Raymond Toy <t...@rtp.ericsson.se> wrote:
(...) ;on (FILE-NAMESTRING #p"foo/") => NIL or ""?
> So CMUCL can return whatever it feels like.
I don't think so (if it wants to conform, that is).
> I do agree, however, that since pathname-name is NIL in this case,
> NIL would be a good answer instead of the empty-string.
NIL *is* the answer because it is a possible return value from
FILE-NAMESTRING and because for missing parts of a namestring, the
respective components of a pathname object are NIL (it's not
difficult to find where the HyperSpec says this).
I don't think CL wants to exclude file systems where the empty
string is a valid file name. (They would need some sort of
escape character syntax when parsing namestrings, of course, to
denote such a (strange) file name.)
Good luck,
Erik Naggum
| I don't think CL wants to exclude file systems where the empty string is
| a valid file name. (They would need some sort of escape character syntax
| when parsing namestrings, of course, to denote such a (strange) file
| name.)
actually, I came across something that implies that the empty string and
nothing are the same for a certain point of view:
Parsing a null string always succeeds, producing a pathname with all
components (except the host) equal to nil.
this is in the dictionary for PARSE-NAMESTRING.
so at least (file-namestring ...) => "" is reversible, but I'd still like
to see some stronger wording to ensure that NIL is the correct answer.
the dictionary for for PARSE-NAMESTRING doesn't say anything about when
to return NIL now. for me, however, the intuitively evident is OK until
people start to object. then I need something more concrete. sigh.
the really pathetic thing here is that Unix used to treat the empty
string as the current directory. that's how a trailing slash worked...
vnik...@poboxes.com
Erik Naggum <er...@naggum.no> wrote:
> * vnik...@poboxes.com
> | (1) What in the standard _forbids_ NIL from being a logical host?
>
> invalid reasoning. you must show where and how the standard
_supports_
> your position. in brief: its absence from the exhaustively
specified set
> of allowable logical hosts.
From the Glossary:
logical host n. an object of implementation-dependent nature...
This does not look like an exhaustively specified set. Can you
point me to this exhaustive specification?
> | (2) What in the standard forbids an implementation from having a
> | `default logical host of last resort' which would be used for
> | a parse when all other sources of a logical host for the parse
> | do not supply one?
>
> invalid reasoning. you must show where and how the standard
_supports_
> your position. in brief, there is no such thing in the standard,
and if
> there isn't, an implementation that has it, will in some way
violate the
> standard semantics.
The standard does not define explicitly _all_ aspects of logical
pathnames. (For example, the definition of the logical host SYS
is implementation-dependent. And isn't it legal for an implementation
to use NIL to represent the logical host whose name us "SYS"?)
Once again: is the case of
(parse-namestring "foo;bar;baz.quux" nil (make-pathname :host nil))
doing the parse so that the resulting directory component is ("FOO"
"BAR"),
the resulting filename component is "BAZ", etc., illegal? If so, why?
I say that the above matches the last case of the definition of what
PARSE-NAMESTRING does when it is passed a string, and the result in
that case is implementation-dependent.
> | (3) In my understanding of logical pathnames at least, parsing a
logical
> | pathname namestring is a separate operation from translating a
> | logical pathname (although typically they are performed
immediately
> | one after the other).
>
> huh? they are _completely_ unrelated tasks. your "typically" does
not
> apply to any of the code I see that actually uses logical
pathnames.
> whence your observation?
Hence: passing a logical pathname namestring to OPEN is typical use of
logical pathname namestrings; when this happens, the namestring is parsed
then translated.
> | Further, my understanding is that a logical pathname namestring
can
> | be parsed even without a logical host at hand (on the other
hand,
> | translating one, of course, requires having a logical host).
>
> whence this understanding? (it's false.)
Hence: parsing is a syntactic operation, and the syntax of a logical
pathname namestring makes the host optional.
(...)
> | (PARSE-NAMESTRING does parsing only without translating, does
it not?)
>
> I fail to see what is unclear about what it does. whence the
uncertainty?
I just wanted to make sure that if I was missing something, it was not
with regards to what PARSE-NAMESTRING does.
(...)
> standards specify exhaustively what's valid and what all the valid
stuff
> means. everything else is forbidden. if you cannot find support
for
> your position in the standard, it is ipso facto not _standard_
behavior.
Fine, but how does `implementation-dependent' fit into this?
(...)
> standards provide the axiomatic framework for a deductive
> system of reasoning.
(...)
> true statements that cannot
> be proven are bugs. contradictions are bugs.
If I take this literally, then any standard has bugs by definition...
(...)
> the less willing you are to use the terminology of the standard,
the more
> I'm inclined to think that you're fighting the terminology (...)
Would you give me specific examples of me fighting the terminology?
(If it is not too much trouble, that is.)
(...)
> | ^2 unless, of course, it is guaranteed that PATHNAME always returns
a
> | physical pathname from a namestring, but I cannot find such a
guarantee
> | in the standard
>
> PATHNAME returns a `pathname' object [function pathname]. a
physical
> pathname is a `pathname' that is not a `logical-pathname'
[glossary].
> the class precedence list for `logical-pathname' is (logical-
pathname
> pathname t) [system-class logical-pathname].
Why did you post this? This is not a guarantee that PATHNAME always
returns
a physical pathname from a namestring.
(...)
> | (B) tests if there _may_exist_ a logical host with respect to which
> | a string is a logical pathname namestring.
> | I still say that (B) is not so trivial. (...)
>
> what the fuck? you call LOGICAL-PATHNAME-TRANSLATIONS to learn if
a
> string names a logical host or not! how hard can this be?
Do you mean that in order to do (B) one has to include a call to
LOGICAL-PATHNAME-TRANSLATIONS?
Anyway, does `not so trivial' mean `hard'?
Be well,
Kent M Pitman
Um, if I understand Erik's point correctly, then I agree with him.
Let me try to explain what I would be saying if I had answered this:
If the standard does not expressly say that something is ok, then an
implication of having failed to specify it is that it has failed to
specify a meaning. It has come up numerous times that people have
alleged that there are things which are "legal" but that have no
assigned "meaning". Forgetting CL for the moment, and speaking only
as a philosopher, I have to say that this concept is not something
that resonates with me. A language is for the purpose of expressing
something--if you do not know what you are expressing, then its
usefulness (at least in a program, though perhaps not in a museum of
modern art) is dubious.
Usually the issue being danced around is this:
Sometimes the standard doesn't preclude something.
That doesn't make use of that thing forbidden, but if no portable
program can be written to use it, then it's really not meaningfully
conforming of a program to use the feature. HOWEVER, an implication
is also that an implementation is not forbidden from assigning
meaning to the item and still claiming to be conforming. Implementations
are permitted to extend the language, but usees of those extensions
render a program non-conforming. Not non-useful. But to the degree
that it has any use, it's either because you don't care about the program
much and are willing to take any result that "appears to work" or else
it's because you have verified with the relevant implementations that
they will reliably provide the feature you want and that agreement is
good enough that it suffices in place of a guarantee by the language
that the feature will work.
In the case of NIL as a logical host, I think the problem is that NIL has
an assigned meaning as a merging element, and I'm pretty sure there is
a specific paragraph somewhere that says, approximately, "NIL is permissible
as a host component only in implementations where there is only one possible
host and a filler of NIL for the host cannot possibly be confused with
the absence of a filler".
Then again, host component merging is hopelessly broken in CL...
but that's a gripe for another day.
Erik Naggum
| In article <31255299...@naggum.no>,
| Erik Naggum <er...@naggum.no> wrote:
|
| > * vnik...@poboxes.com
| > | (1) What in the standard _forbids_ NIL from being a logical host?
| >
| > invalid reasoning. you must show where and how the standard
| _supports_
| > your position. in brief: its absence from the exhaustively
| specified set
| > of allowable logical hosts.
please try not to do this. it's terribly hard to untangle this mess.
| From the Glossary:
| logical host n. an object of implementation-dependent nature...
|
| This does not look like an exhaustively specified set. Can you point me
| to this exhaustive specification?
it is becoming evident that this has changed from a desire to understand
the standard to silly bickering over irrelevant trivia. it also appears
that you focus on particular details of expression, not on the meaning
that is attempted expressed. interpreting standards is very much like
applying laws to a particular case at hand. instead of letting everbody
go through technicalities and insufficiencies, there's a concept called
"the spirit of the law". a truly phenomenal amount of effort goes into
extracting the spirit of the law from the body of laws and precedents,
and this process has a purpose and a reason: there's a mythical principle
that all of the miserably fallible human beings are trying to express.
it is nigh impossible to say anything so people elsewhere at other times
will know _exactly_ what you meant and why you said what you said. just
like you do here, people tend to have their own principles and want what
they see from others to fit them. it takes constant vigilance to fight
that probable inherent limitation of the human intellect -- we weren't
used to having to deal with so much information that turned invalid at
the blink of an eye until late in this century, and there is ample
evidence that humans, like other sentient beings, go crazy when all they
deal with is new information. our filters and the way we think and act
is defined in terms of what has _not_ changed since yesterday. knowing
this, it is even more important to see what kinds of things change and
what kinds of things don't change, and all the while remain open to an
error in those assessments of constancy.
in this case, you've made up your mind about something being allowed by
the standard, but because I can't _disprove_ it your satisfaction, you
think you are in the clear when it comes to saying that the standard
_allows_ it in the same sense that laws do it: they don't forbid it. but
that isn't how standards work. a standard is like a constitution: it
says what procedures must be followed to make a law be fully legal. a
standard binds the implementors the same way the U.S. Constitution binds
the states: it says what they must do under threat of non-conformance,
and constitutional law is about showing that something does _not_ follow
from the constitutionally specified procedures. if it does not follow,
it is no a valid law. just like the U.S. Constitution allows the states
to do a lot of stuff on their own, a standard leaves a lot of options
open to the implementors, but they are _not_ allowed to overturn or
contradict the Constitution or the standard, and will be struck down if
they try to, with exactly the same procedure: if you can't prove it's a
valid law, you can't use it against anybody.
now, this analogy will fail if you aren't interested in law and legal
philosophy, but I am and have been for all my life, so reading standards
really comes as a breeze to me compared to dealing with the much less
specifically targeted legal traditions that also have to deal with
changing desires of the public to which the laws are intended to be
applied. (for a great example on the intricacies of procedure, I
recommend that you read Robert's Rules of Order. I rushed to get the new
edition when it came out 1991. I don't know anybody else who did.)
| (For example, the definition of the logical host SYS is
| implementation-dependent. And isn't it legal for an implementation to
| use NIL to represent the logical host whose name us "SYS"?)
no. nowhere in the standard does it say that. therefore, it is not
legal.
| I say that the above matches the last case of the definition of what
| PARSE-NAMESTRING does when it is passed a string, and the result in
| that case is implementation-dependent.
an implementation is not allowed to add semantics to logical pathnames.
it is allowed to do anything it pleases with physical pathnames. so when
the result is implementation-dependent, it means it is a physical
pathname -- the whole purpose of the logical pathname facility is to be
implementation-independent. it would self-contradictory if parsing
something in an implementation-dependent way would be a means to obtain
implementation-independent behavior. self-contradictions are usually a
pretty good sign you got something very seriously wrong.
| Hence: passing a logical pathname namestring to OPEN is typical use of
| logical pathname namestrings; when this happens, the namestring is parsed
| then translated.
I see no evidence that this is typical. parsing is pretty expensive, to
is makes ample sense to do it early. Common Lisp lets you do that with a
simple #P in front of the namestring. why would anyone go out of their
way to fail to use that facility? I don't get it. if it's typical,
let's tell the kids scary stories so at least the next generation won't.
| Hence: parsing is a syntactic operation, and the syntax of a logical
| pathname namestring makes the host optional.
ok, so your argument rests on that optionality of the host component in
the syntax specification, not on a solid understanding of what the syntax
is supposed to mean? that's bickering over the letter of the law, and
it's usually enough to land you a "contempt of court" ruling if you try
it in any official capacity.
| Fine, but how does `implementation-dependent' fit into this?
I hope you understand this by now. if not, the standard actually has a
lot of good things to say about this issue itself.
| (...)
| > standards provide the axiomatic framework for a deductive
| > system of reasoning.
| (...)
| > true statements that cannot
| > be proven are bugs. contradictions are bugs.
|
| If I take this literally, then any standard has bugs by definition...
truly amazing. I did consider putting in a disclaimer about Gödel here,
but figured nobody would be so utterly incapable of understanding context
they would bring it up, but, what is the world if not full of surprises?
try to take things less literally, and please go read Gödel. you might
be surprised what he's _actually_ talking about. applying Gödel to this
case is like believing competition in the market place has anything to do
with Darwinian theory of evolution.
| Would you give me specific examples of me fighting the terminology?
| (If it is not too much trouble, that is.)
your reference to the incompleteness theorems above is sufficient proof.
| Why did you post this?
because it looked like you needed it. why else?
| Do you mean that in order to do (B) one has to include a call to
| LOGICAL-PATHNAME-TRANSLATIONS?
effectively, yes.
| Anyway, does `not so trivial' mean `hard'?
on a scale from N to M, "not so trivial" is j and "hard" is k. i.e.,
your question is completely devoid of meaning, and any answer is as good
as any other answer. "hard" could be simpler than "not so trivial" in
some contexts and the reverse in others.
tell me, why is this is stuff so hard for you to deal with?
CsO
>robert m miles wrote:
>| How do you portably list all files and directories recursively from a
>| given point?
> well, what have you tried? show us. why did it fail?
sorry to just join in but i have tried this:
(defun pathname-as-dir (pathname)
(setq pathname (pathname pathname))
(let ((filename (file-namestring pathname)))
(if #+lispworks (< 0 (length filename))
#-lispworks filename
(make-pathname :defaults pathname
:directory (append (pathname-directory pathname)
(list filename))
:name nil :type nil :version nil)
pathname)))
(defun dirt (startpath &optional (tab 0))
(dolist (path (directory startpath))
(format t "~V,0T~A~%" tab path)
(dolist (subpath (directory (pathname-as-dir path)))
(dirt subpath (1+ tab)))))
in Allegro CL Lite 5.0 where it worked as i expected
and in LispWorks Personal 4.1.0 where it didn't
ACL has pathname-as-directory already but i used Eriks version
LW seems to share the CMUCL file-namestring "" for nil behaviour
LW is nice in that (on win32) directory returns pathnames which
differentiate between directories and files (it also does :wild-inferiors)
i know the code is probably bad anyway but mad as it seems LW
appears to return (list (pathname-as-dir path)) instead of the
(directory (pathname-as-dir path)) in the 2nd dolist and this
causes an infinite loop
any ideas?
how should it really be done?
ps
tried Corman Lisp but it doesn't seem to have file-namestring
and CLISP behaves like LW...
David R Tribble
>...
> ok, so I'm _extra_ annoyed by illiterates lately, but can you guys
> for this line in the standard or ...
It appears that your spelling/grammar-checker is broken.
Nick Levine
(defun pathname-as-dir (pathname)
(setq pathname (pathname pathname))
(let* ((filename (file-namestring pathname))
(filep (plusp (length filename))))
(make-pathname :defaults pathname
:directory (let ((directory (pathname-directory pathname)))
(if filep
(append directory (list filename))
directory))
:name (if filep (pathname-name pathname))
:type nil :version nil)))
The trick is to watch out for where pathname fields come back as nil and where
they come back :unspecified (see section 19.2.2.2.3.1 of the Spec). In
truename, directory etc, LW fills fields which are not specified with
:unspecified; I would guess that some other implementations (eg ACL) fill such
fields with nil.
I stared at the spec for a while trying to figure out who was right. All I
found was
Whether a value of :unspecific is permitted for any
component on any given file system accessible to the
implementation is implementation-defined.
(in 19.2.2.2.3) which seems to imply that we all are.
One for the language lawyers?
Otoh, on LW the following is simpler and avoids canonicalizing innards of
pathnames
(defun other-dirt (startpath &optional (tab 0))
(dolist (path (directory startpath))
(format t "~V,0T~A~%" tab path)
(when (lw:file-directory-p path)
(dolist (subpath (directory (lw:pathname-location path)))
(other-dirt subpath (1+ tab))))))
- nick
Nick Levine
Re:
> ....
> (make-pathname :defaults pathname
> :directory (let ((directory (pathname-directory pathname)))
>
> (if filep
> (append directory (list filename))
> directory))
> :name (if filep (pathname-name pathname))
> :type nil :version nil)))
Typo in the :type, it should have been
:type (if filep (pathname type pathname))
- nick
Nick Levine
> Typo in the :type, it should have been
>
> :type (if filep (pathname type pathname))
Or even, (pathname-type pathname)
- nick (who should proof-read them _before_ hitting the send button)