From: ·············@ispi.net
Subject: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <6uodup$kaq$1@nnrp1.dejanews.com>
Hi, everyone!
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.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
From: Barry Margolin
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <CwRP1.15$94.258509@burlma1-snr1.gtei.net>
In article <············@nnrp1.dejanews.com>, <·············@ispi.net> wrote:
>Can anybody help me to determin what names received by "directory" function
>are the names of "subdirectories", and what ones are names of "files"?
There's no portable way to do this directly. An indirect way is to
construct a new pathname by appending the name to the original path, and
then try to list that subdirectory. If this succeeds then the name
referred to a subdirectory or a symbolic link pointing to a directory; if
it fails then either it doesn't refer to a subdirectory or you don't have
access to list it.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Rainer Joswig
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <joswig-2809982341580001@194.163.195.67>
In article <··················@burlma1-snr1.gtei.net>, Barry Margolin
<······@bbnplanet.com> wrote:
> In article <············@nnrp1.dejanews.com>, <·············@ispi.net> wrote:
> >Can anybody help me to determin what names received by "directory" function
> >are the names of "subdirectories", and what ones are names of "files"?
>
> There's no portable way to do this directly.
Wouldn't it be nice to have something like that?
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.
--
http://www.lavielle.com/~joswig
From: ·············@ispi.net
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <6us3e6$rr8$1@nnrp1.dejanews.com>
In article <·······················@194.163.195.67>,
······@lavielle.com (Rainer Joswig) wrote:
> In article <··················@burlma1-snr1.gtei.net>, Barry Margolin
> <······@bbnplanet.com> wrote:
>
> > In article <············@nnrp1.dejanews.com>, <·············@ispi.net>
wrote:
> > >Can anybody help me to determin what names received by "directory" function
> > >are the names of "subdirectories", and what ones are names of "files"?
> >
> > There's no portable way to do this directly.
>
> Wouldn't it be nice to have something like that?
>
> 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.
>
> --
> http://www.lavielle.com/~joswig
>
Unfortunately, acl I use does not maintain :directory and :file key
parameters.
--
Stas Selitskiy
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
From: Erik Naggum
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <3116143740108747@naggum.no>
* ·············@ispi.net
| Unfortunately, acl I use does not maintain :directory and :file key
| parameters.
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.
#:Erik
From: Sunil Mishra
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <efylnn3wwtt.fsf@xenia.cc.gatech.edu>
Barry Margolin <······@bbnplanet.com> writes:
> There's no portable way to do this directly. An indirect way is to
> construct a new pathname by appending the name to the original path, and
> then try to list that subdirectory. If this succeeds then the name
> referred to a subdirectory or a symbolic link pointing to a directory; if
> it fails then either it doesn't refer to a subdirectory or you don't have
> access to list it.
I was always under the impression that a null value for pathname-name would
indicate a directory. How is that unreliable?
Sunil
From: Barry Margolin
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <xd6Q1.4$WG.127219@burlma1-snr1.gtei.net>
In article <···············@xenia.cc.gatech.edu>,
Sunil Mishra <·······@xenia.cc.gatech.edu> wrote:
>Barry Margolin <······@bbnplanet.com> writes:
>
>> There's no portable way to do this directly. An indirect way is to
>> construct a new pathname by appending the name to the original path, and
>> then try to list that subdirectory. If this succeeds then the name
>> referred to a subdirectory or a symbolic link pointing to a directory; if
>> it fails then either it doesn't refer to a subdirectory or you don't have
>> access to list it.
>
>I was always under the impression that a null value for pathname-name would
>indicate a directory. How is that unreliable?
PATHNAME-NAME is essentially just a slot accessor, it returns whatever was
specified in the call to MAKE-PATHNAME. Consider my home directory
/users/barmar. I can do (make-pathname :directory '("users" "barmar")) or
(make-pathname :directory '("users") :name "barmar"). In the first case,
PATHNAME-NAME will return return NIL, in the second it will return
"barmar".
I expect that in most implementations, (directory "/users/*") will return
entries like the second case.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Howard R. Stearns
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <3612495D.53B85189@elwood.com>
Sunil Mishra wrote:
>
> Barry Margolin <······@bbnplanet.com> writes:
>
> > There's no portable way to do this directly. An indirect way is to
> > construct a new pathname by appending the name to the original path, and
> > then try to list that subdirectory. If this succeeds then the name
> > referred to a subdirectory or a symbolic link pointing to a directory; if
> > it fails then either it doesn't refer to a subdirectory or you don't have
> > access to list it.
>
> I was always under the impression that a null value for pathname-name would
> indicate a directory. How is that unreliable?
>
> Sunil
Eclipse takes the following approach, from
http://www.elwood.com/eclipse/path.htm#truenames
I think it's "the right thing", but then, I'm pretty biased! (If people
agree that this is the right thing, they might consider talking to their
vendor.) Note that ANSI requires DIRECTORY to return truenames.
------
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.
Note that the "append / hack" isn't really portable. It assumes #\/ as
the directory separator, and it assumes that neither the Lisp
implementation nor the file system support DWIMing of pathnames. (For
example, in Emacs, you can specify a filename as /foo/bar//tmp, and get
back just /tmp.)
From: ·············@ispi.net
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <6us3a9$ri6$1@nnrp1.dejanews.com>
In article <··················@burlma1-snr1.gtei.net>,
Barry Margolin <······@bbnplanet.com> wrote:
> In article <············@nnrp1.dejanews.com>, <·············@ispi.net> wrote:
> >Can anybody help me to determin what names received by "directory" function
> >are the names of "subdirectories", and what ones are names of "files"?
>
> There's no portable way to do this directly. An indirect way is to
> construct a new pathname by appending the name to the original path, and
> then try to list that subdirectory. If this succeeds then the name
> referred to a subdirectory or a symbolic link pointing to a directory; if
> it fails then either it doesn't refer to a subdirectory or you don't have
> access to list it.
Yes, but "directory" function will return "nil" if folder is empty. As a file.
--
Stas Selitskiy
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
From: Steve Gonedes
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <m2pvcfwii5.fsf@KludgeUnix.com>
·············@ispi.net writes:
<
< Hi, everyone!
<
< 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.
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.
(defun dir-p (path)
(probe-file (concatenate 'string path "./")))
From: ·············@ispi.net
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <6us35f$rgi$1@nnrp1.dejanews.com>
In article <··············@KludgeUnix.com>,
Steve Gonedes <········@worldnet.att.net> wrote:
> The faq mentions something like the following as a last resort.
>
> (defun dir-p (path)
> (probe-file (concatenate 'string path "/")))
It works!
It's the only real portable way.
Thank you!
--
Stas Selitskiy
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
From: Reini Urban
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <361247d2.18331248@judy>
·············@ispi.net wrote:
>In article <··············@KludgeUnix.com>,
> Steve Gonedes <········@worldnet.att.net> wrote:
>
>> The faq mentions something like the following as a last resort.
>>
>> (defun dir-p (path)
>> (probe-file (concatenate 'string path "./")))
^^ -- should say "/."
>It works!
>It's the only real portable way.
>Thank you!
portable? hmm...
you could try to use
(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
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
---
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
From: Steve Gonedes
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <m2soh9l98i.fsf@KludgeUnix.com>
Reini Urban <······@sbox.tu-graz.ac.at> writes:
<
< ·············@ispi.net wrote:
< >In article <··············@KludgeUnix.com>,
< > Steve Gonedes <········@worldnet.att.net> wrote:
< >
< >> The faq mentions something like the following as a last resort.
< >>
< >> (defun dir-p (path)
< >> (probe-file (concatenate 'string path "./")))
^^ -- should say "/."
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.
In spite of all this, cl has given me the ability to describe a file
by it's type. It's not perfect, just very convenient.
From: Reini Urban
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <361b2dc1.2478674@judy>
Steve Gonedes <········@worldnet.att.net> wrote:
>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.
.saves has the filename ".saves" and an empty type. (cmucl docs)
but this implementation defined as i understand it.
translation rules for dumber filesystems are not in CLHS. having had
specified some of these rules (e.g. for unix, win32 and dos) would have
made life easier.
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
--
Reini Urban
From: Christopher Stacy
Subject: Re: Help: Result of "directory" function. Wich of names received are "directory" names?
Date:
Message-ID: <uww6gu7w2.fsf@pilgrim.com>
Maybe I missed something about the intentions being discussed,
but "/" is not portable -- that only works on UNIX.
Symbolics Genera supported an extensible portable pathname system,
but it was deemed to cmplicated for inclusion in Common Lisp.