From: Sam Steingold
Subject: delete-file & probe-file on directories
Date:
Message-ID: <ud5pcaqxn.fsf@gnu.org>
should delete-file and probe-file work on directories?
e.g. suppose we have a file "foo" and a subdirectory "bar/".
what should
(probe-file "foo")
(probe-file "foo/")
(probe-file "bar")
(probe-file "bar/")
return?
one could argue that the first two invocations should return the same as
(truename "foo") and the last two the same as (truename "bar/").
one can also argue that the 2nd and 3rd should return nil - especially
if it is possible to have same named files and subdirectories (are there
filesystems where files and subdirectories are in different namespaces?)
the issue is complicated by symbolic links - what if a file is a symlink
to a directory...
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.openvotingconsortium.org/> <http://ffii.org/>
<http://www.mideasttruth.com/> <http://pmw.org.il/>
Good judgment comes from experience and experience comes from bad judgment.
From: Sam Steingold
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <u3bq7c3nd.fsf@gnu.org>
> * Sam Steingold <···@tah.bet> [2005-07-21 15:40:20 -0400]:
>
> should delete-file and probe-file work on directories?
>
> e.g. suppose we have a file "foo" and a subdirectory "bar/".
> what should
>
> (probe-file "foo")
> (probe-file "foo/")
> (probe-file "bar")
> (probe-file "bar/")
>
> return?
>
> one could argue that the first two invocations should return the same as
> (truename "foo") and the last two the same as (truename "bar/").
> one can also argue that the 2nd and 3rd should return nil - especially
> if it is possible to have same named files and subdirectories (are there
> filesystems where files and subdirectories are in different namespaces?)
since some IMAP servers support folders that contain _both_ messages and
subfolders, we cannot blindly assume that "foo" and "foo/" cannot
coexist.
therefore it appears that the second option is better:
(probe-file "foo") == (truename "foo")
(probe-file "foo/") == NIL
(probe-file "bar") == NIL
(probe-file "bar/") == (truename "bar/")
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.palestinefacts.org/> <http://www.memri.org/>
<http://www.iris.org.il> <http://www.jihadwatch.org/>
Bus error -- driver executed.
Sam Steingold <···@gnu.org> writes:
>> * Sam Steingold <···@tah.bet> [2005-07-21 15:40:20 -0400]:
>>
>> should delete-file and probe-file work on directories?
>>
>> e.g. suppose we have a file "foo" and a subdirectory "bar/".
>> what should
>>
>> (probe-file "foo")
>> (probe-file "foo/")
>> (probe-file "bar")
>> (probe-file "bar/")
>>
>> return?
>>
>> one could argue that the first two invocations should return the same as
>> (truename "foo") and the last two the same as (truename "bar/").
>> one can also argue that the 2nd and 3rd should return nil - especially
>> if it is possible to have same named files and subdirectories (are there
>> filesystems where files and subdirectories are in different namespaces?)
>
> since some IMAP servers support folders that contain _both_ messages
> and subfolders, we cannot blindly assume that "foo" and "foo/"
> cannot coexist.
>
> therefore it appears that the second option is better:
>
> (probe-file "foo") == (truename "foo")
> (probe-file "foo/") == NIL
> (probe-file "bar") == NIL
> (probe-file "bar/") == (truename "bar/")
Hmmm. Maybe it's just me but I'd say Common Lisp users would benefit
more from various implementations converging on how standard functions
such as PROBE-FILE work on Unix and Windows-style filesystems before
we start trying to apply them to "filesystems" such as IMAP servers.
Then if CLISP, or any other implementation, really wants to provide a
way to define an IMAP filesystem that can be operated on with the
standard CL file and pathname functions, there's no requirement that
all the functions behave exactly the same for all kinds of file
systems.
Another way of stating the same argument: I accept that Common Lisp's
file handling functions were designed to accomodate a broad variation
in possible file systems, broad enough perhaps to include even such
things as IMAP servers. That's fine. And one consequence of that
choice is that there's probably no single semantics for functions such
as PROBE-FILE that will apply with equal naturalness to all
filesystems. But that doesn't mean that it wouldn't be useful for
implementors to agree on the semantics for *particular*
filesystems. Thus the fact that IMAP or TOPS-20 does something
different than Unix filesystems shouldn't preclude implementations
that actually run on Unix deciding to do things the same way when
dealing with a Unix filesystem. (And no doubt someone will point out
that there are filesystems that run on Unix that aren't like what I'm
imprecisely refering to as "Unix filesystems". Which doesn't change my
argument.)
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
On Thu, 21 Jul 2005 20:42:41 +0000, Peter Seibel wrote:
> Sam Steingold <···@gnu.org> writes:
>
>>> * Sam Steingold <···@tah.bet> [2005-07-21 15:40:20 -0400]:
>>>
>>> should delete-file and probe-file work on directories?
[snip]
> -Peter
If I may take this slightly off topic...
Sam mentioned in a separate post that he had submitted a CLRFI 6 months
ago, and it hadn't even been published.
Peter, pushing the CLRFI process forward is something real and tangible,
that perhaps the ALU could do, and for which I would certainly pay
membership dues. Do you think there's any chance of something like that
happening?
Best wishes,
Bill.
From: Peter Seibel
Subject: CLRFI and the ALU [was: delete-file & probe-file on directories]
Date:
Message-ID: <m24qanzw9x.fsf_-_@gigamonkeys.com>
William Bland <·······@abstractnonsense.com> writes:
> If I may take this slightly off topic...
>
> Sam mentioned in a separate post that he had submitted a CLRFI 6
> months ago, and it hadn't even been published.
>
> Peter, pushing the CLRFI process forward is something real and
> tangible, that perhaps the ALU could do, and for which I would
> certainly pay membership dues. Do you think there's any chance of
> something like that happening?
I'd like to think so. I'm not yet sure exactly what the connection
between the CLRFI folks and the ALU is though if you compare the list
of CLRFI editors at:
<http://clrfi.alu.org/process/editors/>
and the ALU board members at
<http://lisp.org/alu/alu-board>
you'll see that four of the six CLRFI editors are also board members
or officers of the ALU. And the CLRFI site is hosted at the alu.org
domain.
But even if they are technically separate projects, speaking for
myself, I think a vibrant CLRFI process seems like the kind of thing
the ALU out to be trying to help along however we can. I'll try to
post more once I know more. (This has been on my list of things to
find out about--thanks for prodding me into action.)
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> William Bland <·······@abstractnonsense.com> writes:
> > Sam mentioned in a separate post that he had submitted a CLRFI 6
> > months ago, and it hadn't even been published.
> >
> > Peter, pushing the CLRFI process forward is something real and
> > tangible, that perhaps the ALU could do, and for which I would
> > certainly pay membership dues. Do you think there's any chance of
> > something like that happening?
>
> I'd like to think so. I'm not yet sure exactly what the connection
> between the CLRFI folks and the ALU is though if you compare the list
> of CLRFI editors at:
> [..]
> and the ALU board members at
> [..]
> you'll see that four of the six CLRFI editors are also board members
> or officers of the ALU. And the CLRFI site is hosted at the alu.org
> domain.
I get the impression some CLRFI editors have a "wish" to keep the two
organizations fairly separate. An ambivalent feeling. Likely not an
immediate priority though.
I'll find out what the results are of the ILC meeting:
http://clrfi.alu.org/process/minutes/2005-06-21/
Fortunately, it appears at first glance that Nick graciously brought up
the only extant criticism of CLRFI (that I know of): their de facto
openness to all Common Lisp users. Who of course will be directly
affected by CLRFI.
Tayssir
Peter Seibel <·····@gigamonkeys.com> writes:
> But even if they are technically separate projects, speaking for
> myself, I think a vibrant CLRFI process seems like the kind of thing
> the ALU out to be trying to help along however we can. I'll try to
> post more once I know more. (This has been on my list of things to
> find out about--thanks for prodding me into action.)
Okay, from the CLRFI FAQ at:
<http://clrfi.alu.org/faq#question-2>
2. What's your relationship with the ALU?
No precise relationship with the Association of Lisp Users (ALU) has
been established; we are not an ALU subcommittee or anything like
that; but the ALU board does know that we exist, and roughly what
we're attempting to do, and that we're using the ALU machine.
I guess it's good to know that the CLRFI guys didn't just crack into
the ALU machine to get free hosting. ;-)
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> writes:
> myself, I think a vibrant CLRFI process seems like the kind of thing
> the ALU out to be trying to help along however we can. I'll try to
I have the deepest respect for the ALU board and members. But, as an
organization, ALU is apparently paralyzed. It is no longer able to do
anything except organizing Lisp conferences--which is important and
useful, mind you.
After over a year from my first inquiry, I still don't know whether I
will be able to purchase a copy of the ILC 2003 proceedings. Several
weeks ago ALU contacted me and asked my postal address for shipping a
CD with the proceedings.
But things halted when I discovered that someone else from ALU,
apparently unaware of the other effort, independently contacted me and
asked again for the shipping address, which I didn't provide this time
to avoid duplicate work. I still don't know who to send my payment to
and how (suggestion for future Lisp conferences and events: let
BOOKFIX.COM take care of publishing the proceedings).
My trust in ALU's ability to do anything at all is limited right now.
Again, this is not meant in disrespect--from someone who probably
shares some responsibility for this.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: Duane Rettig
Subject: Re: CLRFI and the ALU [was: delete-file & probe-file on directories]
Date:
Message-ID: <464v2kh3x.fsf@franz.com>
[Disclaimer: I am replying as a member of the ALU board, but not
necessarily representing the opinions of the board. I am also not
representing Franz Inc - my opinions are purely my own in this post
and in any subsequent replies.]
Paolo Amoroso <·······@mclink.it> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
> > myself, I think a vibrant CLRFI process seems like the kind of thing
> > the ALU out to be trying to help along however we can. I'll try to
>
> I have the deepest respect for the ALU board and members. But, as an
> organization, ALU is apparently paralyzed.
Until this year, this was absolutely true. One of the things we
couldn't even do was to get minutes together from the board meetings,
but at least from my memory even as far back as 2000, where we were
deciding whether to disband the ALU or not, we were aware of the
problem, which seemed to be that the ALU had lost its teeth. We
finally made the decision to scale back our goals, since we had no
money, and to concentrate on the one thing that we absolutely must
do, which was to organize conferences.
> It is no longer able to do
> anything except organizing Lisp conferences--which is important and
> useful, mind you.
For reasons which I won't go into, including preserving one or more
reputations, I'd prefer not to elaborate much, but you actually have
this backward. We (the ALU) are now, as of this year, finally able
to put on a conference by ourselves. Until this year, we were not able
to do so. Putting on yearly conferences is still our only stated
goal (though I do see some fluff on the website about other goals,
which are either misguided or out of date). Now that we've finally
had our own successful conference, we are now working on stating more
clearly our mission statement and adding goals, including things that
perhaps obviously should have been goals based on our name and the
mission it implies. But none of this was explicit, and I fear that
this is the reason why I've heard from so many of you as to the ALU
board's ineffectiveness to perform according to your expectations.
The long and short of it was that we were constantly on the verge of
not existing at all. We are out of those woods now, and can now
concentrate on what we will be able to tell you we will do for you.
Rest assured that we will make the goals we decide upon explicit, and
it will be placed on the website as soon as we decide.
> After over a year from my first inquiry, I still don't know whether I
> will be able to purchase a copy of the ILC 2003 proceedings. Several
> weeks ago ALU contacted me and asked my postal address for shipping a
> CD with the proceedings.
>
> But things halted when I discovered that someone else from ALU,
> apparently unaware of the other effort, independently contacted me and
> asked again for the shipping address, which I didn't provide this time
> to avoid duplicate work. I still don't know who to send my payment to
> and how (suggestion for future Lisp conferences and events: let
> BOOKFIX.COM take care of publishing the proceedings).
>
> My trust in ALU's ability to do anything at all is limited right now.
> Again, this is not meant in disrespect--from someone who probably
> shares some responsibility for this.
The ILC2003 conference was our first attempt to run a conference
ourselves. In many respects, it appeared to be a success. In other
ways, it was a failure that almost turned to disaster, as those of
you who tried to register at the hotel that Saturday may have
discovered. Some fast thinking people, including Heow Eide-Goodman
(now a board member, and I believe principal organizer of the Lispnyk
group) and Lilliana Avila from Franz, as well as some of the board
members, pulled the conference out of the flames. We lost money, we
lost records, and only last month finally pulled enough of the
proceedings together to be able to make a cd out of it. We're still
discussing what to do with any extra copies of the cds, after every
conference attendee is sure to have received one (another problem,
since our record of attendance conflicts). Paolo, I don't remember,
but if you were an ILC2003 attendee, you are due a free copy of the cd,
otherwise you'll probably have to wait a bit longer. And yes, I
understand that it is a travesty to have had to wait this long for
proceedings, but that is part of the nature of this failure.
The ILC2005 conference went much, much smoother, and we even had
proceedings in dead-tree form available _at_ the conference. This
represents us having learned our lesson, and having learned how to
put on a conference. [This is not an official acknowledgement, since
I'm not speaking for the board, but I'd like to thank Carl Shapiro
and Jon L White for their extreme effort in making this year's
conference a success. Other's helped, but not to the extent that
these two did, especially Carl.]
I've never said anything about the ALU to date, because frankly I
was always worried for its existence. Most people don't know how
all-volunteer organizations work (or don't work) and so there tends
to be a higher expectation placed on these organizations. And when
a volunteer does offer to help, sometimes the help offered doesn't
fit the goals of the organization, and that leads to negative feelings
toward the organization. Now that our survival is much more likely,
we are now working on setting new goals (even if they appear old, as
they might have been expected by others), and when these goals are
set, and board members assigned to oversee the projects, you can be
sure that we will be asking for each of your help in meeting those
goals.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> proceedings together to be able to make a cd out of it. We're still
> discussing what to do with any extra copies of the cds, after every
> conference attendee is sure to have received one (another problem,
> since our record of attendance conflicts). Paolo, I don't remember,
> but if you were an ILC2003 attendee, you are due a free copy of the cd,
No, I didn't attend ILC 2003.
> otherwise you'll probably have to wait a bit longer. And yes, I
> understand that it is a travesty to have had to wait this long for
> proceedings, but that is part of the nature of this failure.
Isn't patience a virtue of Lispers? :)
> The ILC2005 conference went much, much smoother, and we even had
This was probably perceived even by those who didn't attend it.
Thanks for the clarifications,
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: Peter Seibel
Subject: Re: CLRFI and the ALU [was: delete-file & probe-file on directories]
Date:
Message-ID: <m2mzoedenq.fsf@gigamonkeys.com>
Paolo Amoroso <·······@mclink.it> writes:
> My trust in ALU's ability to do anything at all is limited right now.
> Again, this is not meant in disrespect--from someone who probably
> shares some responsibility for this.
That's fair enough. Though I'd like to echo Duane's comments, that
there are some signs that the ALU is at the moment heading more in the
right direction than the wrong direction. Whether we'll keep going in
the right direction and avoid stalling out is, of course, always an
open question.
In the meantime, I'm always interested in hearing from ALU members
about what they think the organization should be expending its
resources on and from non members about what kinds of things the ALU
could do that would make it worth joining.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> writes:
> That's fair enough. Though I'd like to echo Duane's comments, that
> there are some signs that the ALU is at the moment heading more in the
> right direction than the wrong direction. Whether we'll keep going in
ALU definitely deserves a second chance.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Peter Seibel wrote:
> Another way of stating the same argument: I accept that Common Lisp's
> file handling functions were designed to accomodate a broad variation
> in possible file systems, broad enough perhaps to include even such
> things as IMAP servers. That's fine. And one consequence of that
> choice is that there's probably no single semantics for functions such
> as PROBE-FILE that will apply with equal naturalness to all
> filesystems.
Then what's the point in having them at all? If a given API works
totally different across implementations and operating systems,
that's WORSE than having vendor-specific APIs that I can access.
If something seems to work, but later fails in some spurious
(implementation-dependent) way, you're simply screwed.
Your pathname compatibility layer provides some basic operations
that work across different implementations, and on different
Unices and probably Windows as well. Exactly this kind of stuff
belongs into a standard, not the wishy-washy Standard CL
operations it's based on.
> But that doesn't mean that it wouldn't be useful for
> implementors to agree on the semantics for *particular*
> filesystems. Thus the fact that IMAP or TOPS-20 does something
> different than Unix filesystems shouldn't preclude implementations
> that actually run on Unix deciding to do things the same way when
> dealing with a Unix filesystem.
If IMAP namespaces don't happen to map onto "normal"
directory/file structures then you need a different interface. I
don't know IMAP too well, but if it maps well onto a standard file
system tree, then it should work out of the box with a file system
API.
(And no doubt someone will point out
> that there are filesystems that run on Unix that aren't like what I'm
> imprecisely refering to as "Unix filesystems". Which doesn't change my
> argument.)
Such as? When something runs on Unix, I assume that you mean that
it's mounted into the VFS namespace, so it behaves like any other
Unix filesystem, and every C program on earth that uses the Unix
system calls will work out of the box.
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
Ulrich Hobelmann <···········@web.de> writes:
> Peter Seibel wrote:
>> Another way of stating the same argument: I accept that Common Lisp's
>> file handling functions were designed to accomodate a broad variation
>> in possible file systems, broad enough perhaps to include even such
>> things as IMAP servers. That's fine. And one consequence of that
>> choice is that there's probably no single semantics for functions such
>> as PROBE-FILE that will apply with equal naturalness to all
>> filesystems.
>
> Then what's the point in having them at all? If a given API works
> totally different across implementations and operating systems,
> that's WORSE than having vendor-specific APIs that I can access. If
> something seems to work, but later fails in some spurious
> (implementation-dependent) way, you're simply screwed.
Yes. But there's a difference between implementations deciding to map
the *same* underlying operations to CL functions in different ways and
implementations that run on different OS's mapping the same CL
functions to slightly different semantics. I think we have a (slight)
chance of sorting out the former but the later can't be ironed out
without mushing everything down to a lowest common denominator of all
past, present, and future filesystems.
> Your pathname compatibility layer provides some basic operations that
> work across different implementations, and on different Unices and
> probably Windows as well. Exactly this kind of stuff belongs into a
> standard, not the wishy-washy Standard CL operations it's based on.
So what I'm saying is, if all the implementors got together and said,
"on Windows and Unix" we'll make the standard Common Lisp file and
pathname functions work the same across implementations that'd be
valuable. Ideally they'd even agree on a symbol to push on *features*
so you could find out whether a particular implementation is part of
this agreement.
In such a world, if I'm writing software that I know is only going to
be deployed on Windows and Unix I know I can run my code in any Common
Lisp implementation. My porting problems aren't completely solved
because I can't count on my code running the same way on TOPS-20 but I
can live with that.
But at the moment I can't even count on my code running the same
between Common Lisp implementations on exacly the same OS and
filesystem without writing something like my portability layer.
>> But that doesn't mean that it wouldn't be useful for
>> implementors to agree on the semantics for *particular*
>> filesystems. Thus the fact that IMAP or TOPS-20 does something
>> different than Unix filesystems shouldn't preclude implementations
>> that actually run on Unix deciding to do things the same way when
>> dealing with a Unix filesystem.
>
> If IMAP namespaces don't happen to map onto "normal" directory/file
> structures then you need a different interface. I don't know IMAP too
> well, but if it maps well onto a standard file system tree, then it
> should work out of the box with a file system API.
I'm inclined to agree with you--that's why I said it'd be more
valuable for implementors to agree on how things like PROBE-FILE work
on the actual filesystems that their implementations run on than
trying to shoehorn things like IMAP into CL's file API.
>> (And no doubt someone will point out that there are filesystems
>> that run on Unix that aren't like what I'm imprecisely refering to
>> as "Unix filesystems". Which doesn't change my argument.)
>
> Such as? When something runs on Unix, I assume that you mean that
> it's mounted into the VFS namespace, so it behaves like any other Unix
> filesystem, and every C program on earth that uses the Unix system
> calls will work out of the box.
Dunno. I've just learned not to be surprised by the variety of
filesystems that can and do exist.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> Yes. But there's a difference between implementations deciding to map
> the *same* underlying operations to CL functions in different ways and
> implementations that run on different OS's mapping the same CL
> functions to slightly different semantics. I think we have a (slight)
> chance of sorting out the former but the later can't be ironed out
> without mushing everything down to a lowest common denominator of all
> past, present, and future filesystems.
Ok, agreed. My point here is that for filesystems with funny
semantics (funny meaning un-Unix-like, which is what I know) a
common API won't help anyway, since the code to *interface* with
that funny API is again totally different from code you need to
interface with a standard directory tree.
(incoherent-babbling
"It's like the FTP protocol: there are provisions for OSes that
don't even have *files*, there's a built-in ASCII mode, so people
don't have to use binary mode and do the oh-so-hard
whatever-to-ASCII translation themselves later (if they need),
with another module/function/program. The result is a monolith of
a protocol with the kitchen sink included, instead of -- what I'd
like -- a simple standard that is fully specified, so everybody
implements it the same way, which would solve many problems.
When the other side of a file transfer doesn't for instance have
8bit bytes, the use of a file transfer is somewhat reduced, so why
let the client set funny modes, like with 17 bits? I'd rather
just transfer the binary bit-by-bit and let the client decide what
to do with that data. If they need to adjust/translate the data
to use it for something that's their problem. This is separating
concerns. The file-vs-record thing is separation of semantics.
If they client can't even deal with using an FTP client to
download a file, and translate it into a local record, then maybe
that guy shouldn't be transferring data in the first place...
Different FSs need different APIs, because they have different
semantics. In that case meaningful unification in one API isn't
possible, IMHO, so people shouldn't try too hard.
Like with GUIs, it isn't too hard to just write one GUI for
menuless window interfaces (Mac OS), and one for standard
Windows-like systems (Win, Gnome, KDE). At least it's better than
the alternatives(forcing a Windows GUI (written in Qt or whatever)
onto the Mac). One API for Unix/Windows, one for
Funny-system-with-records, and so on.")
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
Ulrich Hobelmann <···········@web.de> writes:
>Ok, agreed. My point here is that for filesystems with funny
>semantics (funny meaning un-Unix-like, which is what I know) a common
>API won't help anyway, since the code to *interface* with that funny
>API is again totally different from code you need to interface with a
>standard directory tree.
My proposal would be to standardize on URI strings as pathnames.
The advantage would be that it would at the same time be easy
to make network transparent, from a filename POV _and_ it can
be manipulated with ordinary string functions.
That fiddling with special opaque pathnames and assorted functions
is just plain silly, imho.
mkb.
Matthias Buelow wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>
>>Ok, agreed. My point here is that for filesystems with funny
>>semantics (funny meaning un-Unix-like, which is what I know) a common
>>API won't help anyway, since the code to *interface* with that funny
>>API is again totally different from code you need to interface with a
>>standard directory tree.
>
>
> My proposal would be to standardize on URI strings as pathnames.
> The advantage would be that it would at the same time be easy
> to make network transparent, from a filename POV _and_ it can
> be manipulated with ordinary string functions.
> That fiddling with special opaque pathnames and assorted functions
> is just plain silly, imho.
URI strings where not around at the time of the ANSI buildup (or if they
were, they were too much in their infancy)
What you are asking makes sense, however, this model already fits in the
current PATHNAME stuff. What is missing is agreement about how to go
ahead and define the behavior of PARSE-NAMESTRING when given a URI-like
string.
Next, you must consider the following: what should the following do?
(with-open-file (s "http://www.nytimes.com" :direction :input)
...)
Cheers
--
Marco
From: Edi Weitz
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <uwtnifzzn.fsf@agharta.de>
On Fri, 22 Jul 2005 14:33:22 -0400, Marco Antoniotti <·······@cs.nyu.edu> wrote:
> what should the following do?
>
> (with-open-file (s "http://www.nytimes.com" :direction :input)
> ...)
That's easy: Fill in the registration data automatically, then proceed
to the sports section... :)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Fri, 22 Jul 2005 14:33:22 -0400, Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
>> what should the following do?
>>
>> (with-open-file (s "http://www.nytimes.com" :direction :input)
>> ...)
>
> That's easy: Fill in the registration data automatically, then proceed
> to the sports section... :)
Hey, I think you should write a CLRFI for this! ;-)
From: Sam Steingold
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <u64v2k6sz.fsf@gnu.org>
> * Arthur Lemmens <········@kf4nyy.ay> [2005-07-22 20:48:16 +0200]:
>
> Edi Weitz wrote:
>
>> On Fri, 22 Jul 2005 14:33:22 -0400, Marco Antoniotti <·······@cs.nyu.edu> wrote:
>>
>>> what should the following do?
>>>
>>> (with-open-file (s "http://www.nytimes.com" :direction :input)
>>> ...)
>>
>> That's easy: Fill in the registration data automatically, then proceed
>> to the sports section... :)
>
> Hey, I think you should write a CLRFI for this! ;-)
I just did - and already submitted to the CLRFI editors!
now, if they just publish it... :-)
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.iris.org.il> <http://pmw.org.il/> <http://www.dhimmi.com/>
<http://www.openvotingconsortium.org/> <http://www.mideasttruth.com/>
If you try to fail, and succeed, which have you done?
Arthur Lemmens <········@xs4all.nl> writes:
> Edi Weitz wrote:
>
>> On Fri, 22 Jul 2005 14:33:22 -0400, Marco Antoniotti <·······@cs.nyu.edu> wrote:
>>
>>> what should the following do?
>>>
>>> (with-open-file (s "http://www.nytimes.com" :direction :input)
>>> ...)
>>
>> That's easy: Fill in the registration data automatically, then proceed
>> to the sports section... :)
>
> Hey, I think you should write a CLRFI for this! ;-)
We already have the PATHNAME-HOST. PATHNAME-DEVICE could return :INTERNET.
you'd need to add a PATHNAME-SCHEME, and PATHNAME-QUERY and little
details like that.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
From: Joe Marshall
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <y87yk3ub.fsf@ccs.neu.edu>
Matthias Buelow <···@incubus.de> writes:
> Ulrich Hobelmann <···········@web.de> writes:
>
>>Ok, agreed. My point here is that for filesystems with funny
>>semantics (funny meaning un-Unix-like, which is what I know) a common
>>API won't help anyway, since the code to *interface* with that funny
>>API is again totally different from code you need to interface with a
>>standard directory tree.
>
> My proposal would be to standardize on URI strings as pathnames.
Ugh.
They don't have the right merge semantics, they are hard to correctly
parse (just look at how many erroneous parsers are out there) and
there is this really nasty problem: a URI is a structured object.
There is a (reasonably) well-defined (but tricky) mapping from URIs to
the string that represents them, but there is no well defined mapping
from partial URIs to substrings (this is the source of most of the
parsing bugs).
> The advantage would be that it would at the same time be easy
> to make network transparent, from a filename POV _and_ it can
> be manipulated with ordinary string functions.
No, it cannot be manipulated with ordinary string functions. That's
the problem.
> That fiddling with special opaque pathnames and assorted functions
> is just plain silly, imho.
Silly, maybe, but predictable.
~jrm
Joe Marshall <···@ccs.neu.edu> writes:
>but there is no well defined mapping
>from partial URIs to substrings (this is the source of most of the
>parsing bugs).
I don't quite understand what you mean, can you give an example?
mkb.
From: Joe Marshall
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <wtnfhsij.fsf@ccs.neu.edu>
Matthias Buelow <···@incubus.de> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>>but there is no well defined mapping
>>from partial URIs to substrings (this is the source of most of the
>>parsing bugs).
>
> I don't quite understand what you mean, can you give an example?
Sorry about taking so long, my home machine wasn't well-connected.
It appears that RFC 3986 is the latest spec on URI's. I studied RFC
2396 in detail, but I may get some things wrong about RFC 3986.
A `generic' URI is a string that can be parsed into a hierarchical
sequence of components. The characters that can be in a URI are a
subset of the ASCII character set. Some of these characters are used
to delimit the components of the URI. If you want a component to
contain a delimiter, or to contain a character that is not normally
allowed in a URI, you must encode the character as a percent sign
followed by two hexidecimal characters. To correctly construct a URI
out of its components, you should encode each component prior to
concatenating them with the appropriate delimiters. Deconsructing a
URI would involve separating the URI at the delimiters and then
decoding each element. There is a little bit of a twist here in that
different characters are reserved in different parts of the URI, and
the query part of the URI has its own subcoding.
File systems can be fairly liberal about what signifies a legal file
name. Unix will take anything but a '/', Windows reserves / \ : * ? "
< > and |. So a filename like "foo.bar?x=baz" is a perfectly
reasonable (albeit unlikely) file name in unix. Simply concatenating
a filename to a URI may lead to an illegal URI, so we need to encode
the file name. But if the filename has a hierarchical relative path
component, we don't want to encode the path separators. We *may* want
to encode the '.' characters depending on whether or not they mean
something special to the file system. (In unix, there may be a
difference between `the previous directory' and the directory named by
`..')
In Windows, it is frequent to encounter file names like `My
Documents'. This would be encoded as `My%20Documents'. But
`My%20Documents' is also a legal Windows file name, which would be
encoded as `My%2520Documents'. The string
"jrm/My%20Documents/foo.txt"
could be interpreted as a relative pathname (to a file in a directory
with a percent sign in the name) or as a relative URI (to a URI path
with an encoded space in the name). Without context, there is no way
of knowing.
If we keep the components separated in a structured way, it is trivial
to create the correctly escaped form of the URI (or to create the
correctly constructed pathname).
Joe Marshall <···@ccs.neu.edu> writes:
>reasonable (albeit unlikely) file name in unix. Simply concatenating
>a filename to a URI may lead to an illegal URI, so we need to encode
>the file name. But if the filename has a hierarchical relative path
Well, the URI RfC scheme would only have to be observed when using
URIs that "connect" to the outside world (for example, when doing http
requests.) That wouldn't be necessary for filesystem stuff, where
anything following a "file://" and seperated with "/" would be
permissible (except NUL). This schema could then be backported on more
restrictive filesystems (NTFS, old Mac, etc.) where, for example, "/"
would be transformed into "\" etc. OTOH, when thinking about that, I
can't see any reason why not just use Unix pathnames in the first
place, and translate those to the local conventions of any other
system (I entertain a not completely unreasonable hope that these
systems will become obsolete in the medium run, or at least adapt to
the Unix conventions. For example, Windows has already done away with
the CP/M drive letters since NT, and afaik "/" is also principally
allowable as directory separator since early DOS days even [although
most programs made and probably still make the invalid assumption that
it's always "\"]).
mkb.
Matthias Buelow <···@incubus.de> wrote:
+---------------
| Joe Marshall <···@ccs.neu.edu> writes:
| >reasonable (albeit unlikely) file name in unix. Simply concatenating
| >a filename to a URI may lead to an illegal URI, so we need to encode
| >the file name. But if the filename has a hierarchical relative path
|
| Well, the URI RfC scheme would only have to be observed when using
| URIs that "connect" to the outside world (for example, when doing http
| requests.) That wouldn't be necessary for filesystem stuff, where
| anything following a "file://" and seperated with "/" would be
| permissible (except NUL).
+---------------
Careful! According to the RFCs, even the "file:" scheme requires a
"host" part! That's why "file:/tmp/foo" and "file://tmp/foo" are both
technically illegal[1]. If you want to refer to a file on the local
host you can write "file://localhost/tmp/foo", or as a special case
called out in the RFCs, as "file:///tmp/foo".[2] See RFCs 1738 & 3986.
-Rob
[1] Even though some browsers accept one but not the other -- and
*which* is accepted is browser-dependent!
[2] All browsers I have tested handle this form properly.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock <····@rpw3.org> wrote:
>Careful! According to the RFCs, even the "file:" scheme requires a
>"host" part! That's why "file:/tmp/foo" and "file://tmp/foo" are both
>technically illegal[1]. If you want to refer to a file on the local
>host you can write "file://localhost/tmp/foo", or as a special case
>called out in the RFCs, as "file:///tmp/foo".[2] See RFCs 1738 & 3986.
Oh, didn't know that, thanks. As it looks like, URIs take and give
little over Lisp pathnames, concerning the complexity of their
structure.
>[2] All browsers I have tested handle this form properly.
I didn't know that a hostname could go between // and /. ;-)
mkb.
From: Christopher C. Stacy
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <u8xzyfylu.fsf@news.dtpq.com>
Matthias Buelow <···@incubus.de> writes:
> My proposal would be to standardize on URI strings as pathnames.
This is an interesting idea. I wonder if anyone has
done research in other languages with this approach.
How about you write a complete portable library for
manipulating URLs, including manipulating components
of those URLs which are file names or whatever,
including transforming between pathnames and URLs.
Then get people to write a lot of programs to see
how well those libraries were designed.
Then consolidate all the inveitable different versions,
incorporating what you have learned, and publish the
resulting library and specification. Assuming this was
considered a popular and useful idea, you will then have
a de facto standard.
From: Edi Weitz
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <u1x5qhenc.fsf@agharta.de>
On Fri, 22 Jul 2005 20:25:38 +0200, Matthias Buelow <···@incubus.de> wrote:
> My proposal would be to standardize on URI strings as pathnames.
> The advantage would be that it would at the same time be easy to
> make network transparent, from a filename POV _and_ it can be
> manipulated with ordinary string functions. That fiddling with
> special opaque pathnames and assorted functions is just plain silly,
> imho.
Well, in /my/ humble opinion manipulating pathnames with string
functions is a huge step backwards, not to mention that it's un-Lispy.
If you want Perl you know where to get it...
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <uek9rvkrp.fsf@nhplace.com>
Ulrich Hobelmann <···········@web.de> writes:
> Peter Seibel wrote:
> > Another way of stating the same argument: I accept that Common Lisp's
> > file handling functions were designed to accomodate a broad variation
> > in possible file systems, broad enough perhaps to include even such
> > things as IMAP servers. That's fine. And one consequence of that
> > choice is that there's probably no single semantics for functions such
> > as PROBE-FILE that will apply with equal naturalness to all
> > filesystems.
>
> Then what's the point in having them at all? If a given API works
> totally different across implementations and operating systems, that's
> WORSE than having vendor-specific APIs that I can access. If something
> seems to work, but later fails in some spurious
> (implementation-dependent) way, you're simply screwed.
I don't want to claim you're crazy for raising this for discussion, but I
will say that the answer is not quite as cut and dried as you've made it:
First it's not the case that it does nothing similar on various
platforms. A lot of cases do work the same on all platforms. You just
have to tread lightly on certain cases. Some people find that more
livable than being forced to use a non-common thing everywhere.
A lot of code _can_ use PROBE-FILE portably and those don't have to be
marked with #+/#-.
Second, it gives you something to look up in the documentation. (And in
some--perhaps many--cases, users don't work on more than one platform,
so portability isn't an issue.)
Third, it gives vendors some reason to enter negotiations with each other
and users reasons to push them to fix discrepancies. It was assumed that
layered standards would take up the slack--e.g., that their might be a
tighter standard for the behavior on posix-compliant operating systemss, etc.
- - - -
But note that I made a smilar argument (about the consequences of
standardizing on something non-portable) in the presence of FIXNUM in
the language, and I think a few other things. For FIXNUM, it seemed
to me to have no real definition, and in fact there were at the time
(I don't know if there still are) implementations that didn't want to
provide it. (e.g., there was some Lisp that wanted ONLY the bignum
representation and did not want a specialized representation for a
subrange of those.) But here again, people cited the desire to declare
things fixnum for similar reasons to what people use types like size_t
for in C++. And FIXNUM has a guaranteed minimum size, such that if
you're using "relatively small numbers", you can just use it as a blunt
club.
pscht. Think big. Just a view into future days. Cell comes with 9 CPUs
in one chip. What if one runs windows, one runs suse, and the last runs
clisp? I'm sure, that will happen.
Peter Seibel <·····@gigamonkeys.com> writes:
>filesystems. Thus the fact that IMAP or TOPS-20 does something
>different than Unix filesystems shouldn't preclude implementations
>that actually run on Unix deciding to do things the same way when
Do we really have to bother with the likes of TOPS-20? I don't want to
start a flamewar but I consider that of hobbyist or archaeological
interest at best. The system is probably older than I am, made by a
company that (unfortunately) doesn't exist anymore, and, unlike other
systems, has stuck on its original hardware, which has been obsoleted
by the VAX almost 30 years ago, which has been obsoleted by the Alpha
15 years ago, which again has been phased out about 5 years ago.
mkb.
From: Sam Steingold
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <uy87zaf3q.fsf@gnu.org>
> * Matthias Buelow <···@vaphohf.qr> [2005-07-21 23:44:15 +0200]:
>
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>>filesystems. Thus the fact that IMAP or TOPS-20 does something
>>different than Unix filesystems shouldn't preclude implementations
>>that actually run on Unix deciding to do things the same way when
>
> Do we really have to bother with the likes of TOPS-20?
things that happened before can happen again.
history repeats itself &c.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.jihadwatch.org/>
<http://www.memri.org/> <http://www.openvotingconsortium.org/>
Those who don't know lisp are destined to reinvent it, poorly.
From: Christopher C. Stacy
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <uackfl54k.fsf@news.dtpq.com>
Matthias Buelow <···@incubus.de> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
> >filesystems. Thus the fact that IMAP or TOPS-20 does something
> >different than Unix filesystems shouldn't preclude implementations
> >that actually run on Unix deciding to do things the same way when
>
> Do we really have to bother with the likes of TOPS-20?
> I don't want to start a flamewar but I
[...figured you would just post some inflamatory nonsense?]
You are misinformed about the status of TOPS-20.
It is in active use and active development. It is being run
on new hardware and also under processor emulation environments
Christopher C. Stacy wrote:
> You are misinformed about the status of TOPS-20.
> It is in active use and active development. It is being run
> on new hardware and also under processor emulation environments
Are there any portable (PC or Mac) implementations of TOPS-20
around, to try?
Could you point to some info page or article (or book) about the
semantics of TOPS-20? I did some googling, but just as all those
operating system books out there, nobody bothers to mention what
distinguishes a TOPS-20 or ITS from other systems, only that they
exist(ed).
Most websites mention the shell, which features longer commands;
some mention COW paging and implementation stuff like that. Well,
ALL modern systems have that, so I wonder what the semantics of
these old systems are like... But then it seems that all
OS-related computer science (and compiler-related, too) focused on
implementation, not policy and structure, as can be seen in most
books on OSes and the Dragon book.
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
From: Christopher C. Stacy
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <uhdemg32f.fsf@news.dtpq.com>
Ulrich Hobelmann <···········@web.de> writes:
> Christopher C. Stacy wrote:
> > You are misinformed about the status of TOPS-20. It is in active
> > use and active development. It is being run
> > on new hardware and also under processor emulation environments
>
> Are there any portable (PC or Mac) implementations
> of TOPS-20 around, to try?
Yes. But TOPS-20 runs a DEC PDP-10 computer, and is written in
assembly language -- it is not portable. You can either buy a PDP-10
(from XKL.COM), run a PDP-10 emulator on your PC or Mac, or get a
guest account on some machine.
> Could you point to some info page or article (or book) about the
> semantics of TOPS-20? I did some googling, but just as all those
> operating system books out there, nobody bothers to mention what
> distinguishes a TOPS-20 or ITS from other systems, only that they
> exist(ed).
The extensive manual set is online.
(There used to be some tutorial books, published by
Digital Press, but I don't know if they are available
in any form. The only one I ever read was used as an
introductory programming textbook on assembler.)
I'm not sure what the most direct URLs are for the
emulator, TOPS-20 software, or the manuals.
I'd start here: http://n.webring.com/hub?ring=pdp10
I'm not a TOPS-20 expert.
Hi Peter,
could you please set up a script in whatever language you want to just
repost this message a random number of times per day... :)
Just to make sure that the point is made. :)
Cheers
--
Marco
Peter Seibel wrote:
>
> Hmmm. Maybe it's just me but I'd say Common Lisp users would benefit
> more from various implementations converging on how standard functions
> such as PROBE-FILE work on Unix and Windows-style filesystems before
> we start trying to apply them to "filesystems" such as IMAP servers.
>
> Then if CLISP, or any other implementation, really wants to provide a
> way to define an IMAP filesystem that can be operated on with the
> standard CL file and pathname functions, there's no requirement that
> all the functions behave exactly the same for all kinds of file
> systems.
>
> Another way of stating the same argument: I accept that Common Lisp's
> file handling functions were designed to accomodate a broad variation
> in possible file systems, broad enough perhaps to include even such
> things as IMAP servers. That's fine. And one consequence of that
> choice is that there's probably no single semantics for functions such
> as PROBE-FILE that will apply with equal naturalness to all
> filesystems. But that doesn't mean that it wouldn't be useful for
> implementors to agree on the semantics for *particular*
> filesystems. Thus the fact that IMAP or TOPS-20 does something
> different than Unix filesystems shouldn't preclude implementations
> that actually run on Unix deciding to do things the same way when
> dealing with a Unix filesystem. (And no doubt someone will point out
> that there are filesystems that run on Unix that aren't like what I'm
> imprecisely refering to as "Unix filesystems". Which doesn't change my
> argument.)
>
> -Peter
>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Hi Peter,
>
> could you please set up a script in whatever language you want to just
> repost this message a random number of times per day... :)
>
> Just to make sure that the point is made. :)
I'm not sure whether you're tweaking me or the folks who might miss
this point. In case it's the former--I'll shut up about it. If it's
the later, I guess you'll have to set up the script yourself.
-Peter
> Cheers
> --
> Marco
>
>
>
>
> Peter Seibel wrote:
>
>> Hmmm. Maybe it's just me but I'd say Common Lisp users would benefit
>> more from various implementations converging on how standard functions
>> such as PROBE-FILE work on Unix and Windows-style filesystems before
>> we start trying to apply them to "filesystems" such as IMAP servers.
>> Then if CLISP, or any other implementation, really wants to provide
>> a
>> way to define an IMAP filesystem that can be operated on with the
>> standard CL file and pathname functions, there's no requirement that
>> all the functions behave exactly the same for all kinds of file
>> systems.
>> Another way of stating the same argument: I accept that Common
>> Lisp's
>> file handling functions were designed to accomodate a broad variation
>> in possible file systems, broad enough perhaps to include even such
>> things as IMAP servers. That's fine. And one consequence of that
>> choice is that there's probably no single semantics for functions such
>> as PROBE-FILE that will apply with equal naturalness to all
>> filesystems. But that doesn't mean that it wouldn't be useful for
>> implementors to agree on the semantics for *particular*
>> filesystems. Thus the fact that IMAP or TOPS-20 does something
>> different than Unix filesystems shouldn't preclude implementations
>> that actually run on Unix deciding to do things the same way when
>> dealing with a Unix filesystem. (And no doubt someone will point out
>> that there are filesystems that run on Unix that aren't like what I'm
>> imprecisely refering to as "Unix filesystems". Which doesn't change my
>> argument.)
>> -Peter
>>
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Hi Peter,
>>
>>could you please set up a script in whatever language you want to just
>>repost this message a random number of times per day... :)
>>
>>Just to make sure that the point is made. :)
>
>
> I'm not sure whether you're tweaking me or the folks who might miss
> this point. In case it's the former--I'll shut up about it. If it's
> the later, I guess you'll have to set up the script yourself.
It is the second one. Is it is ok, I'll just liberally quote you :)
Cheers
--
Marco
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <ud5pbly3k.fsf@nhplace.com>
Sam Steingold <···@gnu.org> writes:
> should delete-file and probe-file work on directories?
it's implementation-dependent.
> e.g. suppose we have a file "foo" and a subdirectory "bar/".
> what should
>
> (probe-file "foo")
> (probe-file "foo/")
> (probe-file "bar")
> (probe-file "bar/")
>
> return?
Not all file systems have file-like objects in the parent directory
that correspond to them, so CL left this to implementations to resolve.
> one could argue that the first two invocations should return the same as
> (truename "foo") and the last two the same as (truename "bar/").
> one can also argue that the 2nd and 3rd should return nil - especially
> if it is possible to have same named files and subdirectories (are there
> filesystems where files and subdirectories are in different namespaces?)
>
> the issue is complicated by symbolic links - what if a file is a symlink
> to a directory...
Then you want something more elaborate than DIRECTORY, and CL didn't give
it to you.
The Lisp Machine had FS:DIRECTORY-LIST which returned something alist-like
which was (dirprops (filename1 . fileprops1) (filename2 . fileprops2) ...)
That's what you want. The committee thought it was "too much" mostly because
file systems differed so widely. It might be possible to get a better sense
of informal agreement now that there are fewer common file systems, and get
vendors to offer a set of facilities that gave more control.
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <u7jfjlxuy.fsf@nhplace.com>
Kent M Pitman <······@nhplace.com> writes:
> The Lisp Machine had FS:DIRECTORY-LIST which returned something alist-like
> which was (dirprops (filename1 . fileprops1) (filename2 . fileprops2) ...)
> That's what you want. The committee thought it was "too much" mostly because
> file systems differed so widely. It might be possible to get a better sense
> of informal agreement now that there are fewer common file systems, and get
> vendors to offer a set of facilities that gave more control.
Oops, I recall one potential objection to this:
In some file systems, it was a huge computational bottleneck to get
the whole directory listing at once.
On TOPS-20, the native file system tools could ask for something more
like what you get from with-hash-table-iterator (or from any of the
::iterator things in C++), that is, a thing that you could call to
get the next thing in the file system from a given cursor-like position.
Arguably, FS:DIRECTORY-LIST should have been replaced by something like
this that returned ALIST elements. Or perhaps both interfaces would have
been good.
This got also complicated because if you did multiple wildcards to get
the list, you'd get back potential duplicates. Some implementations don't
uniqueify/intern pathnames, while others do. (I recommend doing it.) This
makes pathnames a LOT faster to compare, or to look up via EQ hash tables.
I saw some pretty bad attempts at eliminating duplicates on file systems
where clumsy tools and poor pathname representations were used, leading
to some directory listings that took large parts of an hour to do. While
some of this is programmer stupidity, it helps when the system tools don't
invite stupid styles of programming.
Sam Steingold <···@gnu.org> writes:
> should delete-file and probe-file work on directories?
>
> e.g. suppose we have a file "foo" and a subdirectory "bar/".
> what should
>
> (probe-file "foo")
> (probe-file "foo/")
> (probe-file "bar")
> (probe-file "bar/")
>
> return?
Below is the wrapper function for PROBE-FILE from the pathnames
library I developed in my book. As you can see from this cade I'd
prefer (assuming foo and bar live in /tmp):
(probe-file "foo") => #p"/tmp/foo"
(probe-file "foo/") => NIL
(probe-file "bar") => #p"/tmp/bar/"
(probe-file "bar/") => #p"/tmp/bar/"
My theory is that (on Unix and Windows) a directory *is* a file thus
one should be able to refer to it with a pathname that has the
directory name in the :name and :type components (what I call "file
form") as well as with a pathname with NIL :name and :type components
(what I call "directory normal form"). The truename of a directory
should be in directory normal form but we should be able to refer to a
directory with a file-form pathname. However a pathname in directory
normal form always refers to a directory so (probe-file "foo/")
returns NIL because there is no *directory* named foo. (Yes, I'm
making assumptions about how parse-namestring parses "foo/";
assumptions that hold on all the implementations I've tested.)
You can see from my comments in the #+clisp section that CLISP's
current behavior made my life particularly hard. Please forgive the
somewhat cranky tone. ;-)
As far as symlinks, I'd hope it would be orthogonal to this
issue--presumably probe-file would do something like my file-exists-p
and then check whether the resulting file in the filesystem is a
symlink in order to resolve it's truename. But I haven't thought too
hard about that issue.
-Peter
(defun file-exists-p (pathname)
"Similar to CL:PROBE-FILE except it always returns directory names
in `directory normal form'. Returns truename which will be in
`directory form' if file named is, in fact, a directory."
#+(or sbcl lispworks openmcl)
;; These implementations do "The Right Thing" as far as we are
;; concerned. They return a truename of the file or directory if it
;; exists and the truename of a directory is in directory normal
;; form.
(probe-file pathname)
#+(or allegro cmu)
;; These implementations accept the name of a directory in either
;; form and return the name in the form given. However the name of a
;; file must be given in file form. So we try first with a directory
;; name which will return NIL if either the file doesn't exist at
;; all or exists and is not a directory. Then we try with a file
;; form name.
(or (probe-file (pathname-as-directory pathname))
(probe-file pathname))
#+clisp
;; Once again CLISP takes a particularly unforgiving approach,
;; signalling ERRORs at the slightest provocation.
;; pathname in file form and actually a file -- (probe-file file) ==> truename
;; pathname in file form and doesn't exist -- (probe-file file) ==> NIL
;; pathname in dir form and actually a directory -- (probe-directory file) ==> truename
;; pathname in dir form and doesn't exist -- (probe-directory file) ==> NIL
;; pathname in file form and actually a directory -- (probe-file file) ==> ERROR
;; pathname in dir form and actually a file -- (probe-directory file) ==> ERROR
(or (ignore-errors
;; PROBE-FILE will return the truename if file exists and is a
;; file or NIL if it doesn't exist at all. If it exists but is
;; a directory PROBE-FILE will signal an error which we
;; ignore.
(probe-file (pathname-as-file pathname)))
(ignore-errors
;; PROBE-DIRECTORY returns T if the file exists and is a
;; directory or NIL if it doesn't exist at all. If it exists
;; but is a file, PROBE-DIRECTORY will signal an error.
(let ((directory-form (pathname-as-directory pathname)))
(when (ext:probe-directory directory-form)
directory-form))))
#-(or sbcl cmu lispworks openmcl allegro clisp)
(error "file-exists-p not implemented"))
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
"Binghe" <··············@gmail.com> writes:
> Hi,
>
> I find a bug in your `file-exists-p' function:
> There's no `pathname-as-directory' function in cmucl, maybe you want
> `pathname-directory'
It's another function in the library from which FILE-EXISTS-P comes. See
<http://www.gigamonkeys.com/book/practical-a-portable-pathname-library.html>
for more details.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <uacken7il.fsf@nhplace.com>
"Binghe" <··············@gmail.com> writes:
> I find a bug in your `file-exists-p' function:
> There's no `pathname-as-directory' function in cmucl, maybe you want
> `pathname-directory'
I didn't look upthread to see if there's a bug, but I'm guessing
you're confused about the fix here since it's common to have a
PATHNAME-AS-DIRECTORY (which transforms a pathname's form) and it
usually does something very different than PATHNAME-DIRECTORY (which
is a standard function to read one of 6 primary slots in a pathname).
You probably need to write that function. It's usually the one that turns
#p"/bar/foo" into "/bar/foo/" by changing a pathname with
:DIRECTORY (:ABSOLUTE "BAR")
:NAME "FOO"
:TYPE :UNSPECIFIC ;or NIL or "" -- usually accepting either for input is good
:CASE :COMMON
into
:DIRECTORY (:ABSOLUTE "BAR" "FOO")
:NAME NIL ;or NIL or "" -- though NIL is most portably accepted
:TYPE NIL ;ditto
:CASE :COMMON
In some cases, the Lisp system has an implementation already if you
poke around, and it's best to use the native one if there is one.
Sam Steingold <···@gnu.org> writes:
> should delete-file and probe-file work on directories?
>
> e.g. suppose we have a file "foo" and a subdirectory "bar/".
> what should
>
> (probe-file "foo")
> (probe-file "foo/")
> (probe-file "bar")
> (probe-file "bar/")
>
> return?
>
> one could argue that the first two invocations should return the same as
> (truename "foo") and the last two the same as (truename "bar/").
> one can also argue that the 2nd and 3rd should return nil - especially
> if it is possible to have same named files and subdirectories (are there
> filesystems where files and subdirectories are in different namespaces?)
>
> the issue is complicated by symbolic links - what if a file is a symlink
> to a directory...
The best solution is to write two nice CLRFI.
- Directory management functions.
- treatment of symbolic links and similar (.lnk in MS-Windows, aliases
in MacOS/MacOSX).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
From: Sam Steingold
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <u8xzzc3xf.fsf@gnu.org>
> * Pascal Bourguignon <···@vasbezngvzntb.pbz> [2005-07-21 21:50:09 +0200]:
>
> Sam Steingold <···@gnu.org> writes:
>
>> should delete-file and probe-file work on directories?
>>
>> e.g. suppose we have a file "foo" and a subdirectory "bar/".
>> what should
>>
>> (probe-file "foo")
>> (probe-file "foo/")
>> (probe-file "bar")
>> (probe-file "bar/")
>>
>> return?
>>
>> one could argue that the first two invocations should return the same as
>> (truename "foo") and the last two the same as (truename "bar/").
>> one can also argue that the 2nd and 3rd should return nil - especially
>> if it is possible to have same named files and subdirectories (are there
>> filesystems where files and subdirectories are in different namespaces?)
>>
>> the issue is complicated by symbolic links - what if a file is a symlink
>> to a directory...
>
> The best solution is to write two nice CLRFI.
I am not interested in wasting my time on this.
As I said: I submitted a CLRFI 6 months ago,
they haven't even published it yet.
> - Directory management functions.
>
> - treatment of symbolic links and similar (.lnk in MS-Windows, aliases
> in MacOS/MacOSX).
we already have standard functions that should suffice.
we just need to clarify their behavior wrt directories and symlinks.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.memri.org/> <http://www.mideasttruth.com/>
<http://www.honestreporting.com> <http://www.iris.org.il>
The only substitute for good manners is fast reflexes.
Sam Steingold schrieb:
...
> we just need to clarify their behavior wrt directories and symlinks.
But when I want to delete a directory, I also want to delete a symlink
(or what else there may be).
As some programes do: are you sure you want to delete
<path-to-somewhere>? (yes/no).
Or print a message: directory is not empty, (delete-all/abort), when
there are subdirs or files in it.
And a return-value: directory <path> deleted.
Same to files.
Just like the opposite of create (make) a directory/file/symlink.
The only problem I see is to prove whether there are other links to that
directory or its content and no one informs the OS about the action. Can
a "nice" OS react and stop you doing so? (try to del kernel32.dll on
win98 ... NIL).
stefan
Pascal Bourguignon <···@informatimago.com> writes:
> The best solution is to write two nice CLRFI.
He's trying to figure out what the semantics should be, by asking for
the advice and opinions of others, and you tell him he should instead
write a specification?!?! Containing what? That is exactly the
*wrong* thing to do here. Geez, fetishism is obnoxious.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Pascal Bourguignon wrote:
> - treatment of symbolic links and similar (.lnk in MS-Windows, aliases
> in MacOS/MacOSX).
>
Just throwing in minor point in case anyone really could be arsed
standardising the behaviour on windows:
IMHO, any spec that would aim to treat .lnk files like symlinks on 'doze
should aim for cygwin interoperability:
.lnk files are really more like .desktop files on unix/linux with a
"modern" desktop environment (i.e. KDE and maybe GNOME), not symlinks -
i.e. they're usually interpreted by the GUI shell.
There is basically a bodge in cygwin to make .lnk files that act like
symlinks within the cygwin environment:
http://cygwin.com/faq/faq_toc.html#TOC79
"Reparse" or "junction" points in NTFS 5.0 are also a bit like symlinks
(and mounts...), but not capable of pointing to files, only
directories, IIRC.
From: Edi Weitz
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <ud5pblnud.fsf@agharta.de>
On Thu, 21 Jul 2005 23:24:41 +0100, David Golden <············@oceanfree.net> wrote:
> "Reparse" or "junction" points in NTFS 5.0 are also a bit like
> symlinks (and mounts...), but not capable of pointing to files, only
> directories, IIRC.
Not to forget:
<http://hermann.schinagl.tripod.com/nt/hardlinkshellext/hardlinkshellext.html>
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Sam Steingold <···@gnu.org> writes:
>(probe-file "foo")
>(probe-file "foo/")
Those two are distinct.
>(probe-file "bar")
>(probe-file "bar/")
Those two should be treated the same, since at least on Unix, the
directory name is "bar" and not "bar/" (the kernel normally translates
the latter into the earlier; although I vaguely remember [earlier]
Unix versions having a number of bugs afloat on this, for example when
"bar/" only worked when a directory "bar" exists, or somesuch).
mkb.
From: Sam Steingold
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <usly7aez3.fsf@gnu.org>
> * Matthias Buelow <···@vaphohf.qr> [2005-07-21 22:31:58 +0200]:
>
> Sam Steingold <···@gnu.org> writes:
>
>>(probe-file "foo")
>>(probe-file "foo/")
>
> Those two are distinct.
>
>>(probe-file "bar")
>>(probe-file "bar/")
>
> Those two should be treated the same,
this asymmetry is unaesthetic.
> since at least on Unix, the directory name is "bar" and not "bar/"
> (the kernel normally translates the latter into the earlier; although
> I vaguely remember [earlier] Unix versions having a number of bugs
> afloat on this, for example when "bar/" only worked when a directory
> "bar" exists, or somesuch).
"ls foo" and "ls foo/" can do different things on unix:
$ mkdir foo
$ ln -s foo bar
$ ls bar
1 ···@
$ ls bar/
total 0
$
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.jihadwatch.org/> <http://www.honestreporting.com>
<http://www.mideasttruth.com/> <http://www.iris.org.il> <http://ffii.org/>
Ph.D. stands for "Phony Doctor" - Isaak Asimov, Ph.D.
Sam Steingold <···@gnu.org> writes:
>"ls foo" and "ls foo/" can do different things on unix:
Hmm, ok.
This is what happens in FreeBSD:
/*
* Check for symbolic link
*/
if ((dp->v_type == VLNK) &&
((cnp->cn_flags & FOLLOW) || trailing_slash ||
*ndp->ni_next == '/')) {
cnp->cn_flags |= ISSYMLINK;
if (dp->v_mount == NULL) {
/* We can't know whether the directory was mounted with
* NOSYMFOLLOW, so we can't follow safely. */
error = EBADF;
goto bad2;
}
if (dp->v_mount->mnt_flag & MNT_NOSYMFOLLOW) {
error = EACCES;
goto bad2;
}
return (0);
}
earlier, multiple slashes are compressed to one, a trailing slash
is removed and "degenerate names" ("/.", ".") are handled specially.
So apparently, the kernel indeed treats foo/ and foo differently,
if it's a symbolic link. If it isn't (normal directory), it doesn't
make a difference.
mkb.
Sam Steingold <···@gnu.org> writes:
>
> should delete-file and probe-file work on directories?
>
> e.g. suppose we have a file "foo" and a subdirectory "bar/".
> what should
>
> (probe-file "foo")
> (probe-file "foo/")
> (probe-file "bar")
> (probe-file "bar/")
>
> return?
I think the discussion would be clearer if actual pathnames
were the arguments passed to PROBE-FILE. What is happening
above is that two issues are being conflated. The main issue
is NOT, in fact, what PROBE-FILE should do, but rather what
PARSE-NAMESTRING should do on Unix file systems.
It seems that PARSE-NAMESTRING is really where (most of) the
hair seems to lie. I'll grant that the presence of hard links,
symbolic links, aliases, shortcuts, what-have-you does complicate
the issue on a number of operating systems. In particular
there is the question of whether PARSE-NAMESTRING should even
need access to the file systems in order to perform its work.
For example, is it clearer what
(probe-file (make-pathname :name "foo"))
(probe-file (make-pathname :directory '(:relative "foo")))
(probe-file (make-pathname :name "bar"))
(probe-file (make-pathname :directory '(:relative "bar")))
should return? I would think so, although for the case
of Unix where directories are also files, it may still be
contentious.
So then the question really is about the transformation from
namestrings to pathnames, and what a reasonable (I'm tempted
to say "the proper") treatment of directories qua files should
be.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> Sam Steingold <···@gnu.org> writes:
>
>>
>> should delete-file and probe-file work on directories?
>>
>> e.g. suppose we have a file "foo" and a subdirectory "bar/".
>> what should
>>
>> (probe-file "foo")
>> (probe-file "foo/")
>> (probe-file "bar")
>> (probe-file "bar/")
>>
>> return?
>
> I think the discussion would be clearer if actual pathnames
> were the arguments passed to PROBE-FILE. What is happening
> above is that two issues are being conflated. The main issue
> is NOT, in fact, what PROBE-FILE should do, but rather what
> PARSE-NAMESTRING should do on Unix file systems.
I don't think so. I think folks have actually managed to agree on what
PARSE-NAMESTRING should do on Unix-like systems.
> It seems that PARSE-NAMESTRING is really where (most of) the hair
> seems to lie. I'll grant that the presence of hard links, symbolic
> links, aliases, shortcuts, what-have-you does complicate the issue
> on a number of operating systems. In particular there is the
> question of whether PARSE-NAMESTRING should even need access to the
> file systems in order to perform its work.
IMHO, PARSE-NAMESTRING should never have to access the file system--it
should be a purely syntactic operation.
> For example, is it clearer what
>
> (probe-file (make-pathname :name "foo"))
> (probe-file (make-pathname :directory '(:relative "foo")))
>
> (probe-file (make-pathname :name "bar"))
> (probe-file (make-pathname :directory '(:relative "bar")))
>
> should return?
Not to me. That *is* the question.
> I would think so, although for the case of Unix where directories
> are also files, it may still be contentious.
Yes, it is still contentious. Though Unix is pretty fair out of the
mainstream, as OSes go, so it's probably not worth the trouble for the
various implemenattions that happen to run on it to behave the same
way. As I've said upthread, I think both:
(probe-file (make-pathname :name "bar"))
(probe-file (make-pathname :directory '(:relative "bar")))
should return the same thing when bar is a directory. My theory is
that (make-pathname :name "bar") is another legitimate name for the
directory whose *truename* is the same as:
(merge-pathnames (make-pathname :directory '(:relative "bar")) *default-pathname-defaults*)
> So then the question really is about the transformation from
> namestrings to pathnames, and what a reasonable (I'm tempted
> to say "the proper") treatment of directories qua files should
> be.
I don't think so. I think it'd be pretty easy to put a stake in the
ground and say that on Unix (parse-namestring "bar") is the same as
(make-pathname :name "bar") and (parse-namesring "bar/") is the same
as (make-pathname :directory '(:relative "bar")). This meets the
"requirement" that PARSE-NAMESTRING not interact with the filesystem
(which is probably a bad idea anyway, since then the names of
non-existant (or not yet existing) files are parsed differently than
the names of existing files. It also has the advantage, as I mentioned
above, of being one of the few things in this area that all existing
Unix-based Common Lisp implementations I'm aware of actually agree
upon.)
But it still leaves open the question of whether a name in "file-form"
can be used to refer to a directory. I think yes. Others may differ
though I'd be interested to know why.
-Peter
P.S. Quite some time ago (shortly after I wrote pathnames chapter of
PCL) I posted some notes about the pathname system and the various
choices an implementor has when implementing pathnames on a Unixish
filesystem. Looking back at it, I see that I discussed many of these
issues perhaps more coherently than I am doing now. You can read it
at:
<http://groups-beta.google.com/group/comp.lang.lisp/msg/924a093a614d977b?hl=en&>
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Robert Uhl
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <m3y87u7cb3.fsf@4dv.net>
Peter Seibel <·····@gigamonkeys.com> writes:
>
> Though Unix is pretty fair out of the mainstream, as OSes go, so it's
> probably not worth the trouble for the various implemenattions that
> happen to run on it to behave the same way.
I don't have the figures in front of me, but I'd expect that Unix is the
most mainstream OS currently, or perhaps second after Windows. Or
possibly you meant that most OSes don't represent directories as file?
I wouldn't know about that, although it'd not be surprising.
--
Robert Uhl <http://public.xdi.org/=ruhl>
There are two ways--one of Life, and one of death. And there is a very
great difference between the two ways. --The Didache
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>>
>> Though Unix is pretty fair out of the mainstream, as OSes go, so it's
>> probably not worth the trouble for the various implemenattions that
>> happen to run on it to behave the same way.
>
> I don't have the figures in front of me, but I'd expect that Unix is the
> most mainstream OS currently, or perhaps second after Windows. Or
> possibly you meant that most OSes don't represent directories as file?
> I wouldn't know about that, although it'd not be surprising.
Actually I was going for irony. Maybe a ;-) would have helped.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Joe Marshall
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <k6jeipsu.fsf@ccs.neu.edu>
Peter Seibel <·····@gigamonkeys.com> writes:
> IMHO, PARSE-NAMESTRING should never have to access the file system--it
> should be a purely syntactic operation.
Agreed. It makes sense to name things that do not yet exist.
> But it still leaves open the question of whether a name in "file-form"
> can be used to refer to a directory. I think yes. Others may differ
> though I'd be interested to know why.
If bar is a directory, and (probe-file (make-pathname :name "bar"))
returned non-nil, a sloppy programmer might think that this implies
that bar is a file and attempt to open it.
On the other hand, it would be a royal pain in the butt to have to
perform two probes every time you wanted to query the file system.
Joe Marshall <···@ccs.neu.edu> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> IMHO, PARSE-NAMESTRING should never have to access the file system--it
>> should be a purely syntactic operation.
>
> Agreed. It makes sense to name things that do not yet exist.
>
>> But it still leaves open the question of whether a name in "file-form"
>> can be used to refer to a directory. I think yes. Others may differ
>> though I'd be interested to know why.
>
> If bar is a directory, and (probe-file (make-pathname :name "bar"))
> returned non-nil, a sloppy programmer might think that this implies
> that bar is a file and attempt to open it.
Well, in my little world, the truename of a directory is always in
"directory form" so PROBE-FILE would return such a name and you can
then cheaply tell whether the name names a directory or a file via
a predicate such as this:
(defun directory-pathname-p (p)
(flet ((component-present-p (value)
(and value (not (eql value :unspecific)))))
(and
(not (component-present-p (pathname-name p)))
(not (component-present-p (pathname-type p)))
p)))
And of course we have the converse:
(defun file-pathname-p (p)
(unless (directory-pathname-p p) p))
So I'm willing to require the programmer who wants to open a file if
it exists to do this:
(let ((p (file-pathname-p (probe-file "foo"))))
(with-open-file (in p) ...))
And I'm also willing to live with the error that will be signaled if
foo is actually a directory and I forget to check that it is a file
and write this:
(let ((p (probe-file "foo")))
(with-open-file (in p) ...)) ;; may signal an error if p is a directory.
> On the other hand, it would be a royal pain in the butt to have to
> perform two probes every time you wanted to query the file system.
Yes. And also since PROBE-FILE is required to return a truename, I'm
much more comfortable saying the truename is in "directory form" than
I am allowing for there to be two different truenames.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Joe Marshall
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <r7dlnsxv.fsf@comcast.net>
Peter Seibel <·····@gigamonkeys.com> writes:
> Well, in my little world, the truename of a directory is always in
> "directory form" ...
Of course!
--
~jrm
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <uoe8q38kf.fsf@nhplace.com>
Peter Seibel <·····@gigamonkeys.com> writes:
> I think folks have actually managed to agree on what
> PARSE-NAMESTRING should do on Unix-like systems.
> [...]
> IMHO, PARSE-NAMESTRING should never have to access the file system--it
> should be a purely syntactic operation.
well, it at least has to access some external database so that it can
tell which file host has which file system type. it is easy to show
that it can't be PURELY syntactic since f:bar might mean "unix host
f, name = bar" or "mac host local, drive = f, file name = bar" or
"pc local host, device f, name bar", or ...
i agree it probably should not check whether certain files are present or
absent.
(there's also a question of whether it should resolve various things like ~kmp
into /home/kmp.)
Kent M Pitman <······@nhplace.com> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> I think folks have actually managed to agree on what
>> PARSE-NAMESTRING should do on Unix-like systems.
>> [...]
>> IMHO, PARSE-NAMESTRING should never have to access the file system--it
>> should be a purely syntactic operation.
>
> well, it at least has to access some external database so that it
> can tell which file host has which file system type. it is easy to
> show that it can't be PURELY syntactic since f:bar might mean "unix
> host f, name = bar" or "mac host local, drive = f, file name = bar"
> or "pc local host, device f, name bar", or ...
Well I was thinking more of the case where the host argument to
PARSE-NAMESTRING was NIL and the string was *not* a syntactically
valid logical pathname namestring so the parsing is presumably going
to proceed with it's default parsing.
Just out of curiosity, do any of the existing Unix-based CLs actually
support a notion of host other than for logical pathnames?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <u8xzu4alc.fsf@nhplace.com>
Peter Seibel <·····@gigamonkeys.com> writes:
> Kent M Pitman <······@nhplace.com> writes:
>
> > Peter Seibel <·····@gigamonkeys.com> writes:
> >
> >> I think folks have actually managed to agree on what
> >> PARSE-NAMESTRING should do on Unix-like systems.
> >> [...]
> >> IMHO, PARSE-NAMESTRING should never have to access the file system--it
> >> should be a purely syntactic operation.
> >
> > well, it at least has to access some external database so that it
> > can tell which file host has which file system type. it is easy to
> > show that it can't be PURELY syntactic since f:bar might mean "unix
> > host f, name = bar" or "mac host local, drive = f, file name = bar"
> > or "pc local host, device f, name bar", or ...
>
> Well I was thinking more of the case where the host argument to
> PARSE-NAMESTRING was NIL and the string was *not* a syntactically
> valid logical pathname namestring so the parsing is presumably going
> to proceed with it's default parsing.
The implementation is allowed to infer host information from the string
even when not given a host arg. In fact, it's allowed to do whatever
it wants with the string.
> Just out of curiosity, do any of the existing Unix-based CLs actually
> support a notion of host other than for logical pathnames?
Just out of curiosity, if the answer was no would that prove anything
at all? It used to be yes. It's easy to imagine it being yes in the
future if it's not yes now.
Even today, to properly parse a filename on a PC you have to know which
file systems are FAT and which are NTFS, since I think they are subtly
different. I'm sure the same is true of Unix, actually.
Kent M Pitman <······@nhplace.com> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> Kent M Pitman <······@nhplace.com> writes:
>>
>> > Peter Seibel <·····@gigamonkeys.com> writes:
>> >
>> >> I think folks have actually managed to agree on what
>> >> PARSE-NAMESTRING should do on Unix-like systems.
>> >> [...]
>> >> IMHO, PARSE-NAMESTRING should never have to access the file system--it
>> >> should be a purely syntactic operation.
>> >
>> > well, it at least has to access some external database so that it
>> > can tell which file host has which file system type. it is easy to
>> > show that it can't be PURELY syntactic since f:bar might mean "unix
>> > host f, name = bar" or "mac host local, drive = f, file name = bar"
>> > or "pc local host, device f, name bar", or ...
>>
>> Well I was thinking more of the case where the host argument to
>> PARSE-NAMESTRING was NIL and the string was *not* a syntactically
>> valid logical pathname namestring so the parsing is presumably going
>> to proceed with it's default parsing.
>
> The implementation is allowed to infer host information from the string
> even when not given a host arg. In fact, it's allowed to do whatever
> it wants with the string.
>
>> Just out of curiosity, do any of the existing Unix-based CLs
>> actually support a notion of host other than for logical pathnames?
>
> Just out of curiosity, if the answer was no would that prove anything
> at all?
Well, I don't know about *prove* anything. My point is we're *that*
*close* to having all the Unix-based implementations agree on most
things about about how pathnames are handled. Yet there are still some
annoying differences. Exactly because it's implementation defined,
they *could* in theory agree to agree. And that agreement about
agreement is more likely the more things they already agree on. So, if
all the existing Unix-based CLs already "agree" to not support a
notion of host other than for logical pathnames then that's just one
more area that it costs nothing for them to continue agreeing
about. On the other hand, if some implementation had a notion a host
and a syntaxt for namestrings that embedded the host, then either
everyone else would have to get on board with that or they'd have to
abandon it to achieve uniformity of this area.
This is not a statement at all about whether the notion of host is
useful or not--I think it is useful, just not so much on any of the
OS's and implementations I happen to use. So as long as they're all
going to ignore it, they might as well ignore it in the same way.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <u4qai40rp.fsf@nhplace.com>
Peter Seibel <·····@gigamonkeys.com> writes:
> ... if all the existing Unix-based CLs already "agree" to not
> support a notion of host other than for logical pathnames then
> that's just one more area that it costs nothing for them to continue
> agreeing about.
I don't see the value in agreeing to be short-sighted.
Such a standard ought NOT be about being Unix-based. It ought to be about
being anything-based that touches a Unix file system.
For example, I'll take the experience of the Lisp Machine but there was
nothing about the hardware of the Lisp Machine that made it get to this
point--it was about the vision of the designers and it could certainly
be done by any implementor of a stock hardware Lisp, whether PC or MAC or
whatever:
The LispM basically did not presuppose a particular file system, and
in fact did not assume that file hosts were network hosts; that is,
there were various network hosts that had multiple file systems
(identified by multiple file hosts). What the LispM did was to say
that if you put a ":" in a namestring, the part before the first colon
was the name of a file host, and all parsing of the pathname assumed
that the part after the first colon was relative to the file system on
that file host.
(I note as an aside that VAX VMS had a different technique but a similar
concept wherein it allowed you to say FOO::BAR::BAZ:: (or maybe it was
just one colon, but I think it was two) to route around the network in a
way similar to UUCP's use of "!" and to talk about files on the host
that you reached at the other end.)
The very simple question is whether the Lisp wishes to invisibly give you
access to all of those machines. This was an ENORMOUSLY powerful feature
that the Lisp Machine had, allowing one to do things like:
(copy-file "some-unix.some-domain.com:/foo/bar/some-file.text"
"MY-MAC:HOST:DISK1:FOLDER1:SUBFOLDER7:MY-FILE.TEXT")
without writing any network code whatsoever.
My point, though, is that the LispM would have adhered to whatever
standards for Unix filenaming (if there had been any) for the Unix pathnames
it manipulated. And for Mac filenameing for the Mac pathnames. It has
NOTHING WHATSOEVER to do with what hardware is parsing the pathname whether
you have an interest in these things.
FURTHER, while I don't think there's anything wrong with a vendor who
doesn't want to offer this power, I think it's a bit ridiculous for a
vendor to enter into an agreement or to make a published statement saying
that it will never in the future decide to be thus enlightened.
It suffices to simply have the agreement say that you will make hosts of
some kind UNIX-HOST or UNIX-4.2-HOST (the lispm calls this a UNIX42-HOST,
I think, but that's a detail) or whatever and then that anyone worried
about compliance can simply test whether the file host is of the appropriate
kind. Agreeing that you will never use anything BUT one of these hosts
makes zero sense to me.
And with respect the question of how much it costs to continue agreeing not
to do stuff, I must say that's a huge price to pay. In my book, that's like
saying it costs nothing to avoid going to college and that only going forward
to college actually costs. The truth is a lot more complex.
Kent M Pitman <······@nhplace.com> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> ... if all the existing Unix-based CLs already "agree" to not
>> support a notion of host other than for logical pathnames then
>> that's just one more area that it costs nothing for them to continue
>> agreeing about.
>
> I don't see the value in agreeing to be short-sighted.
>
> Such a standard ought NOT be about being Unix-based. It ought to be
> about being anything-based that touches a Unix file system.
Just in case I haven't been clear enough about what I'm actually
advocating here it is:
I'm proposing that it would be good if Unix-based Common Lisp
implementations would agree that:
a) When PARSE-NAMESTRING is called with no explict HOST argument that
the default host be what I'll call a "unix-host".
b) When parsing namestrings for a "unix-host", namestrings are parsed
in a way that is "culturally compatible"[1] with Unix. Since there is
no notion of file hosts as part of file names in Unix file systems
there's no syntax that makes sense to a Unix head for notating such a
thing.
All this means is that the default syntax understood by
PARSE-NAMESTRING on Unix-based Common Lisp's would have no way of
expressing a host. The host could still be specified via the first
optional argument to PARSE-NAMESTRING and could still be included in
explicitly constructed pathname objects.
> And with respect the question of how much it costs to continue
> agreeing not to do stuff, I must say that's a huge price to pay. In
> my book, that's like saying it costs nothing to avoid going to
> college and that only going forward to college actually costs. The
> truth is a lot more complex.
Of course. And I didn't say that in general it doesn't cost to not do
stuff. I was saying that in general it costs implementors to
*change*--either from doing something to not or from not to doing
it. Of course, those are still short term costs that might be worth
paying to avoid longer term costs. But if some benefit (the ability
for Lispers to write pathname manipulation code that is portable
across implementations running on Unix) can be had at little or no
short term cost to implementors we're more likely to get that benefit
than if it can only be obtained at high short-term cost to one or more
implementors.
-Peter
[1] I say "culturally compatible" because it might not be crazy to
allow namestrings such as "foo/**/bar" to be parsed into
(make-pathname :directory '(:relative "foo" :wild-inferiors) :name
"bar") even though the Unix filesystem has no notion of wild
inferiors. (This seems like a relatively benign extension of the
normal unix syntax assuming a single * gets parsed into a :wild
component. I'd also hope that implementors could agree on a syntax for
escaping wildcard characters such as * (and others they may support
such as ?) since they are in fact legal characters in Unix filenames.)
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <uoe8qdrtk.fsf@nhplace.com>
Peter Seibel <·····@gigamonkeys.com> writes:
> Kent M Pitman <······@nhplace.com> writes:
>
> > Peter Seibel <·····@gigamonkeys.com> writes:
> >
> >> ... if all the existing Unix-based CLs already "agree" to not
> >> support a notion of host other than for logical pathnames then
> >> that's just one more area that it costs nothing for them to continue
> >> agreeing about.
> >
> > I don't see the value in agreeing to be short-sighted.
> >
> > Such a standard ought NOT be about being Unix-based. It ought to be
> > about being anything-based that touches a Unix file system.
>
> Just in case I haven't been clear enough about what I'm actually
> advocating here it is:
Just in case I haven't been clear about what I'm actually advocating,
here is how it differs from what you're saying:
> I'm proposing that it would be good if Unix-based Common Lisp
> implementations would agree that:
>
> a) When PARSE-NAMESTRING is called with no explict HOST argument that
> the default host be what I'll call a "unix-host".
IMO, it's ESSENTIAL to understand that PARSE-NAMESTRING is NOT intended
to parse a unix namestring. That is, by doing this (and not leaving the
"host colon" syntactic space to say that if there's a host name in the
string, it will be parsed specially), you end up shooting yourself in
the foot.
PARSE-NAMESTRING's job is to parse a representation of a pathname +
host, not to parse a pathname relative to a host, except when given a
host. What you should be advocating, IMO, is EITHER (a) some
representation of a Unix host and a definition of what happens when
PARSE-NAMESTRING is given such a host OR (b) some other function that
parses a host-specific string, that is, PARSE-HOST-NAMESTRING that takes
a host and a namestring and parses the name string as if it were a native
string on the host (WHICH A LISP NAMESTRING IS NOT).
> b) When parsing namestrings for a "unix-host", namestrings are parsed
> in a way that is "culturally compatible"[1] with Unix. Since there is
> no notion of file hosts as part of file names in Unix file systems
> there's no syntax that makes sense to a Unix head for notating such a
> thing.
This is even more problematic. There are plenty of situations even within
Unix where it may be desirable to show information about a pathname that
is not parseable. e.g., you might want to represent a :WILD-INFERIORS
pathname in a re-parseable way and you may support probing such things
with DIRECTORY even if Unix doesn't. You might use the syntax **/ for
wild inferiors even though Unix hasn't a clue what that means. It's a
totally distinct operation on a pathname to say STRING-FOR-HOST, that is,
something that would be NATIVELY acceptable to the operating system. You
completely screw up the meaning of these operators everywhere if you coopt
them for the purpose they are not intended for.
Furthermore, you're just wrong that since the Unix file system has no notion of
hosts that a Unix-based implementation would have no use for this. If they
can open a TCP FTP connection to a host on the network then they can do what
the LispM did to attach a meaning to the string
MY-PC:D:\Users\Somebody\foo.lisp
But the point is that this kind of thing, not native access to the file system,
is what the existing operations in CL are for. I advocate not overspecifying
them just because you fail to understand their purpose and confuse yourself
into thinking that they therefore have no purpose.
The right thing here is to add the additional operation STRING-FOR-HOST and
to leave the existing one alone.
> All this means is that the default syntax understood by
> PARSE-NAMESTRING on Unix-based Common Lisp's would have no way of
> expressing a host. The host could still be specified via the first
> optional argument to PARSE-NAMESTRING and could still be included in
> explicitly constructed pathname objects.
I am advocating just plain not using the term "Unix-based Common Lisp"
because you are confusing yourself into thinking these are the people
that care about Unix pathnames. The term you want to make yourself use
is "host with local or networked file access to a Unix" and then by
using that term you will find yourself realizing that all implementations
in the modern world have such access and have reason to understand these
syntaxes, and that the only way to sort it all out will be using something
like what the LispM settled on, using the "host colon" convention.
> > And with respect the question of how much it costs to continue
> > agreeing not to do stuff, I must say that's a huge price to pay. In
> > my book, that's like saying it costs nothing to avoid going to
> > college and that only going forward to college actually costs. The
> > truth is a lot more complex.
>
> Of course. And I didn't say that in general it doesn't cost to not do
> stuff. I was saying that in general it costs implementors to
> *change*--either from doing something to not or from not to doing
> it.
About 3 decades ago, I learned to program--first in FORTRAN and later in
BASIC. The BASIC I had offered two operations for character input. One
was the equivalent of read-char and the other of read-char-no-hang. At the
time, I had no one to explain to me why the latter was so ridiculously cool
and important, and at first I came to think of it like a broken version
of READ-CHAR. Thank goodness I did not at that time have access to the
language definition nor any way of changing my implementation so that I
could "fix" it to just be READ-CHAR. Sometimes one just needs to, rather
than beat a system they don't understand into submission, learn to appreciate
it.
I'm not saying that's true of every corner of CL. People have been
misquoting me (or someone) as saying that the language is perfect.
It's not. There are some things I won't defend. I am not defending
this part of the language out of blind allegiance, but out of
thoughtful understanding. The design of the pathname namestring
operators is not broken, it's incomplete. It's that way because the
X3J13 committee was afraid of adding too much stuff from the LispM
(which had this all worked out and tested in a heterogeneous networked
environment for a good solid decade by the time of CL's feature
freeze). The committee thought it conservative to just add half the
support, and all that did was to leave people confused, just as if you
added CAR and CDR but not CONS. (The right fix would not be to make CAR and
CDR do AREF--it would be to add CONS.)
I cannot say it any more plainly: I think the fix you are seeking is
the Wrong One.
> Of course, those are still short term costs that might be worth
> paying to avoid longer term costs. But if some benefit (the ability
> for Lispers to write pathname manipulation code that is portable
> across implementations running on Unix) can be had at little or no
> short term cost to implementors we're more likely to get that benefit
> than if it can only be obtained at high short-term cost to one or more
> implementors.
You see this big value of tying the Unix community together. I don't see
it. WHat I am suggesting would do that with no ill effects. What you are
suggesting would break portability, would confuse people further about
the present state of affairs (giving credence to a misunderstanding of why
things are as they are), and would limit people's imagination. Those seem
like high costs to me.
> [1] I say "culturally compatible" because it might not be crazy to
> allow namestrings such as "foo/**/bar" to be parsed into
> (make-pathname :directory '(:relative "foo" :wild-inferiors) :name
> "bar") even though the Unix filesystem has no notion of wild
> inferiors. (This seems like a relatively benign extension of the
> normal unix syntax assuming a single * gets parsed into a :wild
> component. I'd also hope that implementors could agree on a syntax for
> escaping wildcard characters such as * (and others they may support
> such as ?) since they are in fact legal characters in Unix filenames.)
The fact that users BOTH need to be able to say "give me a reliable
namestring for the host" AND need to be able to say "give me a pathname
that will work with #P, that can be reparsed by PARSE-NAMESTRING, and that
is useful in debugging is the reason that we need two operators. Don't
try to squeeze them into one just because you think they're usually the
same (which they are provably not)...
"If you have two bits of information to represent,
use two bits to represent it.
Neither coincidence nor convenience
justifies overloading a single bit."
-- Pitman's Two-Bit Rule
http://www.nhplace.com/kent/PS/EQUAL.html
Kent M Pitman <······@nhplace.com> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> Kent M Pitman <······@nhplace.com> writes:
>>
>> > Peter Seibel <·····@gigamonkeys.com> writes:
>> >
>> >> ... if all the existing Unix-based CLs already "agree" to not
>> >> support a notion of host other than for logical pathnames then
>> >> that's just one more area that it costs nothing for them to continue
>> >> agreeing about.
>> >
>> > I don't see the value in agreeing to be short-sighted.
>> >
>> > Such a standard ought NOT be about being Unix-based. It ought to be
>> > about being anything-based that touches a Unix file system.
>>
>> Just in case I haven't been clear enough about what I'm actually
>> advocating here it is:
>
> Just in case I haven't been clear about what I'm actually advocating,
> here is how it differs from what you're saying:
>
>> I'm proposing that it would be good if Unix-based Common Lisp
>> implementations would agree that:
>>
>> a) When PARSE-NAMESTRING is called with no explict HOST argument that
>> the default host be what I'll call a "unix-host".
>
> IMO, it's ESSENTIAL to understand that PARSE-NAMESTRING is NOT intended
> to parse a unix namestring. That is, by doing this (and not leaving the
> "host colon" syntactic space to say that if there's a host name in the
> string, it will be parsed specially), you end up shooting yourself in
> the foot.
>
> PARSE-NAMESTRING's job is to parse a representation of a pathname +
> host, not to parse a pathname relative to a host, except when given a
> host.
With all due respect, who says? The Hyperspec lists four bullet points
describing how PARSE-NAMESTRING parses a string. Three of them have to
do with logical namestrings which are, I hope you'll agree, not
relevant to this discussion. The fourth simply says:
"Otherwise, the parsing of thing is implementation-defined."
Given that the standard does *not* define a universal syntax for
physical pathnames, or even specify any way of embedding a host in a
physical namestring, why shouldn't PARSE-NAMESTRING parse the string
it is given using the syntax of the host it is given (if given one via
the optional HOST parameter) or using the syntax of a default host if
none is specified?
> What you should be advocating, IMO, is EITHER (a) some
> representation of a Unix host and a definition of what happens when
> PARSE-NAMESTRING is given such a host OR
That'd be fine, but it has nothing to do with how PARSE-NAMESTRING
parses a string like "/foo/bar/baz.txt" when given no host.
> (b) some other function that parses a host-specific string, that is,
> PARSE-HOST-NAMESTRING that takes a host and a namestring and parses
> the name string as if it were a native string on the host (WHICH A
> LISP NAMESTRING IS NOT).
Why does PARSE-NAMESTRING take an optional HOST argument if not to
allow it to pares a string according to the syntax of that host?
>> b) When parsing namestrings for a "unix-host", namestrings are parsed
>> in a way that is "culturally compatible"[1] with Unix. Since there is
>> no notion of file hosts as part of file names in Unix file systems
>> there's no syntax that makes sense to a Unix head for notating such a
>> thing.
>
> This is even more problematic. There are plenty of situations even within
> Unix where it may be desirable to show information about a pathname that
> is not parseable. e.g., you might want to represent a :WILD-INFERIORS
> pathname in a re-parseable way and you may support probing such things
> with DIRECTORY even if Unix doesn't. You might use the syntax **/ for
> wild inferiors even though Unix hasn't a clue what that means. It's a
> totally distinct operation on a pathname to say STRING-FOR-HOST, that is,
> something that would be NATIVELY acceptable to the operating system. You
> completely screw up the meaning of these operators everywhere if you coopt
> them for the purpose they are not intended for.
Which operators where? As far as I can tell the pathname system is
completely consistent if PARSE-NAMESTRING and NAMESTRING are
considered the API for moving between Lisp pathnames (abstract
representations of filenames) and namestrings (strings representing
filenames in some native syntax). And I'm not just guessing about
this--I spent many weeks while working on my book poring over the
standard trying to see how it all fits together to arrive at this
conclusion. If there are specific bad consequences to operations
defined by the standard to this interpretation, I'd love to know what
they are.
> Furthermore, you're just wrong that since the Unix file system has
> no notion of hosts that a Unix-based implementation would have no
> use for this.
I didn't say that Unix-based implementations have no use for it. I
just observed that the Unix *filesystem* doesn't support such a
notion.
> If they can open a TCP FTP connection to a host on the network then
> they can do what the LispM did to attach a meaning to the string
> MY-PC:D:\Users\Somebody\foo.lisp But the point is that this kind of
> thing, not native access to the file system, is what the existing
> operations in CL are for.
I'd by happy if an implementation wanted to define a way for me to
create a host so that I could say:
(defparameter *url* (make-host :type 'url))
(let ((to-copy (parse-namestring "ftp://ftp.gigamonkeys.com/foo/bar/baz.txt" *url*)))
(copy-file to-copy #p"/home/peter/baz.txt"))
and have it do the right thing. I'm just saying that I don't see the
need to be able to refer to files on any possible "host" with a single
syntax.
> I advocate not overspecifying them just because you fail to
> understand their purpose and confuse yourself into thinking that
> they therefore have no purpose.
You know, I've been trying to stick to the issues at hand but I have
to take this one opportunity to note that while I appreciate the time
you take to share your historical insights, you're pretty a
condescending fellow. Okay, back to our regularly scheduled
programming.
> The right thing here is to add the additional operation
> STRING-FOR-HOST and to leave the existing one alone.
So you say. I don't see the need for that given that NAMESTRING
already exists and that it has pretty much no choice but to return a
string that makes sense in the syntax of the host of the pathname's
host component.
>> All this means is that the default syntax understood by
>> PARSE-NAMESTRING on Unix-based Common Lisp's would have no way of
>> expressing a host. The host could still be specified via the first
>> optional argument to PARSE-NAMESTRING and could still be included in
>> explicitly constructed pathname objects.
>
> I am advocating just plain not using the term "Unix-based Common
> Lisp" because you are confusing yourself into thinking these are the
> people that care about Unix pathnames. The term you want to make
> yourself use is "host with local or networked file access to a Unix"
> and then by using that term you will find yourself realizing that
> all implementations in the modern world have such access and have
> reason to understand these syntaxes, and that the only way to sort
> it all out will be using something like what the LispM settled on,
> using the "host colon" convention.
Hmmm. I think the only way to sort it out is to not try and embed
host in namestrings. We already have a way to store host information
in the pathname object and we have a way to tell PARSE-NAMESTRING what
host's syntax it should use to parse an arbitrary string--why muck up
the namestrings themselves.
>> > And with respect the question of how much it costs to continue
>> > agreeing not to do stuff, I must say that's a huge price to pay.
>> > In my book, that's like saying it costs nothing to avoid going to
>> > college and that only going forward to college actually costs.
>> > The truth is a lot more complex.
>>
>> Of course. And I didn't say that in general it doesn't cost to not
>> do stuff. I was saying that in general it costs implementors to
>> *change*--either from doing something to not or from not to doing
>> it.
>
> About 3 decades ago, I learned to program--first in FORTRAN and
> later in BASIC. The BASIC I had offered two operations for
> character input. One was the equivalent of read-char and the other
> of read-char-no-hang. At the time, I had no one to explain to me
> why the latter was so ridiculously cool and important, and at first
> I came to think of it like a broken version of READ-CHAR. Thank
> goodness I did not at that time have access to the language
> definition nor any way of changing my implementation so that I could
> "fix" it to just be READ-CHAR. Sometimes one just needs to, rather
> than beat a system they don't understand into submission, learn to
> appreciate it.
Yeah. That's why I spent two years of my life doing pretty much
nothing but trying to understand Common Lisp, because I want to
blindly beat it into submission without trying to appreciate it.
> I'm not saying that's true of every corner of CL. People have been
> misquoting me (or someone) as saying that the language is perfect.
> It's not. There are some things I won't defend. I am not defending
> this part of the language out of blind allegiance, but out of
> thoughtful understanding. The design of the pathname namestring
> operators is not broken, it's incomplete. It's that way because the
> X3J13 committee was afraid of adding too much stuff from the LispM
> (which had this all worked out and tested in a heterogeneous
> networked environment for a good solid decade by the time of CL's
> feature freeze). The committee thought it conservative to just add
> half the support, and all that did was to leave people confused,
> just as if you added CAR and CDR but not CONS. (The right fix would
> not be to make CAR and CDR do AREF--it would be to add CONS.)
Well, that's fine. But they didn't give us the whole thought out
system. And in the meantime, the part that they did actually include
in the language also has a (I believe) perfectly consistent semantics
if physical namestrings are assumed to be "native" namestrings with
hosts, in implementations that support them, coming into only at the
point that PARSE-NAMESTRING is called. And given the rate at which
layered standards on top of the ANSI standard are being promulgated, I
think it'd be better to get some de facto standardization around stuff
that existing implementations are already pretty much doing the same
way already with the benefit that folks using Lisp will actually have
a standard and portable way to translate between native filenames and
Lisp pathnames.
> I cannot say it any more plainly: I think the fix you are seeking is
> the Wrong One.
Okay, so we disagree. Though I don't think it's because I don't
understand your position.
>> Of course, those are still short term costs that might be worth
>> paying to avoid longer term costs. But if some benefit (the ability
>> for Lispers to write pathname manipulation code that is portable
>> across implementations running on Unix) can be had at little or no
>> short term cost to implementors we're more likely to get that
>> benefit than if it can only be obtained at high short-term cost to
>> one or more implementors.
>
> You see this big value of tying the Unix community together. I don't see
> it. WHat I am suggesting would do that with no ill effects.
You know, I'm not actually sure what you're suggesting. Should this be an error:
(parse-namestring "/foo/bar/baz.txt")
because there's no host specified? If you can live with that actually
returning a pathname with :directory '(:absolute "foo" "bar"), :name
"baz" and :type "txt" then I don't think we're all that far apart. If
you think that *should* signal an error, then we're miles apart.
> What you are suggesting would break portability,
Between what and what? I think it would increase portability between
implementations running on the same OS. It might, in theory, harm
portability between implementations running on different OS's by
leading folks to rely overmuch on namestrings. But I don't think it
precludes folks doing the right thing should they decide to support
multiple kinds of hosts.
> would confuse people further about the present state of affairs
> (giving credence to a misunderstanding of why things are as they
> are), and would limit people's imagination. Those seem like high
> costs to me.
>
>> [1] I say "culturally compatible" because it might not be crazy to
>> allow namestrings such as "foo/**/bar" to be parsed into
>> (make-pathname :directory '(:relative "foo" :wild-inferiors) :name
>> "bar") even though the Unix filesystem has no notion of wild
>> inferiors. (This seems like a relatively benign extension of the
>> normal unix syntax assuming a single * gets parsed into a :wild
>> component. I'd also hope that implementors could agree on a syntax for
>> escaping wildcard characters such as * (and others they may support
>> such as ?) since they are in fact legal characters in Unix filenames.)
>
> The fact that users BOTH need to be able to say "give me a reliable
> namestring for the host"
Yes, they need this.
> AND need to be able to say "give me a
> pathname that will work with #P, that can be reparsed by
> PARSE-NAMESTRING,
I'm not so sure they need this if you mean a string that can be passed
to PARSE-NAMESTRING without specifying a host.
> and that is useful in debugging is the reason that we need two
> operators. Don't try to squeeze them into one just because you
> think they're usually the same (which they are provably not)...
>
> "If you have two bits of information to represent,
> use two bits to represent it.
> Neither coincidence nor convenience
> justifies overloading a single bit."
>
> -- Pitman's Two-Bit Rule
> http://www.nhplace.com/kent/PS/EQUAL.html
Right. That's why I'm not trying to squeeze too much into physical
namestrings. The other bit goes in the HOST argument to
PARSE-NAMESTRING.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <u4qahuz7u.fsf@nhplace.com>
Peter Seibel <·····@gigamonkeys.com> writes:
> > You see this big value of tying the Unix community together. I don't see
> > it. WHat I am suggesting would do that with no ill effects.
>
> You know, I'm not actually sure what you're suggesting. Should this be
> an error:
>
> (parse-namestring "/foo/bar/baz.txt")
No, it should parse against the default host.
But (parse-namestring "foo:x") should parse against host FOO, not
assume that the native host is a unix and that ":" is a filename
constituent under unix.
Moreover, even the fact that you have to special-case "foo:x" as a
logical pathname if foo is defined as a logical pathname host should
tell you by implication that (parse-namestring x) is not being given
an x that is a native host string. Hence, that in turn should tell
you that namestring is not giving you a native host string either,
unless you think we provided two half-protocols.
> > What you are suggesting would break portability,
>
> Between what and what? I think it would increase portability between
> implementations running on the same OS.
That's not portability. That's felicity. Helping portability for
real means helping everyone, not picking a few lucky winners and
defining them to be all that matters. If it were not possible to
solve this problem without winners and losers, you might even convince
me that such a trade-off was a good one. But since I believe there is
a well-thought-out, well-tested answer to this problem that you appear
to be advocating working away from, I feel a need to at least put
my objections on record in plain form.
> I'm not so sure they need this if you mean a string that can be passed
> to PARSE-NAMESTRING without specifying a host.
Then how does #P ever work?
Kent M Pitman <······@nhplace.com> writes:
>> > What you are suggesting would break portability,
>>
>> Between what and what? I think it would increase portability
>> between implementations running on the same OS.
>
> That's not portability. That's felicity. Helping portability for
> real means helping everyone, not picking a few lucky winners and
> defining them to be all that matters.
I don't think I'm picking winners. I may be trying to improve the
situation of some folks while not improving it for everyone but nobody
is left *worse* off. My point is that there are choices
implementations have to make about how to implement pathnames. Actual
implementations that all happen to run on the same OS have, for
historical reasons, made slightly different choices, all within the
bounds allowed by the standard but with the consequence that the same
code behaves differently in those implementations. Thus to write code
that will be portable between those implementations a programmer (me)
has to be aware of all the choices the different implementations have
made.
If, by some coincidence, all these independent implementations had
originally make the same choices then I, as a programer, wouldn't have
to be aware of those differences because they wouldn't exist. Which
doesn't mean I wouldn't have to be aware of the possibility for
*other* implementations to differ because the logic of the filesystems
they choose to support requires it. But at the moment I have to be
aware of gratuitous differences even if I know I'm going to be running
on a particular OS (or even class of OS's).
All I'm saying is that I think the several widely-used implemenations
that run on Unix today are close to agreeing on all these
implementation choices and that it would be good if they would
converge. Given that they *could* have converged by accident and in
conformance with the spec, it seems perverse to claim that they must
now *not* agree to converge.
Frankly, if the implementors all want to get together and agree that
physical namestrings should be parsed according to the host colon rule
(and define how to escape the colon so I can still parse namestrings
on a filesystem that allow colon as a legal character in a file name
or as a directory separator) and agree on how to define physical
hosts, that's fine. You've alluded to the host-colon rule from the
Lisp Machines. I assume it goes something like this:
1) Look for a leading host name made up of one or more (or zero or
more?) legal constituent characters immediately followed by an
colon. If found look up the named host. Then:
a) If a host is found, parse the rest of the string according to
the syntax of the given host.
b) If no host is found, parse the whole string (including the
putative host name and the colon) according to the syntax of
the default host.
2) If no leading host name is found, parse the whole string according
to the syntax of the default host, after unescaping any characters
escaped in the host-colon syntax (such as a colon that might
otherwis be taken for the separator following the host name.)
NAMESTRING in turn would generate names in host-colon syntax unless
the host component is NIL (or maybe :UNSPECIFIC) in which case it
would generate a hostless namestring in the syntax of the default
host. A nice additional function in the NAMESTRING, FILE-NAMESTRING,
ENOUGH-NAMESTRING, etc. family of functions would be NATIVE-NAMESTRING
which would return a hostless namestring in the syntax of the host
specified by the pathname's host component.
And, in fact I think that current implementations mostly provide a
degenerate case of this specification--because they provide no way to
define new physical hosts we always end up in leg 1b or 2 of the above
spec and end up with pathnames with a NIL host component which then
are rendered by NAMESTRING back into "native" namestrings for the
default host.
The only problem with this scheme is actually already present because
of logical pathnames: the parse of a string is dependent on what hosts
have been defined. Thus if I try to parse a string given to me by a
user who doesn't know about the host-colon syntax, I need to somehow
force a parse according to the syntax of the native host. I suppose I
could always do:
(parse-namestring x (pathname-host *default-pathname-defaults*))
or somethnig.
So unless I've misunderstood how you think things ought to work, I
don't see that what I'm proposing is actually incompatible with what
you want.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
>>>>> "Peter" == Peter Seibel <·····@gigamonkeys.com> writes:
Peter> And, in fact I think that current implementations mostly provide a
Peter> degenerate case of this specification--because they provide no way to
Peter> define new physical hosts we always end up in leg 1b or 2 of the above
Peter> spec and end up with pathnames with a NIL host component which then
Peter> are rendered by NAMESTRING back into "native" namestrings for the
Peter> default host.
Just a note that in CMUCL, pathnames (almost) never have a NIL host
component. It's either a logical host or the special internal
unix-host. Until recently there was no way to make any pathname with
a NIL host component, even with MAKE-PATHNAME because :HOST NIL was
treated as if no host were given so the default was used. This has
been changed recently so that the host is really NIL.
Ray
Raymond Toy <···········@ericsson.com> writes:
>>>>>> "Peter" == Peter Seibel <·····@gigamonkeys.com> writes:
>
> Peter> And, in fact I think that current implementations mostly
> Peter> provide a degenerate case of this specification--because
> Peter> they provide no way to define new physical hosts we
> Peter> always end up in leg 1b or 2 of the above spec and end up
> Peter> with pathnames with a NIL host component which then are
> Peter> rendered by NAMESTRING back into "native" namestrings for
> Peter> the default host.
>
> Just a note that in CMUCL, pathnames (almost) never have a NIL host
> component. It's either a logical host or the special internal
> unix-host. Until recently there was no way to make any pathname
> with a NIL host component, even with MAKE-PATHNAME because :HOST NIL
> was treated as if no host were given so the default was used. This
> has been changed recently so that the host is really NIL.
So now what is the host component of the pathname returned by:
(parse-namestring "/foo/bar/baz.txt")
? And does CMUCL support the host-colon syntax for non-logical
pathnames?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> wrote:
+---------------
| Raymond Toy <···········@ericsson.com> writes:
| > Just a note that in CMUCL, pathnames (almost) never have a NIL host
| > component. It's either a logical host or the special internal
| > unix-host. Until recently there was no way to make any pathname
| > with a NIL host component, even with MAKE-PATHNAME because :HOST NIL
| > was treated as if no host were given so the default was used. This
| > has been changed recently so that the host is really NIL.
|
| So now what is the host component of the pathname returned by:
| (parse-namestring "/foo/bar/baz.txt")
+---------------
> (pathname-host (parse-namestring "/foo/bar/baz.txt"))
""
> (describe *)
"" is a vector of length 0.
It has no fill pointer.
Its element type is specialized to BASE-CHAR.
> (eq ** nil)
NIL
>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
>>>>> "Peter" == Peter Seibel <·····@gigamonkeys.com> writes:
Peter> So now what is the host component of the pathname returned by:
Peter> (parse-namestring "/foo/bar/baz.txt")
As Rob Warnock says, the pathname-host is "", which means CMUCL's
unix-host.
Peter> ? And does CMUCL support the host-colon syntax for non-logical
Peter> pathnames?
Not really, but CMUCL still has its search-list pathnames. They look
like "home:dir1/dir2/file". Basically, a host-colon followed by a
unix-style path. And "home:" is defined to be a list of translations
somewhat like logical pathnames, but it's really more like the PATH
environment variable.
Ray
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <ull3tkwyg.fsf@nhplace.com>
Raymond Toy <···········@ericsson.com> writes:
> >>>>> "Peter" == Peter Seibel <·····@gigamonkeys.com> writes:
>
> Peter> And, in fact I think that current implementations mostly
> Peter> provide a degenerate case of this specification--because
> Peter> they provide no way to define new physical hosts we
> Peter> always end up in leg 1b or 2 of the above spec and end up
> Peter> with pathnames with a NIL host component which then are
> Peter> rendered by NAMESTRING back into "native" namestrings for
> Peter> the default host.
>
> Just a note that in CMUCL, pathnames (almost) never have a NIL host
> component.
I don't think pathnames can have a NIL component any more, I think that's
something that should have atrophied with the introduction of logical
pathname hosts.
The problem is that NIL needs to mean "unfilled", and if the local host
is some object foo, distinct from NIL. otherwise, every time you
do merge-pathnames on a pathname in the default host, you have to worry
that it's being overriden by the default from the pathname you're merging
against if it's non-NIL.
Kent M Pitman <······@nhplace.com> writes:
> Raymond Toy <···········@ericsson.com> writes:
>
>> >>>>> "Peter" == Peter Seibel <·····@gigamonkeys.com> writes:
>>
>> Peter> And, in fact I think that current implementations mostly
>> Peter> provide a degenerate case of this specification--because
>> Peter> they provide no way to define new physical hosts we
>> Peter> always end up in leg 1b or 2 of the above spec and end up
>> Peter> with pathnames with a NIL host component which then are
>> Peter> rendered by NAMESTRING back into "native" namestrings for
>> Peter> the default host.
>>
>> Just a note that in CMUCL, pathnames (almost) never have a NIL host
>> component.
>
> I don't think pathnames can have a NIL component any more, I think that's
> something that should have atrophied with the introduction of logical
> pathname hosts.
>
> The problem is that NIL needs to mean "unfilled", and if the local host
> is some object foo, distinct from NIL. otherwise, every time you
> do merge-pathnames on a pathname in the default host, you have to worry
> that it's being overriden by the default from the pathname you're merging
> against if it's non-NIL.
Actually, I'm with that--one of the other places that I think
implementors (and not just Unix-based ones) could fruitfully decide to
agree on stuff that is not quite specified in the standard is on the
distinction between NIL and :UNSPECIFIC. I think (though it's been a
while since I worked through all the details) that things would be
good if NIL always meant "waiting to be filled in" and :UNSPECIFIC
meant, "meaningless for this host". Thus the default value for
*default-pathname-defaults* would normally have a non-NIL host
component (the default host for the implementation), a non-NIL
directory component, NIL name and type components, NIL or :UNSPECIFIC
in the version component depending on whether the default host
supported versions, and :UNSPECIFIC or some reasonable default value
in device depending on whether the host supported a device component.
Some implementations seem to use return NIL for pathname components
that they don't use rather than :UNSPECIFIC. Which, within an
implementation doesn't really matter because presumably code written
for that implementation never bothers with those components
anyway. But it does make it a bit tricker to write portable pathname
code. At least that's my recollection from when I really banged my
head against the pathname system.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <ull3tkswh.fsf@nhplace.com>
Peter Seibel <·····@gigamonkeys.com> writes:
> one of the other places that I think
> implementors (and not just Unix-based ones) could fruitfully decide to
> agree on stuff that is not quite specified in the standard is on the
> distinction between NIL and :UNSPECIFIC.
Before we get tagged as just plain being disagreeable to one another, let
me say I agree with this.
My beef with the other biz was that I thought it was standardization
on bad design that could be trivially avoided by involving some people
who have knowledge of designs that have been tried before. But I do
strongly favor efforts to get implementations to make even looseknit
agreements that are reasonable and friendly to the standard, to the
other vendors, and to users that have made a good-faith effort to use
the operations in the standard in the manner intended.
> I think (though it's been a
> while since I worked through all the details) that things would be
> good if NIL always meant "waiting to be filled in" and :UNSPECIFIC
> meant, "meaningless for this host".
Rather than "meaningless for this host", which has both philosophical
questions because it sometimes carries meaning and practical problems
because neither the position is meaningless (there are other meaningful
values) nor the value is meainingless (you can have NIL and "" values),
I recommend you just contrast it as "NOT waiting to be filled" or,
in other words, "deliberately left blank". The real and true reason
that :unspecific exists is to be a null value that is not NIL so it
doesn't get merged.
> Some implementations seem to use return NIL for pathname components
> that they don't use rather than :UNSPECIFIC.
This is a bad practice of the information is important (e.g., in a
dir name). If the type is filled, it's filled. If it's not, it's not.
That's how the choice should be made.
> Which, within an
> implementation doesn't really matter because presumably code written
> for that implementation never bothers with those components
> anyway.
But if you're returning it, you're allowing it to cascade through merging
with user-defined structures, so you can't make such assumptions.
> But it does make it a bit tricker to write portable pathname
> code.
That too.
>>>>> "Kent" == Kent M Pitman <Kent> writes:
Kent> Raymond Toy <···········@ericsson.com> writes:
>> >>>>> "Peter" == Peter Seibel <·····@gigamonkeys.com> writes:
>>
Peter> And, in fact I think that current implementations mostly
Peter> provide a degenerate case of this specification--because
Peter> they provide no way to define new physical hosts we
Peter> always end up in leg 1b or 2 of the above spec and end up
Peter> with pathnames with a NIL host component which then are
Peter> rendered by NAMESTRING back into "native" namestrings for
Peter> the default host.
>>
>> Just a note that in CMUCL, pathnames (almost) never have a NIL host
>> component.
Kent> I don't think pathnames can have a NIL component any more, I think that's
Kent> something that should have atrophied with the introduction of logical
Kent> pathname hosts.
I think this is mostly true for CMUCL, except the pathname-device is
always NIL, and pathname-name, pathname-type and pathname-version can
be NIL.
Kent> The problem is that NIL needs to mean "unfilled", and if the local host
Kent> is some object foo, distinct from NIL. otherwise, every time you
Kent> do merge-pathnames on a pathname in the default host, you have to worry
Kent> that it's being overriden by the default from the pathname you're merging
Kent> against if it's non-NIL.
I'd have to dig it up from the mailing list, but someone argued that
allowing (make-pathname :host nil ...) to make a pathname with a host
NIL instead of merging with the default made sense for merging this
with other pathnames. But I've forgotten the precise details.
Ray
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <upst5kxfv.fsf@nhplace.com>
Peter Seibel <·····@gigamonkeys.com> writes:
> [...] You've alluded to the host-colon rule from the
> Lisp Machines. I assume it goes something like this:
>
> 1) Look for a leading host name made up of one or more (or zero or
> more?) legal constituent characters immediately followed by an
> colon.
I'll try to look up the rule and post it if I can find it. I've been
paraphrasing it. As I recall, you look for a colon and then parse the
preceding part according to host parsing, signaling an error if it
doesn't parse as a file host. But I'll try to double-check that.
Note what is legal host syntax may vary, but should not be assumed to
be something that the pathname parser knows about other than that
hosts do not contain colons in their names. On the Lisp Machine,
vertical bars are used to separate various other kinds of tokens. I'm
not proposing this part, but I'm remarking that the biz you wrote
about "legal constituent characters" makes me nervous because it's not
defined that way and defining it that way seems to occur that some
characters won't occur in host names, which I don't think the host
colon rule needs to imply. e.g., here are some that I think are valid
file host names in Symbolics Genera...
FOO-BAR-BAZ.COM:foo
or
INTERNET|192.168.2.1:foo
or
CHAOS|31007:...
or
INTERNET|192.168.2.17|FEP0:>Genera-8-3.ilod.3
The syntax isn't important. Compatibility with Genera is not relevant.
What is important is the syntactic room being left open for others to
experiment, and to do that, it's important not to get people used to using
these operations that were not intended as native parsers or printers
for that purpose. I do think there's a problem here, but the problem is
the absence of the correct operator, not the presence of something broken.
> If found look up the named host. Then:
>
> a) If a host is found, parse the rest of the string according to
> the syntax of the given host.
>
> b) If no host is found, parse the whole string (including the
> putative host name and the colon) according to the syntax of
> the default host.
I think maybe you signal an error, but I'll have to check.
If the user wants to take the default host, they start with a colon
as in
:D:\users\jdoe\foo.text
I think it's possible to omit the leading colon only in the case that
there are no colons in the string at all.
> So unless I've misunderstood how you think things ought to work, I
> don't see that what I'm proposing is actually incompatible with what
> you want.
It's not incompatible in effect, it's incompatible in philosophy.
You're in a position to advocate use of a correct operator for correct
reasons, and to warn people of the pitfalls of what they're doing, and
you're shirking what I perceive as your obligation to do that. You're
apparently suggesting people choose the one that coincidentally (you
used the word "degenerately", but I'm not sure that's a correct usage
of the word) works on the systems you care about rather than the one
that would reliably work on all systems. In effect, you are doing an
optimization that is ok for a programmer to do, but not for a vendor,
book writer, style advocate, language designer or pundit, or other
person in a position of community respect to encourage without due
caveats because you are effectively making an engineering trade-off
prematurely. It might well be a reasonable engineering trade-off for
an individual application developer with knowledge of his end-user
audience, the consequences of doing things sloppily, etc. to do
(defun namestring-for-host (x host)
;; Gee I wish we had a function that did this a better way
(declare (ignore host))
(namestring x))
but it's not something that language designers should be advertising
as a "correct" definition. It might even be a reasonable implementation
by a vendor internally if the vendor has specific knowledge that it will
work and the vendor is committed to changing the implementation if
circumstances ever change that would violate the implementation. But
again it's not reasonable for a vendor to tell users "oh, the right way
to implement this is ...". It might be reasonable for a vendor to say
to a user to do
(defun namestring-for-host (x host)
;; Gee I wish we had a function that did this a better way
(declare (ignore host))
#+(not mylisp)
(cerror
"Well, just use ~S instead of ~S and blunder ahead expecting lossage."
"I don't know how to implement ~*~S."
'namestring 'namestring-for-host)
(namestring x))
but again it would not be reasonable for the vendor to say "because we
agreed with three other vendors to do it this way, you can treat it as
portable and leave out the #+/#- stuff.
If people want a native-namestring kind of operation, they ought not be
relying on the felicity that NAMESTRING might yield it in the limited
case you're talking about (but their code will break if taken everywhere).
Kent M Pitman wrote:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>
>>>You see this big value of tying the Unix community together. I don't see
>>>it. WHat I am suggesting would do that with no ill effects.
>>
>>You know, I'm not actually sure what you're suggesting. Should this be
>>an error:
>>
>> (parse-namestring "/foo/bar/baz.txt")
>
>
> No, it should parse against the default host.
Exactly. Which, on a "Unix" platform, defaults to a "Unix host". Hence
you agree with Peter (and, incidentally with me and a host :) of other
CLers).
> But (parse-namestring "foo:x") should parse against host FOO, not
> assume that the native host is a unix and that ":" is a filename
> constituent under unix.
That is because of the necessary treatment of the colon as a special
separator in namestrings, as you note below.
That does not solve the issue. The problem we have to to get rid of the
"implementation defined" clauses in the PARSE-NAMESTRING and other
pathname thingies, once the host or a special syntax for hosts other
than logical ones (assuming the #\: rule).
> Moreover, even the fact that you have to special-case "foo:x" as a
> logical pathname if foo is defined as a logical pathname host should
> tell you by implication that (parse-namestring x) is not being given
> an x that is a native host string. Hence, that in turn should tell
> you that namestring is not giving you a native host string either,
> unless you think we provided two half-protocols.
Well, as a matter of fact, PARSE-NAMESTRING boils down to
"implementation dependent" stuff way too fast.
I believe that Peter (and I) is arguing that PARSE-NAMESTRING can be
hammered down to do almost TRT on a given host (logical or otherwise).
In other words, agreement can be achieved to make sure that
implementation A and implementation B do the same thing when
PARSE-NAMESTRING is called. Even in the presence of a
"<host-of-some-kind-not-necessarily-logical>:<host-specific-namestring-possibly-with-colons-escaped>"
syntax.
Cheers
--
Marco
Peter Seibel wrote:
>
> b) When parsing namestrings for a "unix-host", namestrings are parsed
> in a way that is "culturally compatible"[1] with Unix. Since there is
> no notion of file hosts as part of file names in Unix file systems
> there's no syntax that makes sense to a Unix head for notating such a
> thing.
scp does use ····@host:/path/to/file
just a thought, i have no idea if that makes any difference to the argument
-Antony
Antony Sequeira <··········@hotmail.com> wrote:
+---------------
| Peter Seibel wrote:
| > b) When parsing namestrings for a "unix-host", namestrings are parsed
| > in a way that is "culturally compatible"[1] with Unix. Since there is
| > no notion of file hosts as part of file names in Unix file systems
| > there's no syntax that makes sense to a Unix head for notating such a
| > thing.
| scp does use ····@host:/path/to/file
+---------------
As does "rsync". And "tar" uses "host:/path", e.g.:
tar cvf my.dom.ain:/dev/nrmt1 .
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <uvf2wtr2y.fsf@nhplace.com>
····@rpw3.org (Rob Warnock) writes:
> Antony Sequeira <··········@hotmail.com> wrote:
> +---------------
> | Peter Seibel wrote:
> | > b) When parsing namestrings for a "unix-host", namestrings are parsed
> | > in a way that is "culturally compatible"[1] with Unix. Since there is
> | > no notion of file hosts as part of file names in Unix file systems
> | > there's no syntax that makes sense to a Unix head for notating such a
> | > thing.
> | scp does use ····@host:/path/to/file
> +---------------
>
> As does "rsync". And "tar" uses "host:/path", e.g.:
>
> tar cvf my.dom.ain:/dev/nrmt1 .
fwiw, Emacs ange-ftp (m-x info then Emacs, Files, Remote Files) claims to use:
/HOST:FILENAME
·····@HOST:FILENAME
·····@HOST#PORT:FILENAME
From: Robert Uhl
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <m33bq0c85b.fsf@4dv.net>
Peter Seibel <·····@gigamonkeys.com> writes:
>
> [1] I say "culturally compatible" because it might not be crazy to
> allow namestrings such as "foo/**/bar" to be parsed into
> (make-pathname :directory '(:relative "foo" :wild-inferiors) :name
> "bar") even though the Unix filesystem has no notion of wild
> inferiors.
Actually, no Unix filesystem I know has any notion of wildcards; all
that kind of thing is performed by the shell (which is why some shells
still don't support ~ or {} expansion).
--
Robert Uhl <http://public.xdi.org/=ruhl>
I sat around during the design phase going `this is going to suck so
badly that we're going to have to hold onto desks to stop us from being
drawn into the vortex.' --Chris Saunderson
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>>
>> [1] I say "culturally compatible" because it might not be crazy to
>> allow namestrings such as "foo/**/bar" to be parsed into
>> (make-pathname :directory '(:relative "foo" :wild-inferiors) :name
>> "bar") even though the Unix filesystem has no notion of wild
>> inferiors.
>
> Actually, no Unix filesystem I know has any notion of wildcards; all
> that kind of thing is performed by the shell (which is why some shells
> still don't support ~ or {} expansion).
Indeed. And, Peter, ksh knows about wild inferiors, I'm told.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Pascal Bourguignon <···@informatimago.com> writes:
> Robert Uhl <·········@NOSPAMgmail.com> writes:
>
>> Peter Seibel <·····@gigamonkeys.com> writes:
>>>
>>> [1] I say "culturally compatible" because it might not be crazy to
>>> allow namestrings such as "foo/**/bar" to be parsed into
>>> (make-pathname :directory '(:relative "foo" :wild-inferiors) :name
>>> "bar") even though the Unix filesystem has no notion of wild
>>> inferiors.
>>
>> Actually, no Unix filesystem I know has any notion of wildcards; all
>> that kind of thing is performed by the shell (which is why some shells
>> still don't support ~ or {} expansion).
>
> Indeed. And, Peter, ksh knows about wild inferiors, I'm told.
Both points are well taken. Which is why I used the somewhat loose
phrase "culturally compatible": there's probably no single syntax that
can lay claim to being the canonical "Unix filename syntax". Some
folks might claim the canonical syntax is the one thas is understood
by the system calls that deal with files and others may claim that the
shell is a integral part of Unix. (Which raises the question, as
Pascal points out, which shell?)
My point was that the syntax understood by PARSE-NAMESTRING when
parsing for the default host on a Unix-based Lisp should be some
syntax that doesn't look foreign to a Unix user. Since ksh in fact
seems to use ** to indicate something very much like :wild-inferiors
that seems like a reasonable option if we want to support wildcards at
all in the syntax.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> wrote:
>phrase "culturally compatible": there's probably no single syntax that
>can lay claim to being the canonical "Unix filename syntax". Some
>folks might claim the canonical syntax is the one thas is understood
>by the system calls that deal with files and others may claim that the
>shell is a integral part of Unix. (Which raises the question, as
>Pascal points out, which shell?)
The "Single UNIX Specification"[1] (IEEE 1003.1, 2004 edition) marks
glob(3) as "mandated" in UNIX98 (and hence probably also UNIX03)
and the standards text tells us the following:
``The glob() function is a pathname generator that shall implement
the rules defined in the Shell and Utilities volume of IEEE Std
1003.1-2001, Section 2.13, Pattern Matching Notation, with optional
support for rule 3 in the Shell and Utilities volume of IEEE Std
1003.1-2001, Section 2.13.3, Patterns Used for Filename Expansion.''
The respective paragraphs in the "Shell Command Language" document
list the *, ? and [ characters as matching a single character (the
latter starting a pattern bracket expression, with the ! replacing
the ^ (as used in Unix regular expression syntax) as the complementation
operator of the set produced by a bracket expression.
If you want to know the details, view the respective document. I
can't post an URL here since the site requires some dumb "registration"
(just type your name and email address, etc.) and relies on cookies
to "authenticate" the viewer (it's a standards body after all <...>).
mkb.
[1] http://www.unix.org/single_unix_specification/
Kent M Pitman schrieb:
> Peter Seibel <·····@gigamonkeys.com> writes:
> > ... if all the existing Unix-based CLs already "agree" to not
> > support a notion of host other than for logical pathnames then
> > that's just one more area that it costs nothing for them to continue
> > agreeing about.
> I don't see the value in agreeing to be short-sighted.
> Such a standard ought NOT be about being Unix-based. It ought to be about
> being anything-based that touches a Unix file system.
...
> The LispM basically did not presuppose a particular file system, and
> in fact did not assume that file hosts were network hosts; that is,
> there were various network hosts that had multiple file systems
> (identified by multiple file hosts). What the LispM did was to say
> that if you put a ":" in a namestring, the part before the first colon
> was the name of a file host, and all parsing of the pathname assumed
> that the part after the first colon was relative to the file system on
> that file host.
Well, in the future days, file-system may be a big point of security
interests. So from now it is hard to say, what ways will be there to get
access to a file anywhere. What will Lisp do then? You can call a OS
function for that, but some times later, you need a handful OS specific
calles for some different "secure" file-systems. This can grow to a
monster, see what it is today. When looking at the history of the way
Lisp does handle access to file systems on existing OS's, I can say:
endless patch work. And it looks like every new variation to a
file-system will produce a new patch to handle it in Lisp, untill some
(ie. one) vendors decide not to publish the internals (patents will do
the rest).
stefan
when you want it to be done, do it yourself.
Peter Seibel wrote:
>
> Well I was thinking more of the case where the host argument to
> PARSE-NAMESTRING was NIL and the string was *not* a syntactically
> valid logical pathname namestring so the parsing is presumably going
> to proceed with it's default parsing.
>
> Just out of curiosity, do any of the existing Unix-based CLs actually
> support a notion of host other than for logical pathnames?
CMUCL/SBCL have non NIL hosts.
* (describe (pathname "foo/bar.baz"))
#p"foo/bar.baz" is a structure of type PATHNAME.
HOST: #<COMMON-LISP::UNIX-HOST>.
DEVICE: NIL.
DIRECTORY: (:RELATIVE "foo").
NAME: "bar".
TYPE: "baz".
VERSION: :NEWEST.;
*
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Peter Seibel wrote:
>
>> Well I was thinking more of the case where the host argument to
>> PARSE-NAMESTRING was NIL and the string was *not* a syntactically
>> valid logical pathname namestring so the parsing is presumably going
>> to proceed with it's default parsing.
>> Just out of curiosity, do any of the existing Unix-based CLs
>> actually
>> support a notion of host other than for logical pathnames?
>
> CMUCL/SBCL have non NIL hosts.
>
> * (describe (pathname "foo/bar.baz"))
>
> #p"foo/bar.baz" is a structure of type PATHNAME.
> HOST: #<COMMON-LISP::UNIX-HOST>.
> DEVICE: NIL.
> DIRECTORY: (:RELATIVE "foo").
> NAME: "bar".
> TYPE: "baz".
> VERSION: :NEWEST.;
> *
So how do I define a new host?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Peter Seibel wrote:
>>
>>
>>>Well I was thinking more of the case where the host argument to
>>>PARSE-NAMESTRING was NIL and the string was *not* a syntactically
>>>valid logical pathname namestring so the parsing is presumably going
>>>to proceed with it's default parsing.
>>>Just out of curiosity, do any of the existing Unix-based CLs
>>>actually
>>>support a notion of host other than for logical pathnames?
>>
>>CMUCL/SBCL have non NIL hosts.
>>
>>* (describe (pathname "foo/bar.baz"))
>>
>>#p"foo/bar.baz" is a structure of type PATHNAME.
>>HOST: #<COMMON-LISP::UNIX-HOST>.
>>DEVICE: NIL.
>>DIRECTORY: (:RELATIVE "foo").
>>NAME: "bar".
>>TYPE: "baz".
>>VERSION: :NEWEST.;
>>*
>
>
> So how do I define a new host?
Excellent question. I think the current answer is - unfortunately - mu.
CMUCL/SBCL have some way of doing it, however, I don't have it on my
fingertips now.
Apart from that, Peter, I agree with you wholeheartedly in this thread.
Cheers
--
Marco
From: Joe Marshall
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <r7dkco4s.fsf@ccs.neu.edu>
Peter Seibel <·····@gigamonkeys.com> writes:
> IMHO, PARSE-NAMESTRING should never have to access the file system--it
> should be a purely syntactic operation.
Rather than trying to `fix' parse-namestring, perhaps it would be
better to create a new function that does what you want.
1. A universal string representation for pathnames such that every
constructable pathname object can be uniquely and unambiguously
transformed to string form and back. (Logical pathnames aren't
quite sufficient for this, nor were they designed for it.)
2. Pathname parser/unparser pairs that are selected by a `syntax'
specifier.
(merge-pathnames
(parse-pathname :dos "C:\\Documents and Settings\\")
(parse-pathname :unix "cygwin/cygwin.dll"))
Perhaps the syntax specifier should be part of the string,
though. (parse-pathname "dos!C:\\Documents and Settings\\")
~jrm
Joe Marshall <···@ccs.neu.edu> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> IMHO, PARSE-NAMESTRING should never have to access the file system--it
>> should be a purely syntactic operation.
>
> Rather than trying to `fix' parse-namestring, perhaps it would be
> better to create a new function that does what you want.
>
> 1. A universal string representation for pathnames such that every
> constructable pathname object can be uniquely and unambiguously
> transformed to string form and back. (Logical pathnames aren't
> quite sufficient for this, nor were they designed for it.)
Well, Kent is claiming that this is what PARSE-NAMESTRING *is meant to
parse* while beating me up for suggesting that maybe we try to get
implementors to at least make it a reliable parser of names on the
"native" filesystem of the OS they run on. He also tells me I should
create a new function that does what I want which is to reliably parse
a native filename.
> 2. Pathname parser/unparser pairs that are selected by a `syntax'
> specifier.
>
> (merge-pathnames
> (parse-pathname :dos "C:\\Documents and Settings\\")
> (parse-pathname :unix "cygwin/cygwin.dll"))
Isn't that what the HOST argument to PARSE-NAMESTRING is for?
>
> Perhaps the syntax specifier should be part of the string,
> though. (parse-pathname "dos!C:\\Documents and Settings\\")
And this brings us to Kent's Lisp Machine-inspired host-colom rule.
You know, I used to try and defend the pathname system as not being
irredeemably confusing but I'm beginning to think it's a lost cause.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Joe Marshall
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <ek9kcjwv.fsf@ccs.neu.edu>
Peter Seibel <·····@gigamonkeys.com> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> Peter Seibel <·····@gigamonkeys.com> writes:
>>
>>> IMHO, PARSE-NAMESTRING should never have to access the file system--it
>>> should be a purely syntactic operation.
>>
>> Rather than trying to `fix' parse-namestring, perhaps it would be
>> better to create a new function that does what you want.
>>
>> 1. A universal string representation for pathnames such that every
>> constructable pathname object can be uniquely and unambiguously
>> transformed to string form and back. (Logical pathnames aren't
>> quite sufficient for this, nor were they designed for it.)
>
> Well, Kent is claiming that this is what PARSE-NAMESTRING *is meant to
> parse* while beating me up for suggesting that maybe we try to get
> implementors to at least make it a reliable parser of names on the
> "native" filesystem of the OS they run on.
Yeah, well, if the host argument isn't supplied (and logical pathnames
aren't being used), the behavior is implementation-defined.
> He also tells me I should create a new function that does what I
> want which is to reliably parse a native filename.
>
>> 2. Pathname parser/unparser pairs that are selected by a `syntax'
>> specifier.
>>
>> (merge-pathnames
>> (parse-pathname :dos "C:\\Documents and Settings\\")
>> (parse-pathname :unix "cygwin/cygwin.dll"))
>
> Isn't that what the HOST argument to PARSE-NAMESTRING is for?
The problem is that you don't really care what the host is (it need
not be reachable, or even exist), you just want to change a string
into a pathname more concisely than (make-pathname ...)
> You know, I used to try and defend the pathname system as not being
> irredeemably confusing but I'm beginning to think it's a lost cause.
I agree.
Joe Marshall <···@ccs.neu.edu> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> Joe Marshall <···@ccs.neu.edu> writes:
>>
>>> Peter Seibel <·····@gigamonkeys.com> writes:
>>>
>>>> IMHO, PARSE-NAMESTRING should never have to access the file system--it
>>>> should be a purely syntactic operation.
>>>
>>> Rather than trying to `fix' parse-namestring, perhaps it would be
>>> better to create a new function that does what you want.
>>>
>>> 1. A universal string representation for pathnames such that every
>>> constructable pathname object can be uniquely and unambiguously
>>> transformed to string form and back. (Logical pathnames aren't
>>> quite sufficient for this, nor were they designed for it.)
>>
>> Well, Kent is claiming that this is what PARSE-NAMESTRING *is meant to
>> parse* while beating me up for suggesting that maybe we try to get
>> implementors to at least make it a reliable parser of names on the
>> "native" filesystem of the OS they run on.
>
> Yeah, well, if the host argument isn't supplied (and logical pathnames
> aren't being used), the behavior is implementation-defined.
Right, and my main point is as long as it's implementation-defined,
maybe folks could agree to do the *same* thing when they're all
running on Unix. (And if we can get that together then maybe we can
define a slightly more expansive "same thing" that will account for
Windows too.)
>> He also tells me I should create a new function that does what I
>> want which is to reliably parse a native filename.
>>
>>> 2. Pathname parser/unparser pairs that are selected by a `syntax'
>>> specifier.
>>>
>>> (merge-pathnames
>>> (parse-pathname :dos "C:\\Documents and Settings\\")
>>> (parse-pathname :unix "cygwin/cygwin.dll"))
>>
>> Isn't that what the HOST argument to PARSE-NAMESTRING is for?
>
> The problem is that you don't really care what the host is (it need
> not be reachable, or even exist), you just want to change a string
> into a pathname more concisely than (make-pathname ...)
But you need to know what syntax you want to use and since each host
defines (among other things) the syntax it supports within the current
API it seems like passing a host of the appropriate type (any will do
as long as it's of the appropriate type) is a good way to indicate
what syntax you want to use. I'll agree that this isn't maybe the
tastiest thing I can imagine but I'm more interested in finding a
reasonable interpretation of the existing language operators that
allows people to get work done rather than holding out for the day
when implementors will all agree on some perfect API.
I think this may be the root of my disagreement with Kent--while the
full-on Lisp Machine pathname system may have been a thing of beauty
that did the right thing in all respects, X3J13 didn't give us the
whole thing. So we have to muddle along with what we've got and I
think (and the behavior of most implementations seems to bear this
out) that people are more interested in having functions for dealing
with actual filenames from the filesystems they are using than in a
whole extra Lisp-specific layer of filenames designed for dealing with
"hosts" which are themselves not portable (because nothing about them
except that they could exist is specified in the standard).
I'm happy to try and find a way to solve what I see as the present-day
practical problem of dealing with actual files and filenames in the
syntax of the filesystem on which my program is running without making
it impossible for som ambitious implementation to come along and
reimplement the full-on Lisp Machine-style host system. But to say
that the real purpose of PARSE-NAMESTRING, et al. is to provide an
interface to a Lisp-implemented host-rich virtual filesystem seems
like wishful thinking given what was actually standardized. I realize
that this point of view is probably going to make Kent happing mad all
over again. I can only hope that he perhaps now will accept that that
I actually understand his point of view; I just don't agree with it.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Joe Marshall
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <slxzom1p.fsf@comcast.net>
Peter Seibel <·····@gigamonkeys.com> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> Peter Seibel <·····@gigamonkeys.com> writes:
>>
>>> Joe Marshall <···@ccs.neu.edu> writes:
>>>
>>>> Peter Seibel <·····@gigamonkeys.com> writes:
>>>>
[etc. etc. etc.]
This is where I give up on string representations and just use
make-pathname. At least it is predictable.
--
~jrm
From: Kent M Pitman
Subject: Re: delete-file & probe-file on directories
Date:
Message-ID: <uoe8nbn70.fsf@nhplace.com>
Peter Seibel <·····@gigamonkeys.com> writes:
> ... I realize
> that this point of view is probably going to make Kent happing mad all
> over again. ...
Whether I am or am not mad is not relevant. It's a metric of whether
I care about something. But ultimately what happens or does not
happen should be based on my technical arguments. Sometimes I get
passionate. Worse things could happen. Sometimes I figure maybe it
helps people to know what things I care about and what I don't.
Sometimes it's just not worth my time to edit out the passion since I
have limited time and I figure people who care can dig through it and
people who don't care can skip it easily enough. Sorry about that.
But please don't think of my being upset as being intended to be
itself an actual impediment. My voice is just one of many. Others
get passionate, too. And that's fine, too. It's important for people
to be on the record, I think. We're all only on earth for a finite
time and maybe some day someone will wonder. I sometimes think of
this group as a kind of insurance against my not getting a chance to
record my thoughts in some other place. (Then again, sometimes it
becomes the reason they don't get recorded there. Ther's a balance to
be struck, and lately I post less--believe it or not--and have been
building a repository of unposted stuff for use in other venues... which
hopefully I'll actually get to.)
Kent M Pitman <······@nhplace.com> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> ... I realize
>> that this point of view is probably going to make Kent happing mad all
>> over again. ...
>
> Whether I am or am not mad is not relevant.
And you may have noticed it didn't stop my from saying my piece. ;-)
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> You know, I used to try and defend the pathname system as not being
> irredeemably confusing but I'm beginning to think it's a lost cause.
I have *not* given careful study and consideration to CL pathnames, but
I'd like to present some food for thought.
The trend in computing has been for operating systems to attempt to hide
the differences between native and foreign filesystems. The CD-ROM spec
calls for 8.3 filenames and no ownership or permission information.
Vendors have created extensions, so users now see files with long, mixed
case names and metadata. Similarly, UNIX users don't see paths like
/remote-mounts/a-windows-box/C:\WINDOWS\YOU-LOSE.EXE and Windows users
don't see \\ucbvax\var/spool/news
Kent's comments about UNIX pathname manipulation functions being handy
for anyone whose Lisp has connectivity to a UNIX box set off alarm bells
for me. What happens if UCBVAX is running BSD on Friday, but Central
Services upgrades it to VMS over the weekend? Do pathnames have to
change, even if the host's name hasn't and its exposed file hierarchy
appears the same? This kind of stuff happens all the time and the trend
has been away from direct manipulation of foreign pathnames in userland.
One of the operating systems handles pathname translation, and the users
and application programmers see a mostly seamless namespace.
Users have enough trouble remembering which slash is the 'backslash' and
which one is 'forward slash.' Must they know what operating system is
running on their remote mounts, and what that OS's filename conventions
are? It seems inevitable that if application programmers are given that
power and responsibility, a good portion of them will punt to the end
user, exposing foreign pathname conventions.
Anyway, if I'm confused and nonsensical, please ignore. Pathname
manipulation functions suck all over -- just look at all the security
problems exposed by bad pathname code parsing
http://insecure.box/../../../../etc/passwd (and Windows equivalents). It
is obvious to me why a Lisp Machine would have needed all the elements
of the pathname system, but I am undecided whether today the
responsibility shouldn't just be delegated to the operating system.
--
Cameron MacKinnon
Toronto, Canada
Marco Antoniotti schrieb:
> Joe Marshall wrote:
> > Peter Seibel <·····@gigamonkeys.com> writes:
> >>IMHO, PARSE-NAMESTRING should never have to access the file system--it
> >>should be a purely syntactic operation.
> > Rather than trying to `fix' parse-namestring, perhaps it would be
> > better to create a new function that does what you want.
...
> Yes. But this is accomodatable in PARSE-NAMESTRING. I think it is
> better to fix what's broken (given that IMO it is fixable) than leave it
> around and then add new stuff.
No. I think not. This is endless fixing and patch-work.
...
> It does create the problem of introducing new interpretation for the
> PATHNAME fields (and, I'll concede, maybe new fields altogether), but
> that is a matter of future agreement.
To give another piont of solving. Make a GUI, call the OS file-manager
(say Midnight Commander) and bring that to the screen. Now you just have
to click on what you want to be opend for your work and needles to say:
save that for later use as an object.
Means some people in here are not willing to see others than a
command-line. Here it seems a border is found.
stefan
lin8080 wrote:
>
> Marco Antoniotti schrieb:
>
>>Joe Marshall wrote:
>>
>>>Peter Seibel <·····@gigamonkeys.com> writes:
>
>
>>>>IMHO, PARSE-NAMESTRING should never have to access the file system--it
>>>>should be a purely syntactic operation.
>
>
>>>Rather than trying to `fix' parse-namestring, perhaps it would be
>>>better to create a new function that does what you want.
>
> ...
>
>
>>Yes. But this is accomodatable in PARSE-NAMESTRING. I think it is
>>better to fix what's broken (given that IMO it is fixable) than leave it
>>around and then add new stuff.
>
>
> No. I think not. This is endless fixing and patch-work.
In this case I think it is not (I may be wrong). I am saying that
because the spec of PARSE-NAMESTRING has nasty "implementation
dependent" clauses in its guts. What irks people like me is that
different implementations do different things.
The case of (pathname-device "C:\\foo\\bar.baz") being one of them.
Cheers
--
Marco
Thomas A. Russ wrote:
> I would think so, although for the case
> of Unix where directories are also files, it may still be
> contentious.
Just throwing in:
Linux with ReiserFS4... where files are also directories - if
you open a file as a file, you get it's contents, if you open it as a
directory, you might get, um, other stuff (various metadata...)
http://www.namesys.com/v4/v4.html#files_dirs