Hi,
After some study of CL pathnames, I decided that I would rather use
something else. Are there any alternatives available?
I find the elisp interface a bit more reasonable. Has anyone tried to
port this to some CL?
Regards,
Mario.
Mario S. Mommer wrote:
> Hi,
>
> After some study of CL pathnames, I decided that I would rather use
> something else. Are there any alternatives available?
No.
>
>
> I find the elisp interface a bit more reasonable. Has anyone tried to
> port this to some CL?
No it is not. PATHANMES are bewildering because of glitches across
different implementations and because of strange behavior under UNIX in
certain pathological cases. Something better should be constructed *on
top* of them, not in alternative to them.
Cheers
--
Marco Antoniotti
Marco Antoniotti <·······@cs.nyu.edu> writes:
> PATHANMES are bewildering because of glitches across different
> implementations and because of strange behavior under UNIX in
> certain pathological cases. Something better should be constructed
> *on top* of them, not in alternative to them.
KMP has admitted that it is not completely clear from the spec how
PATHNAMES should work, and I've seen unresolved disagreement on the
behavior of these things among knowledgeable people, so in essence
they are unreliable. Nobody disagrees on what the rules are on unix
and dos, or mac, for instance. If on such a machine, I'd rather get
the behavior I'm thinking of, instead of fighting some construct that
is supposed to help me but is not doing so, and relying on some
portability which just isn't there.
It's just my personal opinion, anyway. I just find them PATHNAMES
artificial and baroque, and if given a reasonable choice I would use
something else /in *my* programs/. And before I implement some
alternative I wanted to know if someone has done so already.
Mario.
Mario S. Mommer wrote:
> Marco Antoniotti writes:
>
> > PATHANMES are bewildering because of glitches across different
> >implementations and because of strange behavior under UNIX in
> >certain pathological cases. Something better should be constructed
> >*on top* of them, not in alternative to them.
>
>
> KMP has admitted that it is not completely clear from the spec how
> PATHNAMES should work, and I've seen unresolved disagreement on the
> behavior of these things among knowledgeable people, so in essence
> they are unreliable. Nobody disagrees on what the rules are on unix
> and dos, or mac, for instance. If on such a machine, I'd rather get
> the behavior I'm thinking of, instead of fighting some construct that
> is supposed to help me but is not doing so, and relying on some
> portability which just isn't there.
>
> It's just my personal opinion, anyway. I just find them PATHNAMES
> artificial and baroque, and if given a reasonable choice I would use
> something else /in *my* programs/. And before I implement some
> alternative I wanted to know if someone has done so already.
My point was that alternatives do not come easily.
Why don't you list a set of desiderata yopu want in the current PATHNAME
stuff and ask the implementors to agree on them?
AFAIK, this has not happened yet (and maybe this is something I should
have done).
Cheers
--
Marco Antoniotti
Marco Antoniotti <·······@cs.nyu.edu> writes:
> My point was that alternatives do not come easily.
Ok.
> Why don't you list a set of desiderata yopu want in the current
> PATHNAME stuff
Well, here is how i think it would be better.
* Less components or no components at all: just strings. Instead of
host, directory, device, name, type, and version, just a name. The
generality is just not there anyways: you cannot specify (for
example) the protocol (if you would like to open "http://..."). If
some program needs versions (for instance), it should implement that
itself.
* Use native tongue. What's the fuzz with the ";" char? And why do
some lisp complain that "/home/mommer/data/whatever.dat" is a silly
unix pathname? (huh?)
Anything else would just work:
* The need for configuration-dependant pathnames can be solved by
using standard globals, which could be set by hand or by consulting
the host system.
* If you need "my-proggy.lisp" relative to
"/magnus/faustus/galacticus/" just use CONCATENATE.
* Wildcards should work like in the underlying system. Better yet:
they should just refer to the underlying system, because it knows
best (by definition) how to resolve these things.
What functionality would be missing? Yes, the utilities everybody
needs: given a name, extract the directory, maybe the device (if this
makes any sense on the system), but these could do that by parsing the
string. Return a list with the names of the files in the directory
including names of subdirectories, search for a file in a set of
paths, return the current directory, etc. but all of this works better
if it is made in the style of the host system.
> and ask the implementors to agree on them? AFAIK, this has not
> happened yet (and maybe this is something I should have done).
Hm... I don't know.
Mario.
Mario S. Mommer <········@yahoo.com> writes:
> Well, here is how i think it would be better.
>
> * Less components or no components at all: just strings.
So rather than making it easy to refer ``the directory that this file
is in'', or ``the compiled version of this file'', you have to rely on
various ad-hoc string manipulation.
> If some program needs versions (for instance), it should implement
> that itself.
Even on operating systems that supply versions already?
> * Use native tongue.
Besides being non-portable, what do you do when you are referring to a
file that `lives' on a machine with a different OS? Why should the
user have to know the kind of OS that is hosting the file?
> What's the fuzz with the ";" char? And why do
> some lisp complain that "/home/mommer/data/whatever.dat" is a silly
> unix pathname? (huh?)
'cause some Lisp people don't use Unix computers. Do you want them to
use the `native' tongue or not?
> Anything else would just work:
Oh yeah. Bob's your uncle.
> * The need for configuration-dependant pathnames can be solved by
> using standard globals, which could be set by hand or by consulting
> the host system.
They could be set as ENVIRONMENT variables. Then we could run a
little Perl script to query the configuration.....
Exactly what `standard globals' are you talking about? (And if you're
volunteering to set them by hand, please do. I'm over at
Northeastern....)
> * If you need "my-proggy.lisp" relative to
> "/magnus/faustus/galacticus/" just use CONCATENATE.
File not found "/magnus/faustus/galacticusmy-proggy.lisp"
oops I meant /magnus/faustus/galacticus//my-proggy.lisp
No wait, not "/my-proggy.lisp", that's in the root dir.
How could I use concatenate to mean `up two directories'?
Oh, wait. Some people have Amiga's where leading slashes mean
relative directory and no slash means absolute.
Can we do it like Java does? In Java, if you include the trailing
slash on a pathname, you won't see any files when you list the
directory. Except, of course, if it is the root directory. Then you
*must* include the trailing slash.
> * Wildcards should work like in the underlying system. Better yet:
> they should just refer to the underlying system, because it knows
> best (by definition) how to resolve these things.
That would definitely make the name `wild' much more fitting.
> What functionality would be missing? Yes, the utilities everybody
> needs:
Ah, who needs those.
Joe Marshall <···@ccs.neu.edu> writes:
>> * Less components or no components at all: just strings.
>
> So rather than making it easy to refer ``the directory that this file
> is in'', or ``the compiled version of this file'', you have to rely on
> various ad-hoc string manipulation.
The problem is that the "easy" version plain doesn't work. It assumes
some semantics that don't exist (like that a filename can be
meaningfully split in a "name" and a "type" part), while supporting
others that are irrelevant (like version numbers).
I see that it would be fine to have a structured way to deal with
filenames, but it should not be just /any/ structured way, but one
that works in practice. CL pathnames handle some of the problems,
don't address others at all, and cause some new of their own. The idea
is right, but the implementation needs to be improved.
>> If some program needs versions (for instance), it should implement
>> that itself.
>
> Even on operating systems that supply versions already?
Then your program should better know about it, because the semantics
are likely different enough to do things differently. (You don't
depend on :if-exists :new-version to not kill your existing files
either, do you?)
Why not optimize for the common case? There are only two filename
syntaxes left, as long as most people are concerned, and both don't
support versions. I think the "Easy things should be easy, hard things
should be possible" mantra has something to it.
>> * Use native tongue.
>
> Besides being non-portable, what do you do when you are referring to a
> file that `lives' on a machine with a different OS? Why should the
> user have to know the kind of OS that is hosting the file?
How do CL Pathnames make it possible to refer to access such files?
When you want a file from another Computer, you either use some
network protocol, which come with their own ways of addressing (oh,
but you cannot use networking in a portable Common Lisp program. I
guess that is a feature, too), or you tell your operating system to
care about this, as with NFS, in which case there is no problem.
I for one like being able to manipulate pathnames in a structured
way. I don't like CL pathnames however, they always seem to cause at
least as much trouble as they supposedly take away.
I mean, come on, I can port my Lisp programs to a VAX without too much
hassle, but I cannot delete a file. There is something wrong here.
Regards
Henrik
Henrik Motakef <··············@web.de> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
> >> * Less components or no components at all: just strings.
> >
> > So rather than making it easy to refer ``the directory that this file
> > is in'', or ``the compiled version of this file'', you have to rely on
> > various ad-hoc string manipulation.
>
> The problem is that the "easy" version plain doesn't work.
This is news to me. It certainly *seems* to work.
Supposing foo is #P"/home/jrm/file.lisp"
(make-pathname :name nil :type nil :version nil :defaults foo)
really looks as if it gives me the directory only.
And (make-pathname :type "fasl" :defaults foo)
sure looks like it would refer to a fasl file.
> It assumes some semantics that don't exist (like that a filename can
> be meaningfully split in a "name" and a "type" part),
What does your mimecap file look like?
> while supporting others that are irrelevant (like version numbers).
I don't find version numbers to be irrelevant.
> I see that it would be fine to have a structured way to deal with
> filenames, but it should not be just /any/ structured way, but one
> that works in practice. CL pathnames handle some of the problems,
> don't address others at all, and cause some new of their own. The idea
> is right, but the implementation needs to be improved.
I agree with this. The problem is that the CL pathname system is a
half-assed imitation of the Genera system. They should have taken the
whole of it or none of it.
> Why not optimize for the common case? There are only two filename
> syntaxes left, as long as most people are concerned,
Let's see....
there's Unix style: /home/jrm/foo.bar
URL style: ftp://some.host.com/foo.http
DOS style: C:\Documents and Settings\jrm\foo.lsp
UNC style: \\Server\user shares\jrm\foo.lsp
Got a CD drive? FOOBAR.LSP;1
> and both don't support versions.
So they are broken. So we should break CL as well? I believe that
some people have suggested that CL versions should be interpreted much
as Emacs versions are on Unix.
Under Windows, it is common for utilities to version files by
appending a version number in square brackets: foo[2].lisp
Perhaps this convention should be followed. (By the way, windows has
this notion of multiple data streams per file. This could also be
used to version, but no one seems to do it.)
> I think the "Easy things should be easy, hard things
> should be possible" mantra has something to it.
Hard things should be easy, too.
> >> * Use native tongue.
> >
> > Besides being non-portable, what do you do when you are referring to a
> > file that `lives' on a machine with a different OS? Why should the
> > user have to know the kind of OS that is hosting the file?
>
> How do CL Pathnames make it possible to refer to access such files?
They have a host component. Note that I said `refer', not `access'.
The access part comes later. I want to be able to unambiguously NAME
the object (or potential object).
> I for one like being able to manipulate pathnames in a structured
> way. I don't like CL pathnames however, they always seem to cause at
> least as much trouble as they supposedly take away.
>
> I mean, come on, I can port my Lisp programs to a VAX without too much
> hassle, but I cannot delete a file. There is something wrong here.
I agree that CL pathnames are impoverished, but the idea of tossing
them out in favor of STRINGS is absurd.
Joe Marshall <···@ccs.neu.edu> writes:
>> It assumes some semantics that don't exist (like that a filename can
>> be meaningfully split in a "name" and a "type" part),
> What does your mimecap file look like?
I don't care, wise people use file(1). ;-)
>> while supporting others that are irrelevant (like version numbers).
> I don't find version numbers to be irrelevant.
Really? I would love to have them, yet I cannot assume a versioning
file system to be available anyways. So the presence of a version part
in CL pathnames doesn't buy me anything, it is just something I have to
care about without actually being useful.
>> I see that it would be fine to have a structured way to deal with
>> filenames, but it should not be just /any/ structured way, but one
>> that works in practice. CL pathnames handle some of the problems,
>> don't address others at all, and cause some new of their own. The idea
>> is right, but the implementation needs to be improved.
> I agree with this. The problem is that the CL pathname system is a
> half-assed imitation of the Genera system. They should have taken the
> whole of it or none of it.
I heard this before. Is there any document on the web where I can
learn more about the Genera system? What parts are missing in the ANSI
spec?
>> Why not optimize for the common case? There are only two filename
>> syntaxes left, as long as most people are concerned,
>
> Let's see....
> there's Unix style: /home/jrm/foo.bar
> URL style: ftp://some.host.com/foo.http
> DOS style: C:\Documents and Settings\jrm\foo.lsp
> UNC style: \\Server\user shares\jrm\foo.lsp
When I think about pathnames, I think about addressing local files,
not network recources. That would rule out URLs and UNC pathes, and,
to a lesser degree, UNC paths (that I admit to have forgotten in my
previous posting). I think the distinction is important, but I can see
why others think otherwise. So let's say 2.5 ;-)
> Got a CD drive? FOOBAR.LSP;1
Never had to deal with that notation. I guess this is ISO9660, without
Rockridge or Joliet? What does the ;1 mean?
>> and both don't support versions.
> So they are broken. So we should break CL as well?
Yes, we should. I could argue that systems that don't offer orthagonal
persistence are broken, should we ditch all those useless "file" stuff
altogether?
And, after all, just because you have to deal with the version
component all the time doesn't give you a filesystem that supports
them. You get the worst of both worlds.
>> I think the "Easy things should be easy, hard things
>> should be possible" mantra has something to it.
> Hard things should be easy, too.
Ideally, yes. And that's how it usually is in Common Lisp. But for the
cases where it isn't, I'd say start with making easy things easy.
> I agree that CL pathnames are impoverished, but the idea of tossing
> them out in favor of STRINGS is absurd.
It wouldn't be my favourite solution either. However, I think that
pathnames are something that needs to be fixed. Unfortunatly I cannot
see any way how they /can/ be fixed, or any of the other shortcomings
of ANSI Common Lisp, for that matter. The ANSI standard is what we
have, and there isn't going to be a new version any time
soon. Incompatible changes are generally a bad idea as well.
And that sucks big time, IMNSHO.
Regards
Henrik
On Fri, May 02, 2003 at 12:10:49AM +0200, Henrik Motakef wrote:
> Joe Marshall <···@ccs.neu.edu> writes:
>
> >> It assumes some semantics that don't exist (like that a filename can
> >> be meaningfully split in a "name" and a "type" part),
> > What does your mimecap file look like?
>
> I don't care, wise people use file(1). ;-)
Ah, this brings to mind Chapter 8 in the Unix Hater's Handbook, where the joys
of the file(1) command are explored along with shell programming in general.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> Ah, this brings to mind Chapter 8 in the Unix Hater's Handbook...
i'm curious why that pulp piece never got republished. surely, there
must be so much more material in the current linux/solaris/*bsd world
to hate. maybe they are justly worried about a foreword by linus. he
is even milder mannered than dennis... :-]
oz
---
bang go the blobs. -- ponder stibbons
After takin a swig o' Arrakan spice grog, ozan s yigit <··@blue.cs.yorku.ca> belched out...:
> Matthew Danish <·······@andrew.cmu.edu> writes:
>
>> Ah, this brings to mind Chapter 8 in the Unix Hater's Handbook...
>
> i'm curious why that pulp piece never got republished. surely, there
> must be so much more material in the current linux/solaris/*bsd world
> to hate. maybe they are justly worried about a foreword by linus. he
> is even milder mannered than dennis... :-]
It is quite curious that UHH never got republished.
Probably because it would have required rework, and the group of
"authors" couldn't agree on an approach, which would fit nicely with
the book being a direct result of the group dynamic of the
invitation-only mailing list.
--
(concatenate 'string "cbbrowne" ·@cbbrowne.com")
http://cbbrowne.com/info/x.html
Canada, Mexico, and Australia form the Axis of Nations That Are
Actually Quite Nice But Secretly Have Nasty Thoughts About America
Christopher Browne <········@acm.org> writes:
> After takin a swig o' Arrakan spice grog, ozan s yigit <··@blue.cs.yorku.ca> belched out...:
> > Matthew Danish <·······@andrew.cmu.edu> writes:
> >
> >> Ah, this brings to mind Chapter 8 in the Unix Hater's Handbook...
> >
> > i'm curious why that pulp piece never got republished. surely, there
> > must be so much more material in the current linux/solaris/*bsd world
> > to hate. maybe they are justly worried about a foreword by linus. he
> > is even milder mannered than dennis... :-]
>
> It is quite curious that UHH never got republished.
>
> Probably because it would have required rework, and the group of
> "authors" couldn't agree on an approach, which would fit nicely with
> the book being a direct result of the group dynamic of the
> invitation-only mailing list.
It should not only be reworked, but rewritten, because the new kid on
the block answers to the name of windows.
Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
Oops! Andreas Eder <············@t-online.de> was seen spray-painting on a wall:
> Christopher Browne <········@acm.org> writes:
>
>> After takin a swig o' Arrakan spice grog, ozan s yigit <··@blue.cs.yorku.ca> belched out...:
>> > Matthew Danish <·······@andrew.cmu.edu> writes:
>> >
>> >> Ah, this brings to mind Chapter 8 in the Unix Hater's Handbook...
>> >
>> > i'm curious why that pulp piece never got republished. surely, there
>> > must be so much more material in the current linux/solaris/*bsd world
>> > to hate. maybe they are justly worried about a foreword by linus. he
>> > is even milder mannered than dennis... :-]
>>
>> It is quite curious that UHH never got republished.
>>
>> Probably because it would have required rework, and the group of
>> "authors" couldn't agree on an approach, which would fit nicely with
>> the book being a direct result of the group dynamic of the
>> invitation-only mailing list.
>
> It should not only be reworked, but rewritten, because the new kid on
> the block answers to the name of windows.
.. Not that this would be likely to lead to a comparable sort of
group dynamic (note that I keep harping on "group dynamic"; that _is_
important...), from several perspectives:
1. There's the "cheap shot;" various of the UHH folk are /at/
Microsoft, and thus precluded from pouring similar vitrol on
what is their own product;
2. The history of Windows is much more strongly tied to commercial
"push."
The place where the most disgust is expressed, vis-a-vis Unix, is
in the fact that students come to "love" it despite there being
every reason, in the UHH observer's perspective, to hate it.
In contrast, the popularity of Windows cannot be blamed on
"foolish students sucked into a black hole of pain;" the clear
ration(ale) of dollars and cents is the clear cause for its
popularity.
3. The UHH problems with Unix are regarded as being fundamentally
technical; it is manifestly clear that the /big/ problems with
Windows are essentially nontechnical in nature, stemming from
change being driven by the notion "What Can We Sell Them Today?"
4. The assorted perspectives that led to people being critical of
Unix came from there actually *being* different perspectives
from which to look.
The UHH folk were assortedly familiar with actual alternatives,
like NeWS, DPS, NeXTStep, VMS, TOPS-10, TOPS-20, TENEX, TWENEX,
Symbolics, ITS, possibly Multics, GCOS, and other such systems
that are demonstrably genuinely different from each other.
In contrast, today, there are small "islands" of MVS and VMS here
and there, but to anyone coming into computing recently, the only
systems with any "vital" activity/change going on are derivatives
of Unix and derivatives of Windows NT.
The recent "pathname" discussion fits /exactly/ with this; while
in the past, there were other file naming conventions around,
today, I don't think it is _way_ unfair to say that only "old
curmudgeons pining for the old days" are imagining other schemes.
If that offends you, you're probably an "old curmudgeon;" I
seriously doubt many kids are coming in worried about the fact
that filesystems don't offer versioning.
The "old curmudgeons" might well be _right_, but that's
irrelevant to the matter. The point is that the shiny new
graduates of CS schools and, more importantly, the plausible
writers of the "WHH" (Windows Haters Handbook) are likely to be
in the newer generation that haven't memory of there being any
third alternative between Unix and Windows.
--
output = ("cbbrowne" ·@ntlug.org")
http://cbbrowne.com/info/unixhaters.html
"war is an inappropriate analogy; ``flame war'' is a misnomer.
in any usenet exchange, the only casualty is time.
there are better uses for regret."
--thi <···@netcom.com>
* Christopher Browne wrote:
> The recent "pathname" discussion fits /exactly/ with this; while
> in the past, there were other file naming conventions around,
> today, I don't think it is _way_ unfair to say that only "old
> curmudgeons pining for the old days" are imagining other schemes.
> If that offends you, you're probably an "old curmudgeon;" I
> seriously doubt many kids are coming in worried about the fact
> that filesystems don't offer versioning.
Maybe kids aren't but I bet serious vendors are. The Unix file system
is growing all sorts of interesting things on some platforms - access
control lists, user-defined metadata and so on. I wouldn't be at
*all* surprised if versioning comes in, especially versioning with
transactional support and unwinding (`label every current version on
the file system atomically', `unwind the filesystem state to a
label'.)
--tim
Tim Bradshaw <···@cley.com> writes:
> * Christopher Browne wrote:
>> The recent "pathname" discussion fits /exactly/ with this; while
>> in the past, there were other file naming conventions around,
>> today, I don't think it is _way_ unfair to say that only "old
>> curmudgeons pining for the old days" are imagining other schemes.
>> If that offends you, you're probably an "old curmudgeon;" I
>> seriously doubt many kids are coming in worried about the fact
>> that filesystems don't offer versioning.
>
> Maybe kids aren't but I bet serious vendors are. The Unix file system
> is growing all sorts of interesting things on some platforms - access
> control lists, user-defined metadata and so on. I wouldn't be at
> *all* surprised if versioning comes in, especially versioning with
> transactional support and unwinding (`label every current version on
> the file system atomically', `unwind the filesystem state to a
> label'.)
doesn't ClearCase sort of count? ("sort of" is because it can only
count VERY SLOWLY).
--
All ITS machines now have hardware for a new machine instruction --
BAH
Branch And Hang.
Please update your programs.
Michael Livshin <······@cmm.kakpryg.net> writes:
> Tim Bradshaw <···@cley.com> writes:
>
> > * Christopher Browne wrote:
> >> The recent "pathname" discussion fits /exactly/ with this; while
> >> in the past, there were other file naming conventions around,
> >> today, I don't think it is _way_ unfair to say that only "old
> >> curmudgeons pining for the old days" are imagining other schemes.
> >> If that offends you, you're probably an "old curmudgeon;" I
> >> seriously doubt many kids are coming in worried about the fact
> >> that filesystems don't offer versioning.
> >
> > Maybe kids aren't but I bet serious vendors are. The Unix file system
> > is growing all sorts of interesting things on some platforms - access
> > control lists, user-defined metadata and so on. I wouldn't be at
> > *all* surprised if versioning comes in, especially versioning with
> > transactional support and unwinding (`label every current version on
> > the file system atomically', `unwind the filesystem state to a
> > label'.)
>
> doesn't ClearCase sort of count? ("sort of" is because it can only
> count VERY SLOWLY).
In between being a total pain in the neck, it may perhaps. I'd rather
have some kind of interface between CVS and pathname versioning. I
think I remember somebody cooking up a Common Lisp front end to CVS,
but IIRC, it didn't extend itself into pathnames.
Gregm
Greg Menke wrote:
> Michael Livshin writes:
>
>
> >Tim Bradshaw writes:
> >
> >
> >>* Christopher Browne wrote:
> >>
> >>> The recent "pathname" discussion fits /exactly/ with this; while
> >>> in the past, there were other file naming conventions around,
> >>> today, I don't think it is _way_ unfair to say that only "old
> >>> curmudgeons pining for the old days" are imagining other schemes.
> >>> If that offends you, you're probably an "old curmudgeon;" I
> >>> seriously doubt many kids are coming in worried about the fact
> >>> that filesystems don't offer versioning.
> >>
> >>Maybe kids aren't but I bet serious vendors are. The Unix file system
> >>is growing all sorts of interesting things on some platforms - access
> >>control lists, user-defined metadata and so on. I wouldn't be at
> >>*all* surprised if versioning comes in, especially versioning with
> >>transactional support and unwinding (`label every current version on
> >>the file system atomically', `unwind the filesystem state to a
> >>label'.)
> >
> >doesn't ClearCase sort of count? ("sort of" is because it can only
> >count VERY SLOWLY).
>
>
> In between being a total pain in the neck, it may perhaps. I'd rather
> have some kind of interface between CVS and pathname versioning. I
> think I remember somebody cooking up a Common Lisp front end to CVS,
> but IIRC, it didn't extend itself into pathnames.
I am not so sure you want to conflate file versions with CVS (besides,
file versions are kinda fluffy under UNIX).
I'd rather see a nice reimplementation of PRCS. Any taker?
Cheers
--
Marco
From: Steven E. Harris
Subject: Re: pathname replacements / alternatives
Date:
Message-ID: <q67znm1xoc8.fsf@raytheon.com>
Greg Menke <··········@toadmail.com> writes:
> I think I remember somebody cooking up a Common Lisp front end to
> CVS, but IIRC, it didn't extend itself into pathnames.
Maybe you're thinking of Meta-CVS�.
Footnotes:
� http://users.footprints.net/~kaz/mcvs.html
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
* Michael Livshin wrote:
> doesn't ClearCase sort of count? ("sort of" is because it can only
> count VERY SLOWLY).
No, not really, because it doesn't version control everything you do,
only things you ask it do catch.
Things like the filesystem snapshotting stuff that solaris has are
closer to what I mean (but I expect something much more comprehensive)
--tim
"Henrik Motakef" <··············@web.de> wrote in message
···················@interim.henrik-motakef.de...
> > I agree that CL pathnames are impoverished, but the idea of tossing
> > them out in favor of STRINGS is absurd.
>
> It wouldn't be my favourite solution either. However, I think that
> pathnames are something that needs to be fixed. Unfortunatly I cannot
> see any way how they /can/ be fixed, or any of the other shortcomings
> of ANSI Common Lisp, for that matter. The ANSI standard is what we
> have, and there isn't going to be a new version any time
> soon. Incompatible changes are generally a bad idea as well.
Is this such a big problem in peoples code? Does anyone have
programs with thousands of filenames, all with merging and
translations such that hand editing each slightly disparate
case is an insurmountable problem? It sounds highly
unlikely and writing a new pathname system because of
small aesthetic issues does not seem wise. The limited number
of programs I have written all use pathnames and logical
pathnames and I do not see any possible platform specific
problems (just a few changes to root directory paths).
Wade
* Henrik Motakef wrote:
> When I think about pathnames, I think about addressing local files,
> not network recources. That would rule out URLs and UNC pathes, and,
> to a lesser degree, UNC paths (that I admit to have forgotten in my
> previous posting). I think the distinction is important, but I can see
> why others think otherwise. So let's say 2.5 ;-)
The network is the computer, you know. It's the 1980s already.
> Never had to deal with that notation. I guess this is ISO9660, without
> Rockridge or Joliet? What does the ;1 mean?
Could it be ... a version number? No, obviously not, no one uses
filesystems with version numbers any more, oh no, of course it's not
that. Definitely, absolutely not.
> Ideally, yes. And that's how it usually is in Common Lisp. But for the
> cases where it isn't, I'd say start with making easy things easy.
Like pathnames are at present, if you have a functioning brain.
Unfortunately, most Lisp users turn out to not to have functioning
brains. Sad, but self-evidently true I think.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Henrik Motakef wrote:
>> When I think about pathnames, I think about addressing local files,
>> not network recources. That would rule out URLs and UNC pathes, and,
>> to a lesser degree, UNC paths (that I admit to have forgotten in my
>> previous posting). I think the distinction is important, but I can see
>> why others think otherwise. So let's say 2.5 ;-)
>
> The network is the computer, you know. It's the 1980s already.
Yes, my mousepad used to say that. Turned out not to be the best
strategy once the 80s were over (well, let's be honest, it were the
90s. The decade where Lisp stopped to evolve.) It is now more humble
and simply tries to make the net work.
Seriously, I want to distinguish accessing a local file (where, for
example, I would expect file locking to work (except that CL doesn't
give me a way to use that)) from accessing a network resource (which
CL doesn't allow me at all). If there is a generalization, it should
be the other way around, something that works on arbitrary URLs,
including the file:// scheme, with the more lax network semantics.
>> Never had to deal with that notation. I guess this is ISO9660, without
>> Rockridge or Joliet? What does the ;1 mean?
> Could it be ... a version number? No, obviously not, no one uses
> filesystems with version numbers any more, oh no, of course it's not
> that. Definitely, absolutely not.
When was the last time you used this version number? Did your Lisp
system help much with it?
>> Ideally, yes. And that's how it usually is in Common Lisp. But for the
>> cases where it isn't, I'd say start with making easy things easy.
> Like pathnames are at present, if you have a functioning brain.
And if your problems (and your file systems) happen to be those
anticipated by the X3J13 working group in a time when it seemed to be
a good idea to use the DEC TOPS-20 filesystem for examples.
> Unfortunately, most Lisp users turn out to not to have functioning
> brains. Sad, but self-evidently true I think.
There is some truth in this, yes.
Regards
Henrik
* Henrik Motakef wrote:
> And if your problems (and your file systems) happen to be those
> anticipated by the X3J13 working group in a time when it seemed to be
> a good idea to use the DEC TOPS-20 filesystem for examples.
Damn. All those tens of thousands of lines of code I've written in
the last couple of years using the CL pathname system in hairy ways,
all of which runs on Unix and 2 kinds of Windows filesystems with no
changes must be imaginary then. I should of used strings like what
the smart people do.
Henrik Motakef <··············@web.de> writes:
> Tim Bradshaw <···@cley.com> writes:
>
> > * Henrik Motakef wrote:
> >> When I think about pathnames, I think about addressing local files,
> >> not network recources. That would rule out URLs and UNC pathes, and,
> >> to a lesser degree, UNC paths (that I admit to have forgotten in my
> >> previous posting). I think the distinction is important, but I can see
> >> why others think otherwise. So let's say 2.5 ;-)
> >
> > The network is the computer, you know. It's the 1980s already.
>
> Yes, my mousepad used to say that. Turned out not to be the best
> strategy once the 80s were over (well, let's be honest, it were the
> 90s. The decade where Lisp stopped to evolve.) It is now more humble
> and simply tries to make the net work.
>
> Seriously, I want to distinguish accessing a local file (where, for
> example, I would expect file locking to work (except that CL doesn't
> give me a way to use that)) from accessing a network resource (which
> CL doesn't allow me at all). If there is a generalization, it should
> be the other way around, something that works on arbitrary URLs,
> including the file:// scheme, with the more lax network semantics.
>
> >> Never had to deal with that notation. I guess this is ISO9660, without
> >> Rockridge or Joliet? What does the ;1 mean?
> > Could it be ... a version number? No, obviously not, no one uses
> > filesystems with version numbers any more, oh no, of course it's not
> > that. Definitely, absolutely not.
>
> When was the last time you used this version number? Did your Lisp
> system help much with it?
Last time I typed C-x C-s, that is about 10 seconds ago.
The philosophy of unix is to be minimal and have the applications and
the libraries implement additional functionalities like file
versionning. Emacs does this, appending a (format ".~%d~" version)
extension to the file names.
> [...]
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
"Henrik Motakef" <··············@web.de> wrote in message
···················@interim.henrik-motakef.de...
> > I agree that CL pathnames are impoverished, but the idea of tossing
> > them out in favor of STRINGS is absurd.
>
> It wouldn't be my favourite solution either. However, I think that
> pathnames are something that needs to be fixed. Unfortunatly I cannot
> see any way how they /can/ be fixed, or any of the other shortcomings
> of ANSI Common Lisp, for that matter. The ANSI standard is what we
> have, and there isn't going to be a new version any time
> soon. Incompatible changes are generally a bad idea as well.
>
> And that sucks big time, IMNSHO.
(Mind Henrick, this isn't directed specifically at you, but rather a seeming
communal attitude)
Doesn't this just completely baffle anyone else? Here we have the most
dynamic, most complete, most expressive language environement on the planet,
the one environment that can truly change itself essentially from the top
down, and it "can't be fixed". It's "stuck", "moribound", "cast in
concrete".
Certainly some aspects (deep system issues like VM interaction and native
threads) have hooks deep into the implementation. But most of the other nit
picky frustrations that folks have seem to me can be EASILY fixed.
Have a problem with how pathnames are working for you? Change it! Not only
can you change it just for your programs, you can change it for everything
in the system if you want. You have the capability. Tweak it to how you want
it to work.
"But if I change it, it won't be ANSI compliant!" But if you use it
according to ANSI, it won't work for you either (because they're "broken"),
so YOU are stuck. You LET yourself be stuck. Don't do that. Break free! FIX
IT!
We don't even need the source code to do this. We can abstract pretty much
anything. Use the CL-HENRIK package instead of CL-USER.
The standard has this enormous weight upon people, it had the vast burden of
historic momentum. It's to the point that if weren't for folks like Kent and
Barry, we'd be running into situations where we say "Why are we doing it
this way?" "We've always done it this way." "How come?" "..?..Dunno!". But
that momentum seems to be backwards, not forward. It's dragging, not
pushing.
You can write code to the standard. But that doesn't mean you have to write
code IN the standard. Make your tweaks, fixes, blemish removers, whatever on
TOP of the standard, and then use THAT.
I understand the concerns. Look at John's IF* (I think) macro that was
welcomed to such high praise in the community. Don't like it? Don't use it.
Don't like to see it? Don't use Johns code. I'll bet that macro is all over
the place inside the Allegro code base, and we never even see it.
How can that be? They're writing an ANSI CL system and .. and... OH MY GOD!
They're not using pure ANSI CL to do it!! Is that allowed? Are we really
allowed to move the Art Of Lisp forward for our own productivity?? Or must
we stick to only what is in The Book, The Spec, The Bible?
The standard is a foundation folks, not the end of the line.
I agree with others that users need to be able to get to the core ANSI
capability within the system. I know folks like Franz are extending and
pushing out past the fringes of the standard, and make non-standard behavior
default in the basic system, thus making "default" code on their system
"non-standard". It would be nice if this were more prevalent to users who
may be interested in writing upon the ANSI foundation, rather than the Franz
foundation.
But kudos to Franz for at least advancing the art. Trying new things and
using them themselves. Until someone else starts pushing as well, perhaps in
different direction, then Franz gets to "lead". But let them float their
balloons. If they write interesting things, then the more flexible
implementations out their will start to adopt Franz's ideas. Franz released
their hierarchical package system. This is the classic example that the
system can be extended and fixed "in place".
Lisp making Lisp. What a concept.
This is not so much a technical problem, but a perception and community
problem. We LET this happen, it's not forced upon us.
Regards,
Will Hartung
(·····@msoft.com)
From: Tim Bradshaw
Subject: Re: ACL "can't be fixed" (was pathname replacements / alternatives)
Date:
Message-ID: <ey3bryl58x9.fsf@cley.com>
* Will Hartung wrote:
> Doesn't this just completely baffle anyone else? Here we have the
> most dynamic, most complete, most expressive language environement
> on the planet, the one environment that can truly change itself
> essentially from the top down, and it "can't be fixed". It's
> "stuck", "moribound", "cast in concrete".
I think it would baffle me, because, like other people who write Lisp,
I write layers on top of the underlying system all the time (some of
them with implementation-dependent substrates), and it doesn't bother
me at all.
However I'm - possibly incorrectly - not baffled, because I think that
for a lot of the people who complain about how things `don't work and
can't be fixed without reopening the standardisation process and
spending millions and millions of dollars', the hidden - and perhaps
subconscious - agenda is that they don't *want* it to be fixed,
because, if it was, then they'd have one less excuse not do do any
work.
--tim
Joe Marshall <···@ccs.neu.edu> writes:
> I agree with this. The problem is that the CL pathname system is a
> half-assed imitation of the Genera system. They should have taken
> the whole of it or none of it.
I've heard this before; I'm interested in hearing what features the
Genera system had that, had they been included in the CL pathname
system, would make life better today.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
> > I agree with this. The problem is that the CL pathname system is a
> > half-assed imitation of the Genera system. They should have taken
> > the whole of it or none of it.
>
> I've heard this before; I'm interested in hearing what features the
> Genera system had that, had they been included in the CL pathname
> system, would make life better today.
Here are a few that come to mind just on a few minutes thought. I'm out of
town so can't fire up my LispM to check if there are other obvious things
I'm forgetting, but I'm sure there are...
FS:DIRECTORY-LIST returned a list of files and their attributes in
plist format. Pathnames accepted messages (generic functions) to allow
you to change some of these properties. It was possible to poll the
system to find out what set of operations are settable and what not.
It had operations to create directories.
It had a theory of how to represent directories, and messages (now
called generic functions) that were essentially (slightly different
names) converting pathname-as-directory and directory-as-pathname.
It defined that pathname parsing gave you interned objects, so you could
compare them with EQ.
It defined where :UNSPECIFIC was needed.
It defined how NAMESTRING worked to a greater degree.
It offered a string-for-host that allowed you to get a string for the host
without making the bogus assumption that this is what NAMESTRING does.
(If you read the spec for NAMESTRING, you'll realize that if it ever does
this, it's only by accident. It mostly works to return the NAMESTRING
when you have only one host's file system attached to you, but on the LispM,
which was a real networked file system, the namestring _always_ started
with a hostname and then a colon. So, for example,
"acme-unix.com:/etc/aliases" not "/etc/aliases"
"acme-mac.com:main:foo:bar" not "main:foo:bar"
It offered something called canonical-type that was an abstraction you could
use instead of pathname-type to get :TEXT, :LISP, etc. in the face of
text files being sometimes named .txt and sometimes .text, in the face of
lisp files being sometimes .lisp and sometimes .lsp and sometimes .cl.
It offered the ability to attach properties to canonical types saying whether
they were ASCII or binary for FTP purposes, and if binary what their byte
size was.
(It also had a complex system, unrelated to pathnames, for allowing
you to specify the possible routes to a network service, including
your preferences for which were to be tried first in case multiple
ones were possible. Using this, you could say that there was both an
FTP and NFS path to a certain file system and say which you preferred
to use. The operation find-path-to-service-on-host was central to
this. This "path" was not a pathname, but a triple that included, if
I recall, a service to be accomplished (like mail delivery), a
protocol to use (like SMTP), and a medium to do this over (like TCP).)
It offered the ability of logical pathnames to do reverse translation, so
that if you had opened a file and then truenamed it, you had half a chance
of being able to tell the person in abstract terms what file he had opened.
e.g., opening "FOO;BAR.LISP" might find "B:>kmp>foo>bar.lisp.37" but you
might want to backtranslate that to "FOO;BAR.LISP.37" to say to the user
what file had been opened.
It offered a representation of file host objects (not the same as network
hosts). It had a system for representing information about file hosts
so that you could tell it that a given file host was a unix host and that
another file host was a mac host, so it would parse the names correctly
locally without having to ask the remote system.
It had a bunch of file errors spec'd out, a lot of which were not included
in CL because they requierd multiple inheritance and we had a rule at
approval time that the condition system must not rely on CLOS nor vice
versa so that either could be removed without the other in case the public
did not like one of them. Doing file errors right requires understanding
that a network host can have network errors, while other hosts won't have
network errors. It requires understanding that some kinds of errors are
temporary errors (like out of disk space) and others are permanent
(invalid filename). Without multiple inheritance, it's a mess to spec this
out right.
It had a bunch of useful restarts defined for common situations where the
file system would lose and you might need to do things like "expunge the
directory trying to make more space" (for file systems with soft delete)
or "try again" (for networked hosts that didn't respond) or "keep retrying"
(for a host that is believed down and should come back up at some point)
or "create directory" (for a missing directory, which it did NOT do for a
missing file--a distinction we really don't have in CL).
>> features the Genera system had that, had they been included in the
>> CL pathname system, would make life better today.
>
> It had operations to create directories.
CL has ENSURE-DIRECTORIES-EXIST, though. And a very clever piece of
design it is, too.
Also, partial pathnames could be constructed and manipulated portably,
as Genera didn't threaten to signal errors. I'm referring to 19.2.2.5
_Restrictions on Constructing Pathnames_ - obviously, only punctuation
is going to be a problem in practice, but theoretically, almost any
call to MAKE-PATHNAME can hit an undocumented implementation limit.
--
Pekka P. Pirinen
The LM was a wonderful peak of programmability, and will remain so as
long as enthusiasts can find enough low-sulfur coal to shovel into
those machines' boilers to keep them running... :-) - Steven M. Haflich
Henrik Motakef <··············@web.de> writes:
> Why not optimize for the common case? There are only two filename
> syntaxes left,
I saw a talk at MIT once by Isaac Asimov where he was poking fun at Science
Fiction's (including his own) treatment of time travel. About arriving in
the future, he said (I'm paraphasing slightly, though I did re-listen to a
tape of this recently, so probably have it about right): `FORTUNATELY, they
speak English. Thousands of years ago, people spoke ancient Egyptian but
thousands of years from now, everyone still speaks English.'
Does your remark mean you've never heard me say that the portability
that CL planned for is 4-dimensional--not just across platforms, but
across time? That is, what _does_ "two filename syntaxes left" mean?
Does this mean that computer science is a process of ferreting out
nonrightthinking ways of doing stuff until we arrive at the truth,
and that there are only two choices left undiscarded?
Does this mean there will never be new ways of thinking of things?
Does this mean that the Wrong Thing (whatever you subjectively assess that
to be) will never achieve dominance, and so "what is presently in existence"
is a good metric of what we should use?
Does this mean that once something has achieved market dominance, it will
never be deposed? (If so, this must surely be reassuring to IBM.)
Does it mean that everytime something wrong happens, we should just resign
ourselves to it, and every time something interesting is lost, we should
immediately rewrite our tools to forget any memory of it?
A long time ago, when there was mostly only ASCII and EBCDIC, would it
have been correct to conclude that "since there were only two coding
systems left", we could do without worrying about "~" and other diacritical
marks because clearly no one cared seriously about those non-English
languages?
Does this mean that something that is a good idea never dies out and has
to be reinvented?
Is this meant as an assertion that there are no extant versioned file systems,
including the sometimes-convention of GNU programs to use .~3~ to denote file
versioning even on one of the most popular file systems available today?
Or is it only a claim made by someone who doesn't care over the
objection of people who might that CL should go out of its way to not
work on file systems not used by you personally. (Note that CL _also_
tries to work on non IEEE-compliant floating point hardware, even
though such is probably not very common. We didn't see any point to
require what cannot be required, the only effect of which would be
that some systems can't be properly supported.)
Is this an observation that the Common Lisp pathname system can't work
properly on file systems that have no versions? (Because it works fine for
me.)
Or is it even slightly conceivable that the future might be more complex
than today? That it might have version numbers, for example?
The following remark from an old post of mine bears repeating here, even
at the risk of seeming slightly out of context:
One of the hardest things that came of the CL experience for me and
the other people I worked with was this understanding of "another's
pain". I have often said (and you are the most recent example) that
the very hardest thing of all in standards work is to take two
people, one of whom says "I need x" and the other of whom says "I
don't need x, but it would cost me nothing to have it" and to get the
second person to agree to tolerate x just for the sake of the loss of
the other person's pain. An example of this was FORCE-OUTPUT in the
I/O domain. Some implementations have no buffered I/O and so didn't
want things like this, which would have been simple no-ops in their
language. It offended them to see it, but it was essential to
someone else. I have learned to have considerable disdain for people
who can't or won't get inside the head of another and really try to
understand the world from their point of view, and who instead insist
that because they have identified a particular point of view which
they think (without proof) works for them, that it must be a
habitable space for all.
Source: http://groups.google.com/groups?selm=sfwbsvvy7jw.fsf%40world.std.com
Kent M Pitman <······@world.std.com> writes:
> Henrik Motakef <··············@web.de> writes:
>
>
> The following remark from an old post of mine bears repeating here, even
> at the risk of seeming slightly out of context:
>
> One of the hardest things that came of the CL experience for me and
> the other people I worked with was this understanding of "another's
> pain". I have often said (and you are the most recent example) that
> the very hardest thing of all in standards work is to take two
> people, one of whom says "I need x" and the other of whom says "I
> don't need x, but it would cost me nothing to have it" and to get the
> second person to agree to tolerate x just for the sake of the loss of
> the other person's pain. An example of this was FORCE-OUTPUT in the
> I/O domain. Some implementations have no buffered I/O and so didn't
> want things like this, which would have been simple no-ops in their
> language. It offended them to see it, but it was essential to
> someone else. I have learned to have considerable disdain for people
> who can't or won't get inside the head of another and really try to
> understand the world from their point of view, and who instead insist
> that because they have identified a particular point of view which
> they think (without proof) works for them, that it must be a
> habitable space for all.
>
> Source: http://groups.google.com/groups?selm=sfwbsvvy7jw.fsf%40world.std.com
Thank you Kent! I recently attended a standards meeting and spent a
week one day waiting for the endless wrangling over this exact issue
to subside- and it wasn't even over some feature 'x', just over its
name.
Gregm
* Kent M Pitman wrote:
> Does this mean there will never be new ways of thinking of things?
Yes, there will never be any new ways of doing anything. The pathname
abstractions (or lack of them) that people adopted when designing an
OS for a machine where a few long pathnames could use several percent
of the total address space of the machine are the best possible ones.
Just the same way the language they designed to implement the OS for
that machine is the best possible one. Progress in computing is
finished.
--tim
Kent M Pitman wrote:
> Does your remark mean you've never heard me say that the portability
> that CL planned for is 4-dimensional--not just across platforms, but
> across time?
I will try to build a bridge between the different opinions posted in
this thread.
What I like about Common Lisp is that it usually accomodates both
small-scale and large-scale programs. I can start with an exploratory
programming style and use piecemeal growth if needed in order to
refactor my code into a "big" application.
So for example, if I don't need the full power of macros, I can just use
functions. If I don't need the full power of the loop macro, I can just
use do, dotimes and dolist. If I don't need the full power of CLOS, I
can just use defstruct. If I don't need the full power of hashtables and
arrays, I can just use lists. You get the idea.
So what if I don't need the full power of pathnames?
Pascal
P.S.: The answer might be to just use a subset. I just wanted to make
clear what the question is.
P.P.S.: BTW, there is a tutorial on pathnames at
http://www.lisp-p.org/htdocs/pathnames-0/
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> wrote:
+---------------
| So for example, if I don't need the full power of macros, I can just use
| functions. If I don't need the full power of the loop macro, I can just
| use do, dotimes and dolist. If I don't need the full power of CLOS, I
| can just use defstruct. If I don't need the full power of hashtables and
| arrays, I can just use lists. You get the idea.
|
| So what if I don't need the full power of pathnames?
+---------------
Just use namestrings (CLHS 19.1.1 "Namestrings as Filenames"), and
live with whatever portability restrictions that imposes on you.
Since OPEN accepts pathname designators, and pathname designators
include pathname namestrings, if you're sticking to one platform
then most of the time you won't ever notice the lack...
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pascal Costanza <········@web.de> writes:
> So what if I don't need the full power of pathnames?
Then use namestrings, like all other languages do.
> P.S.: The answer might be to just use a subset.
If you think namestrings are a subset of pathnames, that's possible.
Certainly, too, I know a lot of people who just ignore the version
component of pathnames, as if it didn't ever matter. Which may work
fine in their narrowly chosen target environment [even for various
large values of "narrow"].
Note that ignoring the version part of a string is harder than ignoring
the version part of a file. Thank goodness for structure. ;)
> I just wanted to make clear what the question is.
Always a laudable goal.
Pascal Costanza <········@web.de> writes:
> So what if I don't need the full power of pathnames?
I still think that it is not a matter of needing "full power", just of
groking what this is about (which isn't obvious when your lisp
complains that a perfectly legal file name is "silly"). That thing
(PATHNAMES) is, I reckon, a better Idea than it first seems, and folks
here have managed to convince me that strings are not a general and
good solution.
But still (talking about full power), how do I delete a file?
And it happens that I have other attributes for a file, too, that are
neither version nor type (nor date). What is the best way of dealing
with these? [1]
> P.P.S.: BTW, there is a tutorial on pathnames at
> http://www.lisp-p.org/htdocs/pathnames-0/
It is very interesting, indeed. Look at
http://www.lisp-p.org/htdocs/pathnames-0/node2.html
Mario.
---
[1] For the curious: I store some numerical data in fasl files, and they
are indexed by level, primal order, and dual order.
Mario S. Mommer <········@yahoo.com> writes:
>
> But still (talking about full power), how do I delete a file?
>
COMMON-LISP:DELETE-FILE, maybe?
It's in the HyperSpec, it's easy to find with apropos, and it's not at all
hard to guess if you're familiar with CL's naming conventions.
Gabe Garza
* Mario S Mommer wrote:
> I still think that it is not a matter of needing "full power", just of
> groking what this is about (which isn't obvious when your lisp
> complains that a perfectly legal file name is "silly"). That thing
> (PATHNAMES) is, I reckon, a better Idea than it first seems, and folks
> here have managed to convince me that strings are not a general and
> good solution.
Can you actually quote the system that complained at your pathname, in
such a way that the problem can be reproduced by someone other than
you? if you can, and if you haven't made a mistake this is likely an
implementation bug.
> But still (talking about full power), how do I delete a file?
You use the DELETE-FILE function. How did you think you would do
this?
> And it happens that I have other attributes for a file, too, that are
> neither version nor type (nor date). What is the best way of dealing
> with these? [1]
Make sure you use truenames, then store them in a hashtable under
EQUAL, typically. How would you do this if you used another
representation?
--tim
Tim Bradshaw <···@cley.com> writes:
> * Mario S Mommer wrote:
>
> > I still think that it is not a matter of needing "full power", just of
> > groking what this is about (which isn't obvious when your lisp
> > complains that a perfectly legal file name is "silly"). That thing
> > (PATHNAMES) is, I reckon, a better Idea than it first seems, and folks
> > here have managed to convince me that strings are not a general and
> > good solution.
>
> Can you actually quote the system that complained at your pathname, in
> such a way that the problem can be reproduced by someone other than
> you? if you can, and if you haven't made a mistake this is likely an
> implementation bug.
It's CMU Lisp. It's a style warning, somewhat in the mode of some of
the GCC warnings.
This comes from calling "make-pathname" with a string like
"/homes/gilham/stuff.lisp".
* (make-pathname :name "/homes/gilham/stuff.lisp")
Warning: Silly argument for a unix PATHNAME-NAME: "/homes/gilham/stuff.lisp"
#p"/homes/gilham/stuff.lisp"
*
Someone doing this is misunderstanding what make-pathname is supposed
to do.
--
Fred Gilham ······@csl.sri.com
The rage of dance and style that swept the country in the late '70s
crumbled from serious backlash as disco freaks seemed to finally wake
up and realize what they were wearing. -- Michael Okwu
* Fred Gilham wrote:
> Someone doing this is misunderstanding what make-pathname is supposed
> to do.
They certainly are! Indeed I think CMUCL should signal an error in
that case as anything with a slash in it is definitely not a legal
pathname component on Unix. It might depend on the pathname host I
guess.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Fred Gilham wrote:
>> Someone doing this is misunderstanding what make-pathname is supposed
>> to do.
>
> They certainly are! Indeed I think CMUCL should signal an error in
> that case as anything with a slash in it is definitely not a legal
> pathname component on Unix. It might depend on the pathname host I
> guess.
Yes, it might. And in fact, since this pathname object can later be
merged with another pathname object with a different host, I don't
think signalling an error is acceptable.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> Tim Bradshaw writes:
>
>
> >* Fred Gilham wrote:
> >
> >>Someone doing this is misunderstanding what make-pathname is supposed
> >>to do.
> >
> >They certainly are! Indeed I think CMUCL should signal an error in
> >that case as anything with a slash in it is definitely not a legal
> >pathname component on Unix. It might depend on the pathname host I
> >guess.
>
>
> Yes, it might. And in fact, since this pathname object can later be
> merged with another pathname object with a different host, I don't
> think signalling an error is acceptable.
On top of that, I believe the CLHS makes provisions for quoting the #\/
characters under UNIX.
Cheers
--
Marco Antoniotti
* Marco Antoniotti wrote:
> On top of that, I believe the CLHS makes provisions for quoting the
> #\/ characters under UNIX.
You can't do that. A forward slash is just not legal syntax for a
pathname component in UNIX: whether or not the Lisp supports it, Unix
doesn't.
--tim
Tim Bradshaw wrote:
> * Marco Antoniotti wrote:
>
>
> >On top of that, I believe the CLHS makes provisions for quoting the
> >#\/ characters under UNIX.
>
>
> You can't do that. A forward slash is just not legal syntax for a
> pathname component in UNIX: whether or not the Lisp supports it, Unix
> doesn't.
Yep. I guess you cannot do the trick appearing in the CLHS.
Cheers
--
Marco Antoniotti
* Christophe Rhodes wrote:
> Yes, it might. And in fact, since this pathname object can later be
> merged with another pathname object with a different host, I don't
> think signalling an error is acceptable.
I think it is, because the implementation knows whether it supports
(or could support) a pathname system in which this is legal. On the
other hand in the interests of portability it might not want to signal
anything (maybe this pathname isn't actually used in this
implementation...). In that case I'd rather it didn't warn either, I
think.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Christophe Rhodes wrote:
> > Yes, it might. And in fact, since this pathname object can later be
> > merged with another pathname object with a different host, I don't
> > think signalling an error is acceptable.
>
> I think it is, because the implementation knows whether it supports
> (or could support) a pathname system in which this is legal. On the
> other hand in the interests of portability it might not want to signal
> anything (maybe this pathname isn't actually used in this
> implementation...). In that case I'd rather it didn't warn either, I
> think.
In the context of Mac/unix compatibility, '/' and ':' are
automatically exchanged. If you write a file name with '/' on a Mac,
you get a ':' on unix and vice-versa. Such mapping can and should
occur between logical path names and actual file system path names.
Notably to be able to see and use all the files existing in the system
from the logical path name point of view.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> > * Mario S Mommer wrote:
> >
> > > I still think that it is not a matter of needing "full power", just of
> > > groking what this is about (which isn't obvious when your lisp
> > > complains that a perfectly legal file name is "silly"). That thing
> > > (PATHNAMES) is, I reckon, a better Idea than it first seems, and folks
> > > here have managed to convince me that strings are not a general and
> > > good solution.
>
> It's CMU Lisp. It's a style warning, somewhat in the mode of some of
> the GCC warnings.
>
> This comes from calling "make-pathname" with a string like
> "/homes/gilham/stuff.lisp".
>
> * (make-pathname :name "/homes/gilham/stuff.lisp")
> Warning: Silly argument for a unix PATHNAME-NAME: "/homes/gilham/stuff.lisp"
>
> #p"/homes/gilham/stuff.lisp"
> *
>
> Someone doing this is misunderstanding what make-pathname is supposed
> to do.
Right. With this example it is clear why the name is silly. Since it
took me a little bit of close reading to notice, I thought I would
amplify Fred's comments for others.
The complaint is not about the entire filename, but about using, as just
the NAME, not NAME + DIRECTORY, a string with directory separators in
it.
There are two potential solutions to this:
(1) (pathname "/homes/gilham/stuff.lisp")
(2) (make-pathname :directories '(:absolute "homes" "gilham")
:name "stuff"
:type "lisp")
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
Joe Marshall <···@ccs.neu.edu> writes:
> Oh, wait. Some people have Amiga's where leading slashes mean
> relative directory and no slash means absolute.
IIRC, it goes like this:
"foo" is in the current directory,
"/foo" is in the parent directory,
"//foo" is in the grandparent directory,
":foo" is in the root directory of the current filesystem, and
"bar:foo" is in the root directory of the device or disk "bar".
Mario S. Mommer wrote:
> Marco Antoniotti writes:
>
> >My point was that alternatives do not come easily.
>
>
> Ok.
>
>
> >Why don't you list a set of desiderata yopu want in the current
> >PATHNAME stuff
>
>
> Well, here is how i think it would be better.
>
> * Less components or no components at all: just strings.
I am sure that other people will answer to this.
Anyway. Using "just strings" *is wrong*.
> Instead of
> host, directory, device, name, type, and version, just a name. The
> generality is just not there anyways: you cannot specify (for
> example) the protocol (if you would like to open "http://..."). If
> some program needs versions (for instance), it should implement that
> itself.
The issue with "protocols" and "hosts" is well known. Yet it usually
does not bite you. Pondering a bit more on MERGE-PATHNAMES really buys
you a lot of mileage.
> * Use native tongue. What's the fuzz with the ";" char? And why do
> some lisp complain that "/home/mommer/data/whatever.dat" is a silly
> unix pathname? (huh?)
The fuzz here (I mean in LOGICAL-PATHNAMES) is that you may have to have
to port your code to a UNIX machine, to Windows and to Mac OS 9.x.
> Anything else would just work:
>
> * The need for configuration-dependant pathnames can be solved by
> using standard globals, which could be set by hand or by consulting
> the host system.
>
> * If you need "my-proggy.lisp" relative to
> "/magnus/faustus/galacticus/" just use CONCATENATE.
>
> * Wildcards should work like in the underlying system. Better yet:
> they should just refer to the underlying system, because it knows
> best (by definition) how to resolve these things.
Here is the catch! I do not want to worry about "the underlying system".
>
> What functionality would be missing? Yes, the utilities everybody
> needs: given a name, extract the directory, maybe the device (if this
> makes any sense on the system), but these could do that by parsing the
> string. Return a list with the names of the files in the directory
> including names of subdirectories, search for a file in a set of
> paths, return the current directory, etc. but all of this works better
> if it is made in the style of the host system.
What's wrong with PARSE-NAMESTRING and the PATHNAME accessors?
>
>
>
> > and ask the implementors to agree on them? AFAIK, this has not
> >happened yet (and maybe this is something I should have done).
>
>
> Hm... I don't know.
This is exactly the crux of the issue.
Let's take the problem of the "device" in PATHNAMES.
Let's assume (for the sake of the argument: I am not claiming technical
feasability here) that the implementors magically decided to agree that
PATHNAME-DEVICE is going to either be a single letter in [a-zA-Z] or the
name of one of the recognized IETF protocols (e.g. "http" or "news").
Always for the sake of the argument, let's assume that the implementors
all decided to have
(PARSE-NAMESTRING ".emacs") ==> #S(PATHNAME :NAME ".emacs")
on Unix.
I would be content with this state of affairs.
Munging strings is a suboptimal state of affairs.
regards
--
Marco Antoniotti
Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<·················@typhoon.nyu.edu>...
>
> Why don't you list a set of desiderata yopu want in the current PATHNAME
> stuff and ask the implementors to agree on them?
At a bare minimum, I would like to be able to use pathnames (including
logical pathnames) to generate any filename that my system can use.
For example "α" is a possible filename on my computer, but not
something I can use in a logical pathname; whether I can use it with
local case isn't immediately obvious, but logical pathnames don't
really support that well.
^L
······@cs.umass.edu (Louis Theran) writes:
> Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<·················@typhoon.nyu.edu>...
> >
> > Why don't you list a set of desiderata yopu want in the current PATHNAME
> > stuff and ask the implementors to agree on them?
>
> At a bare minimum, I would like to be able to use pathnames (including
> logical pathnames) to generate any filename that my system can use.
> For example "α" is a possible filename on my computer, but not
> something I can use in a logical pathname; whether I can use it with
> local case isn't immediately obvious, but logical pathnames don't
> really support that well.
This misses the point of logical pathnames, which is portability. If
you want a file name like the above, you can probably get it with
namestrings, but you can't expect something like that to be portable.
You have to see logical pathnames as trying to be a "lowest common
denominator" of file name specifications. That makes it far more
useful for a *standard language feature*, which logical pathnames are,
than something that is really good on, say, the Macintosh, but clunky
or broken everywhere else.
--
Fred Gilham ······@csl.sri.com
The rage of dance and style that swept the country in the late '70s
crumbled from serious backlash as disco freaks seemed to finally wake
up and realize what they were wearing. -- Michael Okwu
* Louis Theran wrote:
> At a bare minimum, I would like to be able to use pathnames (including
> logical pathnames) to generate any filename that my system can use.
> For example "α" is a possible filename on my computer, but not
> something I can use in a logical pathname; whether I can use it with
> local case isn't immediately obvious, but logical pathnames don't
> really support that well.
That's not what logical pathnames are for, as has been explained many
times in cll. They're there to provide a lowest-common-denominator
portable naming convention which is good enough to, say, allow you to
compile and load a system which has been designed with the use of
logical pathnames in mind.
--tim
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> That's not what logical pathnames are for, as has been explained many
> times in cll. They're there to provide a lowest-common-denominator
> portable naming convention which is good enough to, say, allow you to
> compile and load a system which has been designed with the use of
> logical pathnames in mind.
The objection is that pathnames are standardized to be useless for
most purposes. You seem to agree.
^L
> The objection is that pathnames are standardized to be useless for
> most purposes. You seem to agree.
Seems to me that they are usable for naming paths in file systems.
I guess the above critique of logical pathnames boils down to the fact
that they are lisp-application-centric. You wind up only being able
to use a subset of possible file names, with the benefit (not
mentioned above) that they will be usable on other systems as well.
But you can't guarantee that your Lisp application will be able to
construct a logical pathname that will allow it to name any file on
your particular system.
So be it. You usually have to wind up conditionalizing your file
naming scheme so it matches the OS. Lisp gives you the option of not
having to conditionalize. You can still use namestrings to get just
about any other file name.
--
Fred Gilham ······@csl.sri.com
The density of a textbook must be inversely proportional to the
density of the students using it. --- Dave Stringer-Calvert
* Louis Theran wrote:
> Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
>> That's not what logical pathnames are for, as has been explained many
>> times in cll. They're there to provide a lowest-common-denominator
>> portable naming convention which is good enough to, say, allow you to
>> compile and load a system which has been designed with the use of
>> logical pathnames in mind.
> The objection is that pathnames are standardized to be useless for
> most purposes. You seem to agree.
No, I don't `seem to agree'. Did you notice qualifier `logical' in
front of `pathname'? Do you understand that all pathnames are not
logical pathnames? Yes, of course you understand all that, you're
just deliberately misrepresenting what I said, aren't you. Now piss
off.
--tim
······@cs.umass.edu (Louis Theran) writes:
> At a bare minimum, I would like to be able to use pathnames (including
> logical pathnames) to generate any filename that my system can use.
Others have already explained that LPNs don't do this. I wanted to
make the point that even physical pathnames are not really ideal for
this purpose on Unix, though, because Unix doesn't have pathname types
except by convention, and as is usual for unix it's not a very tightly
agreed convention. So, implementations either have to do heuristics
or lose when parsing namestrings
* (let ((p #p"libfoo.so")) (list (pathname-name p) (pathname-type p) (pathname-version p)))
("libfoo" "so" :NEWEST)
... fair enough
* (let ((p #p"libfoo.so.1.0")) (list (pathname-name p) (pathname-type p) (pathname-version p)))
("libfoo.so.1" "0" :NEWEST)
... not as useful. On the other hand, we don't always want to parse
trailing numeric components as version, because that would lose with,
say, "/usr/man/man2/exit.2"
Then there are files which just don't fit the name/type/version scheme
at all. What should the pathname type of "README.gz" be? What about
"foo.lisp.gz" ?
One possibility I've toyed with occasionally is simply saying "unix
does not support file types, therefore pathname-type of anything
returns NIL". But, aside from being rather unfriendly, this doesn't
work either, because COMPILE-FILE-PATHNAME is defined in terms of
pathname type, so any time the user compiled anything without giving
an output filename it'd probably overwrite their source file.
Another idea would be for an implementation to introduce more hosts,
which would all map to the local filesystem but involve different
pathname parsers. Then you could say "raw:libfoo.so.1" for no type at
all, or "versioned:libfoo.so.1" for (:name "libfoo" :type "so"
:version "1"), or "gnu-version:backup.c.~3~" for (:name "backup" :type "c"
:version "3"). When you want to refer to a local file whose actual
name is "gnu-version:backup.c.~3~, you might have to be a bit careful,
of course.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
······@cs.umass.edu (Louis Theran) writes:
>
> At a bare minimum, I would like to be able to use pathnames (including
> logical pathnames) to generate any filename that my system can use.
> For example "α" is a possible filename on my computer, but not
> something I can use in a logical pathname; whether I can use it with
> local case isn't immediately obvious, but logical pathnames don't
> really support that well.
I think you have the design intent of logical pathnames backwards. The
point of logical pathnames is NOT "to generate any filename my system
can use". Instead the point of logical pathnames is "to name a file
that ANY file system can use." That is why it is so restrictive in the
naming conventions.
Logical pathnames are designed for portability across file and operating
systems. They don't let you generate arbitrary pathnames. They are
designed to allow you to use pathnames with a reasonable assurance that
those pathnames can, in fact, be realized on any file system you care to
use.
There are some ways in which they fail to reach this goal, for example
if you have a longer filename than the file system supports, but by and
large they achieve the goal of letting you refer to files that your
program supplies, even with different conventions about where the files
should go, and even different choices about mixing compiled and source
files in the same directory.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
* Mario S Mommer wrote:
> Nobody disagrees on what the rules are on unix and dos, or mac, for
> instance.
Except, of course, they do disagree, they just haven't even thought
hard enough about the issue to even realise they disagree.
Hint: what does "/tmp/bar/../fish" refer to? Given a program that
gets one interpretation how would notate the other? How would you
notate each interpretation using the CL PATHNAME facility? Name a
widely deployed UNIX application that gets each interpretation.
> It's just my personal opinion, anyway. I just find them PATHNAMES
> artificial and baroque, and if given a reasonable choice I would use
> something else /in *my* programs/. And before I implement some
> alternative I wanted to know if someone has done so already.
Well, from what you said earlier, you want something like what emacs
does which is ... strings. A big improvement on any kind of
structured representation, clearly.
I used to think that Common Lisp was like the steam turbine. We're
jumping up and down trying to get the navy to notice, but despite
rushing around in front of the fleet at Spithead at thirty knots, they
still insist that reciprocating engines are best, because
reciprocating engines are what they understand. They might be 13
knots slower than Turbinia, they might require major maintenance after
every few hours steaming at full power, they might shake themselves
and the ships they are in to bits, but they're *best*. Our only hope
is that Jacky Fisher is somewhere in the background with a twinkle in
his eye as he realises he can change the world for ever.
But this is wrong. CL *is* like the steam turbine, but we've made a
terrible mistake, and we're trying to persuade people from the bronze
age to adopt it. They understand how things can float, and
more-or-less how to sail, but this thing is made out of *metal*, and
metal of unearthly strength and strangeness - how can it float? How
can that much metal exist? What Gods or Demons made this thing? And
it's driven by a screaming dragon which belches smoke and steam, fed
on huge quantities of strange black rock by its acolytes, shovelling
the rock into its fiery maw. Truly this is a wonder, although most
likely it is sent by the Devil to kill us all. Better to stick to the
string we know.
Welcome to prehistory.
Mario S. Mommer <········@yahoo.com> writes:
> It's just my personal opinion, anyway. I just find them PATHNAMES
> artificial and baroque, and if given a reasonable choice I would use
> something else /in *my* programs/. And before I implement some
> alternative I wanted to know if someone has done so already.
Designing and implementing a really good abstraction for pathnames and related
entities would be interesting (haven't seen any so far), but quite a hard
task.
But if you just want something simple that gets the job done, why no just do a
quick port of e.g. python's os.path?
'as
On Thu, May 01, 2003 at 11:34:59PM +0100, Alexander Schmolck wrote:
> Mario S. Mommer <········@yahoo.com> writes:
>
> > It's just my personal opinion, anyway. I just find them PATHNAMES
> > artificial and baroque, and if given a reasonable choice I would use
> > something else /in *my* programs/. And before I implement some
> > alternative I wanted to know if someone has done so already.
>
> Designing and implementing a really good abstraction for pathnames and related
> entities would be interesting (haven't seen any so far), but quite a hard
> task.
>
> But if you just want something simple that gets the job done, why no just do a
> quick port of e.g. python's os.path?
Okay, I am starting to get annoyed here. Python's os.path is a real piece of
shit, as I had the displeasure of discovering a few days ago. Imagine my
surprise when I discovered that in order to change the type of a filename I had
to use ... STRING CONCATENATION ...
And forget about anything more advanced than the simplistic Unix pathname
concept, which ignores even issues that crop up on Unix filesystems.
OP: Stop whining about CL pathnames and just use them already. They really
aren't that bad. Come up with some more specific criticisms, particularly ones
that can't be addressed with a little bit of macrology or a wrapper. I am
interested in hearing them. (And I'm not speaking of logical pathnames, which
is a whole other story).
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> Okay, I am starting to get annoyed here. Python's os.path is a real piece of
> shit.
Is there anything in python's os.path etc. design that greatly complicated
implementing something you could have done easily (and
crossplatform/crossvendor) in CL?
'as
Alexander Schmolck wrote:
> Matthew Danish writes:
>
> >Okay, I am starting to get annoyed here. Python's os.path is a real
> piece of
> >shit.
>
>
> Is there anything in python's os.path etc. design that greatly complicated
> implementing something you could have done easily (and
> crossplatform/crossvendor) in CL?
Let's see what the Python os.path module actually is.
abspath(path)
Return a normalized absolutized version of the pathname
path. On most platforms, this is equivalent to
normpath(join(os.getcwd(), path)). New in version 1.5.2.
This is (merge-pathnames path (cl.env:cwd))
(Using my little CL.ENV package truly a small layer on CL, and note that
most implementation will always default to the current directory
automagically).
basename(path)
Return the base name of pathname path. This is the second
half of the pair returned by split(path). Note that the result
of this function is different from the Unix basename program;
where basename for '/foo/bar/' returns 'bar', the basename()
function returns an empty string ('').
This is (make-pathname :directory '() :defaults path)
commonprefix(list)
Return the longest path prefix (taken
character-by-character) that is a prefix of all paths in list. If
list is empty, return the empty string (''). Note that this
may return invalid paths because it works a character at a
time.
This can be replaced with a simple function. Note however that the
"character by character" requirement is debatable.
dirname(path)
Return the directory name of pathname path. This is the
first half of the pair returned by split(path).
This is (make-pathname :name nil :type nil :defaults p)
exists(path)
Return true if path refers to an existing path.
This is (probe-file path)
(in some implementations - since there is more than one for CL - this
may not work)
expanduser(path)
Return the argument with an initial component of "~" or
"~user" replaced by that user's home directory. An initial "~"
is replaced by the environment variable HOME; an initial "~user"
is looked up in the password directory through the built-in
module pwd . If the expansion fails, or if the path does not
begin with a tilde, the path is returned unchanged. On the
Macintosh, this always returns path unchanged.
This is truly platform dependent. Note that on Mac OX X, the documented
behavior is bogus.
expandvars(path)
Return the argument with environment variables expanded.
Substrings of the form "$name" or "${name}" are replaced by the
value of environment variable name. Malformed variable names and
references to non-existing variables are left unchanged. On the
Macintosh, this always returns path unchanged.
This is not so easy to render in a cross platform way. To render it in
CL you will need more study and more thinking.
getatime(path)
Return the time of last access of filename. The return value is
integer giving the number of seconds since the epoch (see the time
module). Raise os.error if the file does not exist or is
inaccessible. New in version 1.5.2.
This is
(defun file-access-time (path)
(error 'file-error :pathname path)
of course, you could rely on lower level routines available in your
implementation (again, one of the many).
getmtime(path)
Return the time of last modification of filename. The return
value is integer giving the number of seconds since the epoch
(see the time module). Raise os.error if the file does not exist
or is inaccessible. New in version 1.5.2.
This is (file-write-date path)
getsize(path)
Return the size, in bytes, of filename. Raise os.error if
the file does not exist or is inaccessible. New in version
1.5.2.
This is (file-length path)
isabs(path)
Return true if path is an absolute pathname (begins with a
slash).
This is (eq :absolute (first (pathname-directory path)))
isfile(path)
Return true if path is an existing regular file. This
follows symbolic links, so both islink() and isfile() can be
true for the same path.
This is inherently OS dependent.
isdir(path)
Return true if path is an existing directory. This follows
symbolic links, so both islink() and isdir() can be true for the
same path.
This is roughly (and (directory-pathname-p path) (probe-file path))
where
(defun directory-pathname-p (path)
(and (null (pathname-name path))
(null (pathname-type path))))
:UNSPECIFIC happily swept under the carpet.
islink(path)
Return true if path refers to a directory entry that is a
symbolic link. Always false if symbolic links are not supported.
This is platform and implementation dependent.
ismount(path)
Return true if pathname path is a mount point: a point in a
file system where a different file system has been mounted. The
function checks whether path's parent, path/.., is on a
different device than path, or whether path/.. and path point to
the same i-node on the same device -- this should detect mount
points for all Unix and POSIX variants.
This is platform and implementation dependent.
join(path1[, path2[, ...]])
Joins one or more path components intelligently. If any
component is an absolute path, all previous components are
thrown away, and joining continues. The return value is the
concatenation of path1, and optionally path2, etc., with exactly
one slash ('/') inserted between components, unless path is
empty.
This can be done by repeatedly applying MERGE-PATHNAMES.
normcase(path)
Normalize the case of a pathname. On Unix, this returns the
path unchanged; on case-insensitive filesystems, it converts the
path to lowercase. On Windows, it also converts forward slashes
to backward slashes.
This is done at PARSE-NAMESTRING time.
normpath(path)
Normalize a pathname. This collapses redundant separators
and up-level references, e.g. A//B, A/./B and A/foo/../B all
become A/B. It does not normalize the case (use normcase() for
that). On Windows, it converts forward slashes to backward
slashes.
This is done is several ways in CL, depending on the need. You may use
NAMESTRING or TRUENAME.
realpath(path)
Return the canonical path of the specified filename,
eliminating any symbolic links encountered in the path.
Availability: Unix. New in version 2.2.
This is roughly (truename path)
samefile(path1, path2)
Return true if both pathname arguments refer to the same
file or directory (as indicated by device number and i-node
number). Raise an exception if a os.stat() call on either
pathname fails. Availability: Macintosh, Unix.
This is (pathname-match-p (truename path1) (truename path2))
sameopenfile(fp1, fp2)
Return true if the file objects fp1 and fp2 refer to the
same file. The two file objects may represent different file
descriptors. Availability: Macintosh, Unix.
This is (pathname-match-p (file-stream-file s1) (file-stream-file s2))
samestat(stat1, stat2)
Return true if the stat tuples stat1 and stat2 refer to the
same file. These structures may have been returned by fstat(),
lstat(), or stat(). This function implements the underlying
comparison used by samefile() and sameopenfile(). Availability:
Macintosh, Unix.
This is platform and implementation dependent.
split(path)
Split the pathname path into a pair, (head, tail) where tail
is the last pathname component and head is everything leading up
to that. The tail part will never contain a slash; if path ends
in a slash, tail will be empty. If there is no slash in path,
head will be empty. If path is empty, both head and tail are
empty. Trailing slashes are stripped from head unless it is the
root (one or more slashes only). In nearly all cases, join(head,
tail) equals path (the only exception being when there were
multiple slashes separating head from tail).
This is what all the PATHNAME-* accessors do.
splitdrive(path)
Split the pathname path into a pair (drive, tail) where
drive is either a drive specification or the empty string. On
systems which do not use drive specifications, drive will always
be the empty string. In all cases, drive + tail will be the same
as path. New in version 1.3.
This may be PATHNAME-DEVICE (but different implementation differ in
their interpretation).
splitext(path)
Split the pathname path into a pair (root, ext) such that
root + ext == path, and ext is empty or begins with a period and
contains at most one period.
This is not wery well defined.
walk(path, visit, arg)
Calls the function visit with arguments (arg, dirname,
names) for each directory in the directory tree rooted at path
(including path itself, if it is a directory). The argument
dirname specifies the visited directory, the argument names
lists the files in the directory (gotten from
os.listdir(dirname)). The visit function may modify names to
influence the set of directories visited below dirname, e.g., to
avoid visiting certain parts of the tree. (The object referred
to by names must be modified in place, using del or slice
assignment.)
This could be (roughly)
(defun file-system-walk (path visit)
;; No need for 'arg', whose semantics is unclear.
(multiple-value-bind (files directories)
(discern (directory path))
(dolist (f files)
(funcall visit f))
(dolist (d directories)
(file-system-walk d visit))))
So, the bottom line is that you do not need to rewrite os.path in CL as
everything you need is available and more manageable (meaning: you
manipulate structured objects and not strings). When it is not
available it is usually a few implementation dependent steps away.
You can argue that the missing part should be available in CL (the
`stat' stuff, for example. But you cannot ask CLers to do what others
do: apply Greenspun's Tenth :)
Cheers
--
Marco Antoniotti
> Let's see what the Python os.path module actually is.
>
> basename(path)
>
> This is (make-pathname :directory '() :defaults path)
If you assume Unix. Otherwise, HOST NIL :DEVICE NIL as well.
> (defun directory-pathname-p (path)
> (and (null (pathname-name path))
> (null (pathname-type path))))
> :UNSPECIFIC happily swept under the carpet.
Don't, it's perfectly standard. I'd also recommend calling TRUENAME
for this, to handle symbolic links to directories. This function has
been discussed before on this newsgroup, and it's unfortunately hard
to do portably, due to lax interpretation of directory truenames by
various implementations. For widely portable apps, this one has to
be in the OS-compatibility layer.
> sameopenfile(fp1, fp2)
>
>This is (pathname-match-p (file-stream-file s1) (file-stream-file s2))
FILE-STREAM-FILE is non-standard, use TRUENAME.
--
Pekka P. Pirinen
A. Top posters.
Q. What is the most annoying thing on Usenet?
On Fri, May 02, 2003 at 01:08:02AM +0100, Alexander Schmolck wrote:
> Matthew Danish <·······@andrew.cmu.edu> writes:
> > Okay, I am starting to get annoyed here. Python's os.path is a real piece of
> > shit.
>
> Is there anything in python's os.path etc. design that greatly complicated
> implementing something you could have done easily (and
> crossplatform/crossvendor) in CL?
I really like having a pathname object so that I don't have to sit and parse
the namestring myself (or even with supplied functions). It's far more
convenient for dealing with things such as...pathname type. :UP and :BACK are
also something you don't find in Python's UNIX-centric outlook. Especially
ironic considering symlinks.
Of course, if the underlying filesystem's semantics are fuzzy to begin with, I
can't really expect much of either system. But you can still get by, and I see
no reason to replace such a working pathname system in CL with a hacked
together string-based os.path-alike with dubious benefits.
I bet those UNIX folks thought they were being mighty clever... making it
impossible to implement a reasonable pathname abstraction without tons of
contextual information. I mean, who programs a UNIX system anyway, it was
obviously built for users.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish:
> I bet those UNIX folks thought they were being mighty clever...
the design is a straight-forward adaptation of the multics pathname
design but with _/_ as seperator, instead of _>_. not sure why some
pathname abstractions were not implemented in libc; you may want to
ask this to dmr directly, if you are really interested. my guess is
that it was just simpler to use strings at the time, for the few
programs[1] that needed to worry about it.
oz
---
[1] basename command existed in UPM, ver 1.0, feb 79. :)
* ozan s yigit wrote:
> the design is a straight-forward adaptation of the multics pathname
> design but with _/_ as seperator, instead of _>_. not sure why some
> pathname abstractions were not implemented in libc; you may want to
> ask this to dmr directly, if you are really interested. my guess is
> that it was just simpler to use strings at the time, for the few
> programs[1] that needed to worry about it.
My guess is that, given the tiny memory of a PDP11 you didn't want to
waste space on abstractions you didn't absolutely need.
--tim
Tim Bradshaw <···@cley.com> writes:
> My guess is that, given the tiny memory of a PDP11 you didn't want to
> waste space on abstractions you didn't absolutely need.
that is a reasonable guess. for example in the 6th ed kernel, all pathnames
are immediately handed over to namei to convert it to an inode pointer, and
are not touched again.
oz
--
music is the space between the notes. -- claude debussy
* ozan s yigit wrote:
> that is a reasonable guess. for example in the 6th ed kernel, all pathnames
> are immediately handed over to namei to convert it to an inode pointer, and
> are not touched again.
The tragedy of computing is that the perfectly legitimate tradeoffs
that were made to squeeze a multiuser OS onto a machine with
64k(words) of address space, executing well under a million
instructions a second have become the received wisdom on machines with
thousands of times as much memory, executing billions of instructions
a second, and with performance characteristics almost entirely
different than a PDP11.
--tim
Tim Bradshaw :
> The tragedy of computing is that the perfectly legitimate tradeoffs
> that were made to squeeze a multiuser OS onto a machine with
> 64k(words) of address space, executing well under a million
> instructions a second have become the received wisdom on machines with
> thousands of times as much memory, executing billions of instructions
> a second, and with performance characteristics almost entirely
> different than a PDP11.
i don't think it is received wisdom; you are well aware pike et al. have
worked hard to change many of this. [relevant to this discussion, painful
parts like "Lexical file names in plan 9, or, getting dot-dot right"] there
is of course the curse of the installed base, there is many years of common
practice before www, where pathnames or things that look like pathnames
were not munged a lot and so on. it just wasn't even on the radar maybe
until NFS came along...
oz
--
We could make a computer look like a grapefruit.
-- Jonathan Ives, Apple VP of Industrial Design
* ozan s yigit wrote:
> i don't think it is received wisdom; you are well aware pike et
> al. have worked hard to change many of this.
Yes, I am aware. But I think they have, so far, failed to make any
significant impact on how people think. Which is, I think, a tragedy,
and says something very bad indeed about the state of computing.
(Incidentally, I didn't just mean pathnames, I meant the whole
mindset. To pick another example, pervasive bounds-checking was *of
course* absurdly unrealistic on a PDP11, so we live with frequent
buffer-overflow attacks in security-critical software.)
Computer science is essentially a medieval cult - while the hierarchy
is busy holding endless arguments over angels and pins (except they
call it call/cc and strong typing) everyone else is wallowing around
in the mud and dying in multitudes of diseases that the most
elementary precautions would prevent.
--tim
Tim Bradshaw <···@cley.com> writes:
> * ozan s yigit wrote:
>
> > i don't think it is received wisdom; you are well aware pike et
> > al. have worked hard to change many of this.
>
> Yes, I am aware. But I think they have, so far, failed to make any
> significant impact on how people think. Which is, I think, a tragedy,
> and says something very bad indeed about the state of computing.
>
> (Incidentally, I didn't just mean pathnames, I meant the whole
> mindset. To pick another example, pervasive bounds-checking was *of
> course* absurdly unrealistic on a PDP11, so we live with frequent
> buffer-overflow attacks in security-critical software.)
>
> Computer science is essentially a medieval cult - while the hierarchy
> is busy holding endless arguments over angels and pins (except they
> call it call/cc and strong typing) everyone else is wallowing around
> in the mud and dying in multitudes of diseases that the most
> elementary precautions would prevent.
Leaving Lispers who try to design things robustly as ... Moors
stranded in Europe? What I'd give for a good map, instead of
grandiose geographical theories about the location of Andalus.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
* Thomas F Burdick wrote:
> Leaving Lispers who try to design things robustly as ... Moors
> stranded in Europe? What I'd give for a good map, instead of
> grandiose geographical theories about the location of Andalus.
Right. We're the Muslims, in fact.
--tim
* ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick)
| Leaving Lispers who try to design things robustly as ... Moors
| stranded in Europe? What I'd give for a good map, instead of
| grandiose geographical theories about the location of Andalus.
I happen to live in the zone and have 4 ft wide map of it
just in front of me. I could help you for a small fee
Sir. Would you like to know the location of Tarifa? Malaga?
Granada maybe? Just drop me a note Sir <g>
--
Eduardo Mu�oz | (prog () 10 (print "Hello world!")
http://213.97.131.125/ | 20 (go 10))
On 04 May 2003 21:39:32 +0100, Tim Bradshaw <···@cley.com> wrote:
> Computer science is essentially a medieval cult - while the hierarchy
> is busy holding endless arguments over angels and pins (except they
Indeed, Unix has daemons and PIDs.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Hi,
> After some study of CL pathnames, I decided that I would rather use
> something else[...] I find the elisp interface a bit more reasonable.
That's funny; over time I've come to hold quite the opposite opinion.
The fact that Emacs doesn't use a pathname model has driven me up the
wall on several occasions. We have to make do with its abstraction-
starved pathnames-as-strings-and-strings-only interface. Some of the
problems of this are brilliantly illustrated in the integration of Tramp
into Emacs; check these emacs-devel threads for more:
http://mail.gnu.org/archive/html/emacs-devel/2001-08/msg00001.html
http://mail.gnu.org/archive/html/emacs-devel/2001-10/msg00012.html
http://mail.gnu.org/archive/html/emacs-devel/2001-10/msg00026.html
http://mail.gnu.org/archive/html/emacs-devel/2001-11/msg00090.html
http://mail.gnu.org/archive/html/emacs-devel/2002-04/msg00206.html
http://mail.gnu.org/archive/html/emacs-devel/2002-06/msg00399.html
http://mail.gnu.org/archive/html/emacs-devel/2002-06/msg00566.html
http://mail.gnu.org/archive/html/emacs-devel/2003-04/msg00631.html
etc., etc.
Now I think Tramp is great, and use it all the time. It strikes me that
so much of the pain of integrating its functionality into Emacs could
have been alleviated with reasonable pathname objects.
Ted
--
Edward O'Connor
·······@soe.ucsd.edu