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.

(directory "/**/*.lisp")

should generate a list of every lisp file on your hard drive.

  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?

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...).

(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?

DIRECTORYP pathname
[Function]
returns true if pathname represents a directory. An error is signalled if
pathname is not a pathname.

CL-HTTP defines www-utils:pathname-directory-p .

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.

Jon
PS Any chance of a glibc (libc6) port of Talk for linux?

    #+lispworks system::logical-pathname-p ; tested in 4.1 releases
    #+liquid liquid::logical-pathname-p    ; from next release

Hope this helps.

  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.

(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.

;;; 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

CL-HTTP has a way that works really well though.

  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"

--

  why do you expect a string to be a pathname?

  do you expect (null "()") to return true, too?

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).

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 <vniko...@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.)

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.

Vassil Nikolov <vniko...@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.)

  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.

  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.

  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)))

I like it so much when the language provides the appropriate
primitives (like FILE-NAMESTRING in this example).

Vassil Nikolov <vniko...@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.)