Can anybody help me to determin what names received by "directory" function
are the names of "subdirectories", and what ones are names of "files"?

Thank you.

MCL adds some functionality:

DIRECTORY pathname &key :directories :files
:directory-pathnames :test :resolve-aliases
[Function]
returns a list of the truenames of all files or folders that match
pathname, using * as a wildcard character. directory must accept
logical pathnames but does not return them.

Example:

(directory "ccl:examples;*"
           :directories t
           :files nil)

-->

(#P"Macintosh HD:Lisp:MCL 4.2:Examples:BinHex:"
 #P"Macintosh HD:Lisp:MCL 4.2:Examples:FF Examples:"
 #P"Macintosh HD:Lisp:MCL 4.2:Examples:NotInROM:"
 #P"Macintosh HD:Lisp:MCL 4.2:Examples:series:")

MCL also has a function DIRECTORYP.

It depends on which lisp implementation you're using. For acl and
lispworks you can use `file-directory-p'. You may get lucky with
(apropos 'directory).

The faq mentions something like the following as a last resort.

I expect that in most implementations, (directory "/users/*") will return
entries like the second case.

--
Stas Selitskiy

--
Stas Selitskiy

--
Stas Selitskiy

  the function EXCL:ARGLIST reports the argument list of a function, as
  does the Emacs/Lisp Interface function FI:LISP-ARGLIST, ordinarily bound
  to C-c a and M-A in Lisp mode or in a Listener.

(directory <wildpathname> :directories-are-files t)

  will return the subdirectories are ordinary files, and is the default.

(directory <wildpathname> :directories-are-files nil)

  will return the subdirectories as directories.

  note that Allegro CL distinguishes a file from a directory by the
  trailing slash in the pathname print syntax.

  all of this is well documented in the accompanying manuals or on-line
  documentation.  please take the time to read them.

------
As defined by ANSI, a truename is a canonicalized pathname in which
wildcards and
mnemonic version numbers have been resolved, logical host translations
have been
resolved, and, in general, multiple ways of referring to the same file
in the file system have
been resolved to the most canonical form.

There are two Eclipse-specific aspects of this last issue that are of
note:

    1.In some situations, some file systems, such as Unix, allow
namestrings that refer to
       directories to be specified with or without the trailing
directory separator (eg.
       "/dir/subdir" or "/dir/subdir/"). In other words, something that
looks like a filename
       might refer to a file or to a directory.

       In Eclipse, the truename of a directory is always canonicalized
such that the
       namestring prints as a directory (eg. "/dir/subdir/"), and the
PATHNAME-NAME,
       PATHNAME-TYPE and PATHNAME-VERSION are all :UNSPECIFIC.

    2.Some file systems allow files to be symbolically linked to other
files or directories. In
       general, Eclipse truenames resolve such links to their ultimate
file or directory
       destination. However, DIRECTORY allows the programmer to specify
whether such
       symbolic links are followed once, completely, or not at all.

-----
A problem with using nil instead of :unspecific is that it isn't really
cannonicalized.  If both are acceptable, then you don't really know what
to expect.  Besides, if you want to, for example, use PROBE-FILE to see
if a directory exists, you don't want it merging in the defaults from
*defualt-pathname-defaults*.  Thus, if the system went around returning
truenames with null-components, you might find that some later action
with those TRUENAMES merged in different values and returned results for
a DIFFERENT file.

(defun dir-p (path)
  (probe-file (concatenate 'string path
    ;; will work on some filesystems, on those which
    ;; use "." as file-alias for the actual dir ("self")
    ;; and accept "/" as path delimiter (unix, winnt)
    "/.")))

or even
(defun dir-p (path)
  (probe-file (concatenate 'string path
    ;; will work on less filesystems,
    ;; on these which support the NUL device as file
    "/NUL")))

but none of those are portable at all.
they will only work on winnt and on various unix variants,
but not on DOS+Win3.x (needs "\\"), mac (needs ":"), vms "[]",
or any other non-unix os as stated in the FAQ.
i cannot really remember now what win95 and win98 do with the "/".
nt at least accepts it as valid path-delim.

most OS also support a file-attribute which tells you if this file is a
directory. i would use this. something like a posix stat.
this would fit better to OS which treat files as objects and dirs as
collection of objects and should therefore be more portable.
  file-attribute <==> slot

I was thinking that a namestring or path with a trailing slash would
be used, such as "/usr/local/", and since I'm used to having the slash
be used to distinguish a file from a directory I included it - I
probably should have written "/./", but I hate pathnames that have two
trailing slashes (I get this in my C and shell programs all too often
- drives me nuts because it seems so kludgy). A better way would be to
have an optional argument but the optimal solution would be a built in
method I suppose.

(defun dir-p (path &optional (seperator "/."))
  (probe-file (concatenate 'string path seperator)))

This works much better, but there is always something like:

(defun dir-p (path)
 #+(excl (excl::probe-directory path))
 #+(  ...)).

I guess it depends on the tools and problem you have to deal with.
Maybe there should be some constant which serves as the path
seperator? What if there are no pathnames? Maybe :unspecified? I
dunno, it's a tough issue.

< this is really a mess. make-pathname seems to accept only files but no
< directories, though CLHS would imply it.
< so (probe-file (make-pathname :directory path :name ".")) or similar
< attempts will fail

I'll agree with you to some degree, but I'm glad that there is a
method for dealing with something as common as pathnames. It's better
to have a starting point than to ignore the issue altogether, IMHO.
There's always logical pathnames (which can work to some degree).

The real difficulty I think is the lack of a common distinction amoung
_every_ operating system for a directory, file, and most importantly
it's type (I ignore versions because their lack of on my machine gets
me so angry). In unix with `~/emacs/.saves', would we call `.saves' a
nameless file with no type? Or is it actually a directory with no
name, hence `~/emacs/.saves/'? There is no concept of `type' to be
found within the unix universe. Should filenames be limited to eight
characters long to accommodate windows95 (which altogether ignores the
issue of filenames, IMHO) and DOS?

To me the biggest problems I have when writing programs is interfacing
with the unix `knowledge stores'. No matter what language, storing
things in a file/program-dependant manner is just not a good idea.
Ideas like using an invisible marker (such as a tab versus a space)
for a `seperator of information' makes me think of unix as a database
of bad ideas.

a simple example such as below would be fine:
;;unix
(pathname-name ".foo") =>  ".foo"
(pathname-name ".foo.l") =>  ".foo"

cmucl defines these rules:
(defun parse (x)
  (values (pathname-name x) (pathname-type x) (pathname-version x)))

(parse ''foo'') ) ''foo'', NIL, :NEWEST
(parse ''foo.bar'') ) ''foo'', ''bar'', :NEWEST
(parse ''.foo'') ) ''.foo'', NIL, :NEWEST
(parse ''.foo.bar'') ) ''.foo'', ''bar'', :NEWEST
(parse ''..'') ) ''.'', '''', :NEWEST
(parse ''foo.'') ) ''foo'', '''', :NEWEST
(parse ''foo.bar.1'') ) ''foo'', ''bar'', 1
(parse ''foo.bar.baz'') ) ''foo.bar'', ''baz'', :NEWEST