Question / comment about DIRECTORY
JP Massar
-------
Notes:
If the pathspec is not wild, the resulting list will contain either
zero or one elements.
------
but both Allegro and Lispworks, at least on Windows 98, seem to
violate this, as in (in Allegro):
> (setq x (pathname "C:/Lispcode/"))
#p"C:\\Lispcode\\"
> (wild-pathname-p x)
NIL
> (length (directory x))
19
>
Corman Lisp returns NIL in this case, which is neither clearly correct
nor incorrect. (Should it return the pathname which represents
"C:/Lispcode" or "C:/Lispcode/" or NIL ?)
In the case of
(directory "C:/Lispcode/foo.lisp")
assuming it exists
Corman Lisp returns NIL, which seems pretty clearly wrong, while
Allegro returns a one-element list of the pathname representing the
file.
Corman Lisp returns a list of pathnames for
(directory "C:/Lispcode/*")
as does Allegro and Lispworks. But Corman Lisp's return list does not
contain any pathnames of the subdirectories of "C:/Lispcode/", whereas
the others do. It is not 100% clear that subdirectories must be
included in the results returned by DIRECTORY, but the definition of
FILE
FILE: a named entry in a file system
in the hyperspec, would suggest that a subdirectory satisifies this
definition.
Kent M Pitman
> The hyperspec says, under DIRECTORY:
>
> -------
>
> Notes:
>
> If the pathspec is not wild, the resulting list will contain either
> zero or one elements.
>
> ------
>
> but both Allegro and Lispworks, at least on Windows 98, seem to
> violate this, as in (in Allegro):
>
> > (setq x (pathname "C:/Lispcode/"))
> #p"C:\\Lispcode\\"
> > (wild-pathname-p x)
> NIL
> > (length (directory x))
> 19
Yeah, from a very strict reasing I thin you're right. But I think of
C:/Lispcode/ as meaning :name :wild, :type :wild, :version :wild.
If we had described this function as being called on a defaulted
pathname, all the text you see would be the same but the program would
be conforming...
What *does* bother me is implementations that treat C:/Lispcode as
if it meant C:/Lispcode/ just because the implementation secretly has
consulted the file system and found it to be a dir. Much though Unix
file systems have this bug, I don't think it should go ahead and add
the "/" and then treat it as a directory....
Just my opinion, of course. But if it does this unasked-for favor for
you, none of the "algebra" on filenames works. (I suspect there's better
ways of saying this if I'd had group theory, but I haven't, so maybe
someone can fill in the right words for the probably-well-known problem
I'm getting at.)
> Corman Lisp returns NIL in this case, which is neither clearly correct
> nor incorrect. (Should it return the pathname which represents
> "C:/Lispcode" or "C:/Lispcode/" or NIL ?)
Personally, I think if you name something with a filename part, then it
should return you a file, but if you name a dir, you should get dir contents.
If anything, the problem is that C:/Lispcode/ is only provisionally wild,
depending on whether you are using it for this function or for other
functions.
Btw, the reason I think this is that I think C:/foo/ really means
name=NIL, type=NIL, version=NIL, and I further think that the system
should never contact the native file system without filling NILs. So in
the context of DIRECTORY, I feel that whether the spec says to or not,
the function must of necessity fill those slots. And, moreover, in a dir
listing, I think :wild is the natural filler for unsupplied slots.
It's a pity this is ill-described. The pathname chapter was top on my list
of worst chapters and most desperately in need of further work when the
timetable for being done came along and we literally just had to stop and
call the spec done. The stuff that is there was somewhat untangled from
CLTL, but it was still far from beaten into anything I'd call reasonable
shape. And, to be honest, I bet most people weren't able to read the spec
well enough to really know if they agreed or disagreed with most of the
stuff there as a consequence. Rather, we used the same reasoning we used
in many other places: it's no worse than CLTL, and people have gotten by for
years on what was there... I know, you might wish it was more, but there was
also value to getting the thing out the door before all Lisp companies
were bankrupt, too. I think we made the right decision, but I still cringe
when people try to read this and a few other sections like as if we meant
what we wrote....
I'd rather see implementations do something reasonable and willfully divergent
than something that's slavishly adherent and conceptually wrong in the cases
where the situation is borderline and even a feeble argument can be made for
it, as is the case here, I think...
> In the case of
>
> (directory "C:/Lispcode/foo.lisp")
>
> assuming it exists
>
> Corman Lisp returns NIL, which seems pretty clearly wrong, while
> Allegro returns a one-element list of the pathname representing the
> file.
>
> Corman Lisp returns a list of pathnames for
>
> (directory "C:/Lispcode/*")
>
> as does Allegro and Lispworks. But Corman Lisp's return list does not
>
> contain any pathnames of the subdirectories of "C:/Lispcode/", whereas
> the others do. It is not 100% clear that subdirectories must be
> included in the results returned by DIRECTORY, but the definition of
> FILE
>
> FILE: a named entry in a file system
>
> in the hyperspec, would suggest that a subdirectory satisifies this
> definition.
I think it should return the subdirs. Otherwise, how do you recurse down
the file tree?
James A. Crippen
> What *does* bother me is implementations that treat C:/Lispcode as
> if it meant C:/Lispcode/ just because the implementation secretly has
> consulted the file system and found it to be a dir. Much though Unix
> file systems have this bug, I don't think it should go ahead and add
> the "/" and then treat it as a directory....
I hate that 'feature'. It did take some getting used to when I first
encountered it, but it's much more useful to be able to say "gimme the
directory's file" when I mean it, and "gimme the files in the
directory" when I mean that.
And consider a file system that has separate namespaces for files and
directories. In this case a directory most certainly has none of the
properties of a file, and can't be treated as such. Indeed, a file
and directory with the same path could well exist since their names
wouldn't collide. But under Unix and Windows this is certainly not
true, since any normal file operation can do *something* (although not
always useful) with a directory. The separation should exist clearly,
no matter what Unix programmers think of it. Lisp isn't Unix, it
shouldn't propagate Unix brain damage.
> Just my opinion, of course. But if it does this unasked-for favor for
> you, none of the "algebra" on filenames works. (I suspect there's better
> ways of saying this if I'd had group theory, but I haven't, so maybe
> someone can fill in the right words for the probably-well-known problem
> I'm getting at.)
I think what's happened is that the typed representation has changed
from filename string to directory name string and the operators aren't
defined for that type. Sound right?
'james
--
James A. Crippen <ja...@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
Marco Antoniotti
Kent M Pitman <pit...@world.std.com> writes:
...
> It's a pity this is ill-described. The pathname chapter was top on my list
> of worst chapters and most desperately in need of further work when the
> timetable for being done came along and we literally just had to stop and
> call the spec done. The stuff that is there was somewhat untangled from
> CLTL, but it was still far from beaten into anything I'd call reasonable
> shape. And, to be honest, I bet most people weren't able to read the spec
> well enough to really know if they agreed or disagreed with most of the
> stuff there as a consequence. Rather, we used the same reasoning we used
> in many other places: it's no worse than CLTL, and people have gotten by for
> years on what was there... I know, you might wish it was more, but there was
> also value to getting the thing out the door before all Lisp companies
> were bankrupt, too. I think we made the right decision, but I still cringe
> when people try to read this and a few other sections like as if we meant
> what we wrote....
>
> I'd rather see implementations do something reasonable and willfully
> divergent than something that's slavishly adherent and conceptually
> wrong in the cases where the situation is borderline and even a
> feeble argument can be made for it, as is the case here, I think...
I have a suggestion here. (You may not like it, but here it is).
Why don't *you* write a "Revised and Cleaned Up Pathname Spec",
that all implementors can follow easily?
Ok. I know where the crunch is.
The three (or more) vendors could write an "appointment letter" on
your behalf to have you work as a consultant. They will pay for your
work, with the provision that the resulting document will be binding
on them and that it will be made public (e.g. on C.L.L.).
Wow, this has been an amazingly easy post to write. KMP does the work
and I do not spend a pennyน. :)
Cheers
Marco
น Actually, considering how much our ACL license renewal has
costed....?!? :)
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> writes:
>
> > What *does* bother me is implementations that treat C:/Lispcode as
> > if it meant C:/Lispcode/ just because the implementation secretly has
> > consulted the file system and found it to be a dir. Much though Unix
> > file systems have this bug, I don't think it should go ahead and add
> > the "/" and then treat it as a directory....
>
> I hate that 'feature'. It did take some getting used to when I first
> encountered it, but it's much more useful to be able to say "gimme the
> directory's file" when I mean it, and "gimme the files in the
> directory" when I mean that.
The thing I hate about it is that people casually leave off "/" on URLs
and expect that many hosts will re-supply it, but it competely changes
the URL merging rules. An equivalent thing happens in file systems, of
course, but it's hugely rampant on web addresses. I used to advertise
my web directory with a "/" on the end and people would leave it off,
so that "foo.html" in the files would resolve by replacing "/pitman" as
"/foo.html" instead of subdirectorying as "/pitman/foo.html". Then they
send ME the bug reports, like as if I've written the HTML wrong.
The same problem happens in pathnames, and the players are different, but
the characteristic misplacement of blame is the same.
> And consider a file system that has separate namespaces for files and
> directories.
Yes, I've known such. It is a pity, therefore, that we don't have
more elaborated file manipulation tools in CL. Fortunately, I don't know
any to be in play now in any commercial context. Do you?
> In this case a directory most certainly has none of the
> properties of a file, and can't be treated as such. Indeed, a file
> and directory with the same path could well exist since their names
> wouldn't collide. But under Unix and Windows this is certainly not
> true, since any normal file operation can do *something* (although not
> always useful) with a directory. The separation should exist clearly,
> no matter what Unix programmers think of it. Lisp isn't Unix, it
> shouldn't propagate Unix brain damage.
>
> > Just my opinion, of course. But if it does this unasked-for favor for
> > you, none of the "algebra" on filenames works. (I suspect there's better
> > ways of saying this if I'd had group theory, but I haven't, so maybe
> > someone can fill in the right words for the probably-well-known problem
> > I'm getting at.)
>
> I think what's happened is that the typed representation has changed
> from filename string to directory name string and the operators aren't
> defined for that type. Sound right?
Yes, but it misses my point.
I was expecting someone to identify the set of pathnames and operators
among them as some word like "group" or "field" or "ring" or
something--I can never keep thems straight--and to talk about
meta-rules of identities and inverses and stuff being violated. File
systems and the operators on them are like Rubik's cube--you should be
able to manipulate your point of view, to transform and untransform things,
etc. and end up reliably back in a certain place, but there are certain
fudge operators like the "trailing /" problem above that break these nice
simple algebraic properties. There's a whole formal, and as far as I
can tell "relatively straightforward" vocabulary of terminology I wish I
had at my disposal, but sadly, for accidents of history/time/effort, I
don't. I encourage any students peeking in on the discussions to
take a group theory course if they have the opportunity...
Christophe Rhodes
> Kent M Pitman <pit...@world.std.com> writes:
>
> > I'd rather see implementations do something reasonable and willfully
> > divergent than something that's slavishly adherent and conceptually
> > wrong in the cases where the situation is borderline and even a
> > feeble argument can be made for it, as is the case here, I think...
>
> I have a suggestion here. (You may not like it, but here it is).
>
> Why don't *you* write a "Revised and Cleaned Up Pathname Spec",
> that all implementors can follow easily?
How about something like this (informal, for now):
* The use of pathnames is deprecated;
* A new object, a URI, is introduced. PARSE-URI and MERGE-URI do the
correct things (RFC 2396) with respect to string arguments and
*DEFAULT-URI-DEFAULTS*, which is expected initially to be set to the
result of parsing "file://localhost/<dir>/", where <dir> is what is
the `current directory'.
* Functions which previously accepted pathnames should be extended to
also accept URIs, though it is unspecified behaviour should they be
fed a URI that is not of the file scheme with localhost as the
authority component. In particular, LOAD, COMPILE-FILE, and OPEN
should work.
Cheers,
Christophe
PS: toy implementation (no guarantees, incomplete, will get back to it
eventually) at <URI:http://www-jcsu.jesus.cam.ac.uk/~csr21/uri.lisp>.
I hope that what I'm driving at is clear, even if I haven't yet spent
the time on writing it up properly. With a properly-specified user
extension mechanism (as in that file, by subclassing and writing
methods) we can obtain something that has most of the advantages of
logical pathnames, with fewer drawbacks (I think, anyway).
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Lieven Marchand
> But under Unix and Windows this is certainly not true, since any
> normal file operation can do *something* (although not always
> useful) with a directory. The separation should exist clearly, no
> matter what Unix programmers think of it. Lisp isn't Unix, it
> shouldn't propagate Unix brain damage.
Even in Unix this isn't consistent and depends on version and
command. I've come across vendor supplied tar's where 'tar cvf foo.tar
dir' would just add the directory and 'tar cvf foo.tar dir/' would add
the directory and everything under it.
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Barry Fishman
> Kent M Pitman <pit...@world.std.com> writes:
>
>> What *does* bother me is implementations that treat C:/Lispcode as
>> if it meant C:/Lispcode/ just because the implementation secretly has
>> consulted the file system and found it to be a dir. Much though Unix
>> file systems have this bug, I don't think it should go ahead and add
>> the "/" and then treat it as a directory....
>
> I hate that 'feature'. It did take some getting used to when I first
> encountered it, but it's much more useful to be able to say "gimme the
> directory's file" when I mean it, and "gimme the files in the
> directory" when I mean that.
Just an aside.
I have used Unix for quite some time, and the automatic appending of
"/" to directory names has never been a part of any Unix or GNU
systems I have used. Slashes are path separators, not file type
extensions (which Unix does not have). Try typing "pwd" sometime and
see what you get. It would make more sense to interpret (in Unix)
/home/jones/ as a null named file in Jone's home directory, but of
course, this is not done. Several applications (most notably emacs)
seems to feel they are doing the user a favor by adding a slash, but
this only complicates code which now needs to test for and remove
slashes when constructing file paths by concatenation. I suspect a
great deal of elisp and cpu time is wasted to enforce the idea
that directories end in /, irrespect of the OS primitives, rather than
just a bit of filename TAB completion code in the interactive filename
prompting routines.
I must admit I have problems understanding Common Lisp's PATHNAME
approach, at least having come from Unix and VMS. Lisp seems to be
trying very hard to expose a content in filenames which Unix has taken
a great effort to hide. In fact this hiding is one of the major
design rationals of Unix. Common Lisp has its own rationals, and no
reason or obligation to follow the Unix design, but isn't the attributes
implied by a filename really determined by the filesystem, and
should likewise not be restricted by how Lisp chooses to organize it
into its own virtual file layout. For example, where do I store my
protocol field? Maybe a imbedded string hack? What is the meaning of
a host attribute for a file that each record read might choose a
different host?
Common Lisp could have used CLOS to provide a much more general file
interface, with a much simpler set of common functions (and a more
documented interface for each file system), or it could have just
avoided the issue and used filesystem specific strings to represent
file names. Instead the authors seemd to have taken a guess, (maybe
based on lisp machines of which I am not familiar),
Barry Fishman
Kent M Pitman
> I must admit I have problems understanding Common Lisp's PATHNAME
> approach, at least having come from Unix and VMS. Lisp seems to be
> trying very hard to expose a content in filenames which Unix has taken
> a great effort to hide.
The notion is that you should syntactically be able to tell what is a
directory and what is not without doing file I/O.
And Unix, while prevalent now, is a late-comer to the OS world. CL's
pathname system was designed to embrace about 20 different operating
systems that were all in common use in the late 70's and early 80's.
> ... isn't the attributes
> implied by a filename really determined by the filesystem ...
Common Lisp does not purport to use the file system notation. It is up to the
implementation to offer a mechanism for doing that.
I can't speak to Emacs. It is not a Common Lisp and has its own
rationale, though probably similar to CL's. Emacs was also not originally
a Unix thing either, by the way, much though Unix people like to think so.
A great deal of its design was initially ported from the Teco version and
from operating systems in which directoriness WAS more apparent.
> ... What is the meaning of
> a host attribute for a file that each record read might choose a
> different host?
A "file host" is not obliged to be the same as a "network host". So the
answer is "the meaning is: a file host that chooses each record from a
different network host".
> Common Lisp could have used CLOS to provide a much more general file
> interface,
No, it could not have. CL was designed well in advance of CLOS. CLOS is
a second-generation addition and, because it was new and untested, had to
be added as a modular addition. Even the condition system, which uses
CLOS, uses it in a very weak way that was designed to allow the condition
system to survive a backout of CLOS usage, if that had happened.
People like to believe that language design is a technical process, but it
simply is not. You're welcome to design a language that has no political
constraints, but expect to start up with no users and a big missionary
process of convincing anyone that your language is worth implementing, worth
using, etc. There are some very good reasons for the approach CL took, but
it came with some cosntraints.
> with a much simpler set of common functions (and a more
> documented interface for each file system),
Here you are definitely wrong. The CL pathname system was based on
the Lisp Machine pathname system, mostly by taking about half of the
functionality already present on the LispM because people felt that
"not taking everything" showed "good conservativism". I think this
was a bad way to go and they should have instead trusted that the
LispM people had thought hard about it. But the LispM system, which
accomodates NUMEROUS file systems (much more than just Unix) is
probably a lot less simple than you think because the true space of
operating system file systems is much more diverse than you think.
That's not to say it can't be done in an object-oriented fashion with
defined protocols for extension--it's only to say that if you saw the
protocols for extension, you'd instead be whining about how some of them
seem unnecessary, I bet, since your message has a very Unix-centric bias
showing in it, whether intended or not.
> or it could have just avoided the issue
I really seriously doubt that.
> and used filesystem specific strings to represent
> file names.
I seriously doubt that, too. The LispM has a :string-for-host that you
can send to a host to get its file system specific name, but it's really
impractical to restrict an implementation to use the native string syntax
directly, since users are often prompted for filenames, and since the lisp
file system may be capable of accessing many more files than the native
file system, so requiring the read-line'd pathnames to just access the native
file system (when the native file system can't likewise access all the things
Lisp can) is a way of cutting Lisp users and users of applications built
in Lisp off from much of the power that Lisp ought to offer them.
> Instead the authors seemd to have taken a guess, (maybe
> based on lisp machines of which I am not familiar),
No, not a guess. The LispM had carefully studied the issue of
multiple namespaces, protocols, host syntaxes, etc. and had a fully
deployed working model that was way more complex than CL designers
were prepared to include. The LispM system was not guesswork and not
a hack. CL subsetted this work and mostly did a reasonable job; lots
of room was left open for vendor extensions, and some vendors have
extended things. This makes it a little tough on portable code, but so
it goes.
I think calling something a guess, when you are making only guesses
yourself in the reasoning that leads you to make such accusations,
is highly unfair and inappropriate.
Tim Bradshaw
> Several applications (most notably emacs)
> seems to feel they are doing the user a favor by adding a slash, but
> this only complicates code which now needs to test for and remove
> slashes when constructing file paths by concatenation.
Can you give an example of this? It seems to me that if I want to
concatenate two directories D1 and D2 then (assuming trailing slashes)
the algorithm is:
(if (char= (aref d2 0) #\/)
;; D2 is absolute
d2
(concatenate 'string d1 d2))
Similarly if I want to create a filename F in a directory D the algorithm
is
(concatenate 'string d f)
--tim
Tim Bradshaw
> The thing I hate about it is that people casually leave off "/" on URLs
> and expect that many hosts will re-supply it, but it competely changes
> the URL merging rules. An equivalent thing happens in file systems, of
> course, but it's hugely rampant on web addresses. I used to advertise
> my web directory with a "/" on the end and people would leave it off,
> so that "foo.html" in the files would resolve by replacing "/pitman" as
> "/foo.html" instead of subdirectorying as "/pitman/foo.html". Then they
> send ME the bug reports, like as if I've written the HTML wrong.
I *think* that's a bug in the webserver. What should happen is either
that it should send you a redirect to the right URL (at which point
the URL min the browser should be right), or it should say that the
URL isn't valid. Certainly that's what apache does (for our
configuration anyway). I think there used to be a bug in some
webservers where, for some URLs, they'd just return the page they
thought you meant. Certainly if I ask for /~pitman now I get a
redirect, buty I'm reasonably sure that at some point I didn't, I just
got the page I `meant'.
None of this should be taken to mean that I think it's OK to randomly
leave trailing slashes off: I think it's reasonable behaviour for
something interactive like a web server to correct the error (by
suggesting a redirect), but I definitely don't think it's good in a
program.
--tim
Barry Fishman
> Barry Fishman <barry_...@acm.org> writes:
>
>> I must admit I have problems understanding Common Lisp's PATHNAME
>> approach, at least having come from Unix and VMS.
.....
> That's not to say it can't be done in an object-oriented fashion with
> defined protocols for extension--it's only to say that if you saw the
> protocols for extension, you'd instead be whining about how some of them
> seem unnecessary, I bet, since your message has a very Unix-centric bias
> showing in it, whether intended or not.
Thinking that object-oriented design requires extension protocols
shows a very lisp-centric bias. :)
Can't expressing something from a particular point of view be just a
way of supplying some context to explore the implications of an idea.
It does not mean that one is unable to accept (or understand) a
response which uses a different context. In fact, isn't this a usual
way to explain something?
I was really looking for some examples or pointers to technical
papers which explored the design decisions that were made. I still
am. I'm sorry if you felt I was expressing arrogance, but how else
could I focus on what precise issues I didn't understand? Just asking
a general question would give you no indication of what my confusion
was. I can get the answers to general questions elsewhere.
I do sense from your text a sensitivity, which I find a bit alarming,
although typical in this group. If this involved young college
students rather than people who are well known for their
contributions, I don't think I would be as disturbed.
It's hard to tell just by looking at their text how people really
feel. I know when I worked as a research assistant, it was common to
tell a fellow programmer things like, "Lets see if you have a brain,"
without meaning any malice. It was just a sarcastic way to help
us separate a possibly heated technical discussion from our personal
feelings about each other. This does not transfer to text very well.
But too apologetic text does become quite sickening.
I guess I'll just go elsewhere for information.
Barry Fishman
JP Massar
>
>It's a pity this is ill-described.
Right. It's not a good situation when one can't write portable code
to search a directory tree using ANSI Common Lisp's on the same OS.
> The pathname chapter was top on my list
>of worst chapters and most desperately in need of further work when the
>timetable for being done came along and we literally just had to stop and
>call the spec done.
There are other ambiguities and problems. E.g.,
Corman Lisp returns NIL for
(probe-file "C:/Lispcode/")
presumably for the same reason -- it's not a 'file'.
They hyperspec entry for ENSURE-DIRECTORIES-EXIST uses 'file' in the
DESCRIPTION part, but 'file' is not mentioned in the preceding parts.
>The stuff that is there was somewhat untangled from
>CLTL, but it was still far from beaten into anything I'd call reasonable
>shape. And, to be honest, I bet most people weren't able to read the spec
>well enough to really know if they agreed or disagreed with most of the
>stuff there as a consequence. Rather, we used the same reasoning we used
>in many other places: it's no worse than CLTL, and people have gotten by for
>years on what was there... I know, you might wish it was more, but there was
>also value to getting the thing out the door before all Lisp companies
>were bankrupt, too. I think we made the right decision, but I still cringe
>when people try to read this and a few other sections like as if we meant
>what we wrote....
>
>I'd rather see implementations do something reasonable and willfully divergent
>than something that's slavishly adherent and conceptually wrong in the cases
>where the situation is borderline and even a feeble argument can be made for
>it, as is the case here, I think...
>
I don't know how many other ambiguities and errors there are in the
hyperspec, but it would seem like a reasonable idea to create
something containing errata and notes; maybe an online document that
anyone could add to. If there were an issue, such as what should
DIRECTORY do in the case we are discussing, then it might be possible
to reach a consensus even if the hyperspec needs to be contradicted.
>
>I think it should return the subdirs. Otherwise, how do you recurse down
>the file tree?
There is no obvious way that I know of in Corman Lisp to recurse down
the file tree, except by using the internals of DIRECTORY to write
your own.
Corman Lisp provides a DIRECTORY-P function, but nothing to list
subdirectories that I am aware of.
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> writes:
>
> > Barry Fishman <barry_...@acm.org> writes:
> >
> >> I must admit I have problems understanding Common Lisp's PATHNAME
> >> approach, at least having come from Unix and VMS.
>
> .....
>
> > That's not to say it can't be done in an object-oriented fashion with
> > defined protocols for extension--it's only to say that if you saw the
> > protocols for extension, you'd instead be whining about how some of them
> > seem unnecessary, I bet, since your message has a very Unix-centric bias
> > showing in it, whether intended or not.
>
> Thinking that object-oriented design requires extension protocols
> shows a very lisp-centric bias. :)
I don't think that at all. To me "object-oriented" design means "identity
matters", nothing more. Maclisp had no extension capability and was
object-oriented.
> Can't expressing something from a particular point of view be just a
> way of supplying some context to explore the implications of an idea.
> It does not mean that one is unable to accept (or understand) a
> response which uses a different context. In fact, isn't this a usual
> way to explain something?
I'm not sure your point here. But if I sounded defensive it was
because your message had a very critical tone. It didn't seem to be
exploring an idea, it seemed to be condemning a design while at the
same time not acknowledging the intent of that design. The dominant
file systems at the time the design was done were TOPS-10, TENEX,
TOPS-20, VAX VMS, AT&T Unix, MIT Multics, MIT ITS, not to mention a
bunch of mainframe OS's. Some were uppercase only, some mixed, some
were case-sensitive but case-translating (like CL). Some had dirs as
files, some not. Some had quote chars for funny file chars, some not.
Some had wildcards, some didn't. Some had :up in relative pathnames,
some didn't. Some had namable root dirs, some didn't. There were file
systems with no directories, file systems with non-hierarchical
directories, file systems with no file types, file systems with no
versions, file systems with no devices, and so on. People often
critique the design now because Unix and Mac and DOS are so
comparatively similar (compared to some of those others)... One can't
pick any single feature and say "this should obviously have been done
differently" without seeing the magnitude of the problem facing us and
understanding that every decision was a gamble and we were seeking a
middle ground. All in all, I feel we did well, even if I personally
would have included more from the LispM; I can respect why we didn't.
> I was really looking for some examples or pointers to technical
> papers which explored the design decisions that were made.
You didn't say that. I don't know that there are any. But you'd get
better answers if you asked the questions you have directly instead of
making guesses and critiquing the decision quality based on your guesses.
> I still am.
I and others would be willing to field your questions. I doubt there
are things for you to read other than the actual mail that went back and
forth, but that's very unsorted and I don't know that it's public.
> I'm sorry if you felt I was expressing arrogance, but how else
> could I focus on what precise issues I didn't understand?
When you don't understand something, you could start by asking. I don't
think anyone minds you saying "this is a problem". We all agree there are
problems and we can help you constructively work around the problems.
But your message seemed focused not on "I need to do x" or "I wonder why
y was done." but "It looks to me like z was done wrong because it looks to
me like ...." You're welcome to begin any way you like; it's an open forum.
But if you get jumped on, you might look to how you opened...
> Just asking
> a general question would give you no indication of what my confusion
> was. I can get the answers to general questions elsewhere.
Speaking only for myself, I have no ego in the design per se. I'm always
open to understanding what people don't like. But that you don't like it
doesn't mean it was a bad decision, if you get what I mean.
> I do sense from your text a sensitivity, which I find a bit alarming,
> although typical in this group. If this involved young college
> students rather than people who are well known for their
> contributions, I don't think I would be as disturbed.
I've tried to explain the nature of the issue.
Your questions made ok sense, but this paragraph was far from just
exploring issues. It went far beyond asking questions into making
assertions about what people two decades ago could have done while
at the same time admitting you have no idea what facts went into the
situation. It ends up by saying "the authors seem to have taken a guess"
and I find that personally insulting. I thought my remarks were appropriate
to your opening.
| Common Lisp could have used CLOS to provide a much more general file
| interface, with a much simpler set of common functions (and a more
| documented interface for each file system), or it could have just
| avoided the issue and used filesystem specific strings to represent
| file names. Instead the authors seemd to have taken a guess, (maybe
| based on lisp machines of which I am not familiar),
> It's hard to tell just by looking at their text how people really
> feel. I know when I worked as a research assistant, it was common to
> tell a fellow programmer things like, "Lets see if you have a brain,"
> without meaning any malice. It was just a sarcastic way to help
> us separate a possibly heated technical discussion from our personal
> feelings about each other. This does not transfer to text very well.
> But too apologetic text does become quite sickening.
>
> I guess I'll just go elsewhere for information.
I'm still happy to answer questions, and I suspect others here are as well.
Just please dispense with the insulting parts and the speculation in the
absence of data, and stick to the parts more like the earlier paragraphs
which merely observe legitimate truths and questions about the present-day
state.
Or just ignore me and wait for someone else to reply. I'm just one person.
I'm as easy to killfile as the next if you continue to feel, after this
explanation, that my response was out of line.
Kent M Pitman
[discussion of "http://foo.com/bar" vs "http://foo.com/bar/"]
> I *think* that's a bug in the webserver.
Yeah, I'm sure it is. But only a Unix programmer would have tolerated it.
I reported the bug to the Unix guys maintaining the server and they couldn't
understand why I thought it was a bug. They said I should add a META BASE=
thing, but the problem with that is that I can't test it out on my local
file system before publishing if I do that...
My ultimate fix was to advertise http://world.std.com/~pitman/pitman.html
(which is just a link to index.html) because people feel it's less omittable.
When I was saying index.html, they kept leaving it out, and then they'd leave
out the /, and then my page wouldn't work, and then I'd get bug reports.
Sigh.
Kent M Pitman
> Where Common Lisp pathnames fall down is with regards to the
> spectacularly misnamed ``common case.'' There's nothing common about
> it, and it's a disaster in cross platform environments.
First, it doesn't purport to be "commonplace". It contrasts LOCAL
where the host implementation defines the meaning of a case choice; in
COMMON case, COMMON lisp defines the case choice. (There was also in
CLTL a COMMON datatype, which has thankfully atrophied. But you can
be sure we never meant it to select the datatypes that were common
outside of Lisp.)
Second, at the time CL was standardized TOPS-20 and VAX VMS were two
very big platforms used by Lisp programmers. Both used uppercase by
default.
Third, if you think it's a disaster in cross-platform environments,
you're probably confused about how to use it. In my experience, it makes
cross-platform work easier, not harder. I use it exclusively.
I think we should have made :case :common the default, because sometimes
people forget to supply it and that DOES create problems (e.g., if it's not
used uniformly).
We *could* have made it be lowercase rather than upper (though that would
have gone against the status quo of the time), but if we had, most people
would probably not be caused to ask "what does this mean". They probably
would instead be saying "what's the difference between :case :common
and :case :local?", or worse, making assumptions about them being the same
and using them interchangeably not realizing what they were for.
Roger Corman
>
>There is no obvious way that I know of in Corman Lisp to recurse down
>the file tree, except by using the internals of DIRECTORY to write
>your own.
>
Well it may not be obvious but there is now a :RECURSE keyword on the DIRECTORY
command (a non-standard enhancement) which will recurse the tree and returns
files from subdirectories as nested lists.
Roger
JP Massar
wrote:
Right. I even knew that, if not consciously when I wrote the above.
Sorry for the non-clear statement.
The 'problem' is that it seems reasonable to want to get at the
subdirectories themselves; not just the files they contain.
Suppose I wanted to make a map of the directory structure. If I had
directories that contained no files, only containing subdirectories
which also contained no files, the DIRECTORY function will give me
no indication that this structure exists. And if the subdirectories
do contain files I can only understand the directory structure by
doing additional parsing on the pathnames that are returned.
Or maybe I only want to recurse into subdirectories conditionally or
to a certain depth. I can't do that, as far as I know, since I can't
control the recursion.
BTW, I think that returning nested lists is not santioned by the
hyperspec, but it's not clear what happens to the definition of the
return value if you allow additional keywords with unspecified
semantics, as is allowed in regard to DIRECTORY.
Kent M Pitman
> The 'problem' is that it seems reasonable to want to get at the
> subdirectories themselves; not just the files they contain.
The dir listing stuff we have is certainly just a placeholder. Vendors
are intended to experiment with extensions. The &key is a hint of this.
An additional problem, if you're looking for nits to pick, is that it
makes you get all the files at once. If I recall, TOPS-20 had a
facility which was the file system analog of WITH-HASH-TABLE-ITERATOR
or WITH-PACKAGE-ITERATOR; that is, it allowed you to get a function
that would get the "next" in a series. This kept you from listing lots
of files you didn't care about. I mention this in this context partly
because this desire to go slowly is often very important when going
vertically in the file system (down into subdirs), not just horizontally
(enumerating an "exact" dir's contents).
Paolo Amoroso
wrote:
> Here you are definitely wrong. The CL pathname system was based on
> the Lisp Machine pathname system, mostly by taking about half of the
> functionality already present on the LispM because people felt that
> "not taking everything" showed "good conservativism". I think this
Weren't Lisp Machines relatively mature when the work on ANSI Common Lisp
began?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Kent M Pitman
> On Sat, 6 Oct 2001 19:36:02 GMT, Kent M Pitman <pit...@world.std.com>
> wrote:
>
> > Here you are definitely wrong. The CL pathname system was based on
> > the Lisp Machine pathname system, mostly by taking about half of the
> > functionality already present on the LispM because people felt that
> > "not taking everything" showed "good conservativism". I think this
>
> Weren't Lisp Machines relatively mature when the work on ANSI Common Lisp
> began?
Yes.
But
NIH.
:-(
Marco Antoniotti
Tim Bradshaw <t...@cley.com> writes:
I have given a lot of thought to this issue (in conjunction to
MK:DEFSYSTEM) and came to the conclusion that working with strings to
deal with pathnames evntually leads you into waters too murky.
The above code should be treated as
(let* ((pd1 (parse-namestring d1))
(pd2 (parse-namestring d2))
(pd1-dir (pathname-directory pd1))
(pd2-dir (pathname-directory pd2))
)
(if (and pd2-dir
(not (eq pd2-dir :unspecific))
(eq (first pd2-dir) :absolute))
pd2
(merge-pathnames
(make-pathname :directory (append pd1-dir
(rest pd2-dir)))
pd2)))
The code is ntested and it obviously leaves something to be desired
(device, hosts, no check on pd1-dir ect, etc).
But it is much more robust than just munging the strings and more
portable as well.
Cheers
Tim Bradshaw
> I'd like to be enlightened. In all the cross platform environments I've
> worked in, files are called what they are called. They do _not_ change
> names when I access them from another operating system or Lisp. I'm using
> CVS these days, but that was the case with clearcase and AFS providing the
> backing store too.
My experience of cross-platform working with windows/Unix is that case
is a seething nightmare. Files are not called what they are called,
they're called some weird case-mangled version of what they are
called, which depends on exactly which version of the myriad
windows/Unix file sharing products you use, and which of the myriad
switches you have set in the product you're using. Clearcase, for
instance, requires some fairly non-default settings for Unix servers /
Windows clients, because it's really a Unix product and has Unix
requirements for case-sensitivity.
--tim
Tim Bradshaw
> I have given a lot of thought to this issue (in conjunction to
> MK:DEFSYSTEM) and came to the conclusion that working with strings to
> deal with pathnames evntually leads you into waters too murky.
I agree absolutely. Lack of any standard structured path
interface is one of the more braindamaged bits of the standard Unix
API.
--tim
Kent M Pitman
> I'd like to be enlightened. In all the cross platform environments I've
> worked in, files are called what they are called. They do _not_ change
> names when I access them from another operating system or Lisp. I'm using
> CVS these days, but that was the case with clearcase and AFS providing the
> backing store too. Granted that UNIX, MacOS and all recent versions of
> Windows differ from VMS is the way they deal with pathname components in
> that VMS was versioned. But the issue is that what I want is to be able to
> use the same strings in defaults to describe the same names in the
> filesystem. Common case works actively to defeat this.
>
> For example, I fail to see how having:
>
> (ed (make-pathname :name "foo" :type "lisp" :host "louis" :directory
> '(:absolute "louis" "EKSL" "junk")))
>
> try to edit a file called
>
> /users/theran/eksl/JUNK/FOO.LISP
>
> on a UNIX system is helpful.
It doesn't. It edits
/louis/EKSL/junk/foo.lisp
on host louis because the default :case is :local, which uses your
components exactly as given. If you *had* supplied common case, it
would edit:
/LOUIS/eksl/JUNK/FOO.LISP
because common case uses uppercase for the "natural case" and lowercase
for the "unnatural" case. The idea behind case common is so you can
do something like creating "foo.lisp" in the right case (which might be
FOO.LISP or might be foo.lisp, depending on OS). If your dataflow
comes from a user familiar with the local file system, you should be using
:case :local. If your dataflow comes froma Common Lisp programmer who
wants to be portable and make files in the natural case of any operating
system, they sould be using :case :common and they should be
specifying:
(ed (make-pathname :name "FOO" :type "LISP" :host "LOUIS"
:directory '(:absolute "LOUIS" "EKSL" "JUNK")))
so that they get either
/louis/eksl/junk/foo.lisp [unix]
or <LOUIS.EKSL.JUNK>FOO.LISP [tops-20]
Note that TOPS-20 *does* have a little-known escape convention with
control-v allowing the next character to be quoted, so if you'd just
used a literal string it would have come out like this on Tops-20 if
you'd made it use the string that literally works for unix:
<^Vl^Vo^Vu^Vi^Vs.^Ve^Vk^Vs^Vl.^Vj^Vu^Vn^Vk>^Vf^Vo^Vo.^Vl^Vi^Vs^Vp [tops-20]
If you'd made the string acceptable for TOPS-20, it would have been awful
on Unix. So we made common case and we created the "natural/unnatural"
distinction. You're always welcome to use :case :local and you'll get
exactly what you type. I simply don't see how you can regard this as a
problem when it only offers you flexibility.
You might not think that these file systems are worth supporting,
but the fact that it would end up this way was not known at the time
we standardized. And we did the design so that it would stand the test
of time, no matter which way things went. Uppercase means pick "the
natural case" and lowercase means pick "not the natural case". Mixed is
left alone. The reason you might want to pick "not the natural case"
is if you're compiling a temp file. I use this idiom all the time:
(make-pathname :name "_temp" :type "LISP"
:case :common :defaults input-filename)
in order to try to get "_TEMP" on unix and "_temp" on any file systems that
use uppercase as natural but offer me a lowercase alternative.
Now, the place you may run into trouble if you're not careful is:
(make-pathname :name "FOO" :type (pathname-type other-pathname)
:defaults whatever :case :common)
This will produce bizarre results; you should instead do:
(make-pathname :name "FOO" :type (pathname-type other-pathname :case :common)
:defaults whatever :case :common)
to make sure that you are both reading and storing in the same mode.
Otherwise, you will flip the case accidentally. Or, you can omit :case :common
in both cases and you'll also be fine (though it sounds like you like lowercase
filenames, so you'll want to lowercase the "FOO" in that case). Consistency
reigns.
> This is what we'd have if common case was the
> default.
> Logical pathnames also hijack the string "LISP" in the type
> component, so presumably there's no way to get the string "lisp" if the
> implementor likes "cl" or "lsp" better and you are using common case.
Now you've switched to talking about logical pathnames, which is an utterly
different issue. But this is between you and your vendor, since the vendor
makes the decision of how to do this translation. The function of logical
pathnames is not to force vendors to use the same name if they don't want
to (since at the time, some file systems had only 3-letter extensions and
"lisp" wans't possible some places); using logical pathnames papers over
this.
> > We *could* have made it be lowercase rather than upper (though that would
> > have gone against the status quo of the time), but if we had, most people
> > would probably not be caused to ask "what does this mean". They probably
> > would instead be saying "what's the difference between :case :common
> > and :case :local?", or worse, making assumptions about them being the same
> > and using them interchangeably not realizing what they were for.
>
> Users should not have to perform exegesis on a spec every time they consult
> it. What you've given me here is a Talmudic analysis of common case, but
> you still haven't convinced me that it's useful.
Users shouldn't assume the spec is a user document. A lot of the time it
suffices as such, but that is beyond the scope of its purpose. Criticizing
the language on the basis of its value as a teaching document is
extraordinarily unfair. Some languages have specs that are not even readable
but are written in formalese. We could have done that, but we made it so
approachable that you were able to make this confusion; I'd say that was
pretty darned helpful. I'm sorry that sometimes that luxury gets you into
trouble but you have only yourself to blame for it.
Pekka P. Pirinen
> > * Barry Fishman wrote:
> > > Several applications (most notably emacs)
> > > seems to feel they are doing the user a favor by adding a slash,
>
> MK:DEFSYSTEM) and came to the conclusion that working with strings to
> deal with pathnames evntually leads you into waters too murky.
>
> The above code should be treated as
> (let* ((pd1 (parse-namestring d1))
> (pd2 (parse-namestring d2))
That approach is much better. However, if D1 and D2 were input by a
user as directory names, we shouldn't parse them as file namestrings.
In particular, no significance should be attached to a trailing
directory separator or lack thereof. It's really not nice to just
drop the last directory component. Which sort of leaves us where we
started.
> (if (and pd2-dir
> (not (eq pd2-dir :unspecific))
> (eq (first pd2-dir) :absolute))
If this is from unchecked user input, I suppose there could be a :WILD
in there as well. But of course this was just untested example code.
I don't believe one can write strictly portable pathname code, but I
suppose with some care, one can write code that works on several
platforms and implementations in practice.
--
Pekka P. Pirinen
The gap between theory and practice is bigger in theory than in practice.
Marco Antoniotti
Pekka.P...@globalgraphics.com (Pekka P. Pirinen) writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
> > > * Barry Fishman wrote:
> > > > Several applications (most notably emacs)
> > > > seems to feel they are doing the user a favor by adding a slash,
> >
> > I have given a lot of thought to this issue (in conjunction to
> > MK:DEFSYSTEM) and came to the conclusion that working with strings to
> > deal with pathnames evntually leads you into waters too murky.
> >
> > The above code should be treated as
> > (let* ((pd1 (parse-namestring d1))
> > (pd2 (parse-namestring d2))
>
> That approach is much better. However, if D1 and D2 were input by a
> user as directory names, we shouldn't parse them as file namestrings.
> In particular, no significance should be attached to a trailing
> directory separator or lack thereof.
I am not sure I agree here.
> It's really not nice to just
> drop the last directory component. Which sort of leaves us where we
> started.
>
> > (if (and pd2-dir
> > (not (eq pd2-dir :unspecific))
> > (eq (first pd2-dir) :absolute))
>
> If this is from unchecked user input, I suppose there could be a :WILD
> in there as well. But of course this was just untested example code.
Yes.
> I don't believe one can write strictly portable pathname code, but I
> suppose with some care, one can write code that works on several
> platforms and implementations in practice.
I agree. In the above case, in the case of "user input", you must
resort to extra checking: i.e. you must go and see what you have on
the spinning disks (or in the isolinear chips in the case of Star
Trek) before you can interpret the parsed namestrings.
When and how you check this is a problem of the application. If the
application expects a "directory" and it is supplied something that
parsed as a "filename", somewhere along the path you must signal a
condition. Everything boils down to when and how the condition is
signalled.
j...@itasoftware.com
> > > > > Several applications (most notably emacs)
> > > > > seems to feel they are doing the user a favor by adding a slash,
(This in the context that the user asked for directory "~/foo" and got
back "~/foo/")
The problem is that Unix has a fundamental ambiguity. There is no
canonical way to differentiate between the mapping of "foo" to a
directory object and the contents of that directory object itself.
This is further complicated by the fact that it is convenient to use
partial pathnames. The problem is exacerbated by the myriad of
utilities that interpret partial paths in different ways.
I favor a system that seems similar to what Kent described: if you
are talking about a directory, you use the trailing slash.
> > Marco Antoniotti <mar...@cs.nyu.edu> writes:
> > >
> > > I have given a lot of thought to this issue (in conjunction to
> > > MK:DEFSYSTEM) and came to the conclusion that working with strings to
> > > deal with pathnames evntually leads you into waters too murky.
I don't know if I'd say *too* murky, but I agree. This is especially
true if you have to interface to utilities that attempt to `dwim' the
pathname. My favorite: the JVM on Unix. When referring to a
directory, you *must not* have a trailing slash on the name, *except*
if you are referring to the root directory, in which case it *must*
have that slash.
> Pekka.P...@globalgraphics.com (Pekka P. Pirinen) writes:
>
> > That approach is much better. However, if D1 and D2 were input by a
> > user as directory names, we shouldn't parse them as file namestrings.
> > In particular, no significance should be attached to a trailing
> > directory separator or lack thereof.
I either don't understand or I don't agree. If the user has a
mechanism to indicate that something is supposed to name a directory,
then you definitely shouldn't try to treat it as a file, and vice
versa. But attaching a trailing directory separator is an unambiguous
way of distinguishing between the two, so it is quite significant.
> Pekka.P...@globalgraphics.com (Pekka P. Pirinen) writes:
>
> > I don't believe one can write strictly portable pathname code, but I
> > suppose with some care, one can write code that works on several
> > platforms and implementations in practice.
Marco Antoniotti <mar...@cs.nyu.edu> writes:
> I agree. In the above case, in the case of "user input", you must
> resort to extra checking: i.e. you must go and see what you have on
> the spinning disks (or in the isolinear chips in the case of Star
> Trek) before you can interpret the parsed namestrings.
And this is where the problem lies. What if are attempting to parse a
namestring of an object (file or directory) that doesn't exist?
There's no help on the spinning disk (perhaps the Heisenberg
compensators?)
> When and how you check this is a problem of the application. If the
> application expects a "directory" and it is supplied something that
> parsed as a "filename", somewhere along the path you must signal a
> condition. Everything boils down to when and how the condition is
> signalled.
Signalling a condition is not the Unix way, though. You should either
simply exit with no indication whatsoever of why, or make a random
undocumented choice as to how to parse it, or throw in a few extra
slashes `just in case', or simply unconditionally delete whatever is
in the way.
Kent M Pitman
> Signalling a condition is not the Unix way, though. You should either
> simply exit with no indication whatsoever of why, or make a random
> undocumented choice as to how to parse it, or throw in a few extra
> slashes `just in case', or simply unconditionally delete whatever is
> in the way.
This is great stuff. If the rest of Unix could be described so clearly it
would make a great book.
Raymond Toy
Kent> j...@itasoftware.com writes:
>> Signalling a condition is not the Unix way, though. You should either
>> simply exit with no indication whatsoever of why, or make a random
>> undocumented choice as to how to parse it, or throw in a few extra
>> slashes `just in case', or simply unconditionally delete whatever is
>> in the way.
Kent> This is great stuff. If the rest of Unix could be described so clearly it
Kent> would make a great book.
Isn't that what the "Unix Haters" book is? Don't have a copy but read
some items. Quite funny (and sad).
Ray
Daniel Barlow
> Signalling a condition is not the Unix way, though. You should either
> simply exit with no indication whatsoever of why, or make a random
> undocumented choice as to how to parse it, or throw in a few extra
> slashes `just in case', or simply unconditionally delete whatever is
> in the way.
For extra marks, additionally choose n from
- log to syslog (but don't document the facility or level that you
use)
With any luck, no message will appear because on some past occasion
/var filled up and syslogd hasn't been restarted since, so silently
loses the message. Even if it is working normally, the only way to
find out where it went is by looking at the mtime of all the files in
/var/log
- dump core
In a random directory where nobody will ever find the file.
Suggestions: /var/lock, /var/spool/mail, or create a directory ~/.foo
and leave it there
- hang indefinitely
Suggested approach: walk the directory tree around the location of
your application binary and hope there's a nfs mount to an
unavailable host. If that doesn't work, try to save all your data
files as well. Eventually you'll get one.
- hang for three minutes, timeout and choose another of the above
Nameserver lookups are a good way to do this. You needed the machine
hostname so that you could print a slightly prettier error message,
right? The timeout will also give you a new error, which is ideal for
finding out whether your error handling code is reentrant, and fix it
if so.
- complain that something failed because "No such file or directory"
"something" will turn out to be the optional locale-dependent message
catalog file for your application, which isn't installed because
nobody's written it (UK English and US English are similar enough that
nobody's going to) and would usually silently fall back to the US
version, but because this is an error situation we happen to check
"errno", and that was the last system call that happened.
- generate big pixmaps and cause the X server to allocate vast amounts
of swap
This will force the user to restart X to get the memory back, at which
point they've lost all their state and usually might as well have
rebooted anyway
Overall guiding principle: it should be possible to leverage any small
error into a much bigger one which will technically not require
rebooting (stability is measured by uptime, so it is important that we
never reboot) but will leave the machine crippled enough that the user
might as well have rebooted anyway - and saved themself the 15 minutes
of logging in remotely, mucking about with strace(1) and looking
through process lists and wondering whether killing
in.rpc.kfamgnome-portservd is (a) possible, (b) at all likely to help
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
j...@itasoftware.com
> j...@itasoftware.com writes:
>
> > Signalling a condition is not the Unix way, though....
>
Daniel Barlow <d...@telent.net> writes:
> For extra marks, additionally choose n from
>
> [Other good ideas elided]
> - complain that something failed because "No such file or directory"
Too friendly. If you are going to print an error message, it
shouldn't provide real information, only the illusion thereof.
Something like ``invalid argument'', ``not a typewriter'', ``cannot
make directory: not a directory'', ``?'', ``where are you?''
Lieven Marchand
I suspect you have been trolled.
Off course, nowadays Unix is kind of usable and management pressures
most people to use the abomination from Redmond.
Anyone game for a Windows-haters list?
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Raymond Toy
Lieven> Raymond Toy <t...@rtp.ericsson.se> writes:
>> >>>>> "Kent" == Kent M Pitman <pit...@world.std.com> writes:
>>
Kent> j...@itasoftware.com writes:
>> >> Signalling a condition is not the Unix way, though. You should either
>> >> simply exit with no indication whatsoever of why, or make a random
>> >> undocumented choice as to how to parse it, or throw in a few extra
>> >> slashes `just in case', or simply unconditionally delete whatever is
>> >> in the way.
>>
Kent> This is great stuff. If the rest of Unix could be described so clearly it
Kent> would make a great book.
>>
>> Isn't that what the "Unix Haters" book is? Don't have a copy but read
>> some items. Quite funny (and sad).
Lieven> I suspect you have been trolled.
In what way? (Assuming you're responding to me.)
Lieven> Off course, nowadays Unix is kind of usable and management
Lieven> pressures most people to use the abomination from Redmond.
While I don't have the book, I think a lot of the things in that book
still true.
Ray
j...@itasoftware.com
> Of course, nowadays Unix is kind of usable and management pressures
> most people to use the abomination from Redmond.
I think you may have lowered your standards. Unix isn't *that* much
better than it used to be, but there is nothing to compare it with
anymore.
Fred Gilham
> Anyone game for a Windows-haters list?
With considerable fear and trembling, I post the following link:
http://geraldholmes.freeyellow.com/
--
Fred Gilham gil...@csl.sri.com
I was storing data in every conceivable way, including keeping a chain
of sound waves running between the speaker and the microphone. There
was no more memory left to be had....
Lieven Marchand
That's more or less what I meant. It isn't my favourite operating
system but it's the best I can get.
Lieven Marchand
> >>>>> "Lieven" == Lieven Marchand <m...@wyrd.be> writes:
>
> Lieven> Raymond Toy <t...@rtp.ericsson.se> writes:
> >> >>>>> "Kent" == Kent M Pitman <pit...@world.std.com> writes:
> >>
> Kent> j...@itasoftware.com writes:
> >> >> Signalling a condition is not the Unix way, though. You should either
> >> >> simply exit with no indication whatsoever of why, or make a random
> >> >> undocumented choice as to how to parse it, or throw in a few extra
> >> >> slashes `just in case', or simply unconditionally delete whatever is
> >> >> in the way.
> >>
> Kent> This is great stuff. If the rest of Unix could be described so clearly it
> Kent> would make a great book.
> >>
> >> Isn't that what the "Unix Haters" book is? Don't have a copy but read
> >> some items. Quite funny (and sad).
>
> Lieven> I suspect you have been trolled.
>
> In what way? (Assuming you're responding to me.)
I think Kent was aware of the existence of the "Unix Haters" book
since a lot of the content originated with the MIT ITS/Lisp crowd.
>
> Lieven> Off course, nowadays Unix is kind of usable and management
> Lieven> pressures most people to use the abomination from Redmond.
>
> While I don't have the book, I think a lot of the things in that book
> still true.
They're practically all still true, only the current mainstream stuff
is so much worse that it makes Unix a paragon of usability. Compare
the rant about Unix simply terminating your program in the case of an
error whilst printing an errno explanation and leaving a core
file. The Redmond crawling horror doesn't bother telling the user what
went wrong out of fear of confusing him but just says "Illegal
operation" and gives you a checkbox with the options "Crash now" or
"Crash later". And you don't get a core file to check what was wrong.
Kent M Pitman
> I think Kent was aware of the existence of the "Unix Haters" book
> since a lot of the content originated with the MIT ITS/Lisp crowd.
Yes, I was on the Unix-Haters e-mail list that led to the book, and am
aware of the book. I think it was Alan Bawden (who I think invented the
version of backquote we use in CL today) who ran the mailing list,
ruthlessly excising people from the list if they ever said anything that
could even possibly be construed as a kind word about Unix; total vitriol
was a requirement if you wanted to stay subscribed. ;-)
But my remark was serious in that I recall it as somewhat user-centric,
people whining about how it was to USE Unix. If my memory on that point
is correct, another book from the cynical angle of "helping" an
IMPLEMENTOR build other things LIKE unix might be a big hit, too.
Then again, maybe not. What do I know? Not like we all don't have better
things to do be doing, but...
James A. Crippen
My personal favorite crash is exemplified by Nutscrape, which will
lose its entire user interface but keep a few child processes running
until time_t rolls over. Actually crashing and dumping core would be
too easy, much better to subtly mangle the system by filling up the
process table or eating up all of swap through some memory cancer.
And make sure to write a lock file that only gets deleted if the
program exits normally. This encourages the user to hunt for the lock
file so they can delete it. But of course they can't delete it
because the program that crashed was setuid root and the lock file was
written as root in /var/run with 1755 permissions (the execute and
sticky bits were overloaded to mean something else, naturally). The
*correct* way to clean up the lock file turd is to run the appropriate
control program which knows how to speak some randomly defined
protocol down a FIFO that was created in
/tmp/.foo/\#\@\\\\*&%\$unprintable/^HBAR and then issue seventeen
cryptic one and two letter commands to get the application's
background cruft daemon to delete the lock with root permissions, but
then to actually kill the application you have to reinstate the lock
file as a symbolic link to nowhere so the control program can kill the
background daemon, which will then send SIGTHTBABW to the application
program, which since it's already totally mangled its stack will
finally crash and dump core on calling exit(). But of course the core
will be useless since it got as far as trying to call exit() before it
died, so the state that caused the original lossage is long since
lost.
'james
--
James A. Crippen <ja...@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
Greg Menke
> cryptic one and two letter commands to get the application's
> background cruft daemon to delete the lock with root permissions, but
Is a background cruft daemon the kind of thing that spawns off nasal
daemons?
Gregm
Ingvar Mattsson
> * Barry Fishman wrote:
> > Several applications (most notably emacs)
> > seems to feel they are doing the user a favor by adding a slash, but
> > this only complicates code which now needs to test for and remove
> > slashes when constructing file paths by concatenation.
>
> Can you give an example of this? It seems to me that if I want to
> concatenate two directories D1 and D2 then (assuming trailing slashes)
> the algorithm is:
>
> (if (char= (aref d2 0) #\/)
> ;; D2 is absolute
> d2
> (concatenate 'string d1 d2))
And the effort spent in squishing slashes is, eh, rather mis-spent
since in (at least most, if not all) unixes you can access a file with
multiple slashes without a problem.
//Ingvar
--
(defmacro fakelambda (args &body body)
`(lambda ,args (labels ((me ,args ,@body)) (me ,@args))))
(funcall (fakelambda (a b) (if (zerop (length a)) b (format nil "~a~a"
(aref a 0) (me b (subseq a 1))))) "Js nte iphce" "utaohrls akr")
Lieven Marchand
> But my remark was serious in that I recall it as somewhat user-centric,
> people whining about how it was to USE Unix.
There are 3 major parts, (1) using Unix, (2) programming it and (3)
sysadminning it.
> If my memory on that point is correct, another book from the cynical
> angle of "helping" an IMPLEMENTOR build other things LIKE unix might
> be a big hit, too.
But Unix is simple to implement. See "Worse is better". The Lions book
can be read in a few sittings, and even a literate style presentation
of a more useable version like Linux 0.99.x wouldn't be larger than
"TeX, the program".
Tim Bradshaw
>
> But Unix is simple to implement. See "Worse is better". The Lions book
> can be read in a few sittings, and even a literate style presentation
> of a more useable version like Linux 0.99.x wouldn't be larger than
> "TeX, the program".
>
Including all the utilities, not just the kernel? I don't think a Unix kernel
is Unix.
(and do the utilities include TeX?)
--tim
cbbr...@acm.org
> Lieven Marchand <m...@wyrd.be> writes:
> > But Unix is simple to implement. See "Worse is better". The Lions
> > book can be read in a few sittings, and even a literate style
> > presentation of a more useable version like Linux 0.99.x wouldn't
> > be larger than "TeX, the program".
> Including all the utilities, not just the kernel? I don't think a
> Unix kernel is Unix.
Indeed. The thing people tend not to understand is that for something
to be "Unix," it has to have init running, and then a hierarchy of
shells and ttys and such running on top of that.
It definitely is a bit nebulous just where it should be rightly
considered that the system stops.
[Of course, if you limit things to the kernel, that would make it
quite practical to use something like Linux as kernel, and build up
user space as Lisp; the projects to build "Lisp OSes" have tended to
fail due to not having enough Kernel hackers, which would be nicely
resolved by using this principle...]
> (and do the utilities include TeX?)
(well, in the "GNU's Not Unix" perspective, yes...)
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.cbbrowne.com/info/lsf.html
"Why use Windows, since there is a door?"
-- <fac...@galileo.rhein-neckar.de> Andre Fachat
Lieven Marchand
> Lieven Marchand <m...@wyrd.be> writes:
>
> >
> > But Unix is simple to implement. See "Worse is better". The Lions book
> > can be read in a few sittings, and even a literate style presentation
> > of a more useable version like Linux 0.99.x wouldn't be larger than
> > "TeX, the program".
> >
>
> Including all the utilities, not just the kernel? I don't think a Unix kernel
> is Unix.
Only the kernel of course. A lot of the utilities have been ported to
other operating systems.
> (and do the utilities include TeX?)
TeX was originally not written on or for Unix.
Tim Bradshaw
>
> Only the kernel of course. A lot of the utilities have been ported to
> other operating systems.
>
Well, then yes, of course, it's quite easy to implement something
which does nothing useful. I do that every day!
>
> TeX was originally not written on or for Unix.
>
I think you missed the joke...
--tim
Rob Warnock
+---------------
| And the effort spent in squishing slashes is, eh, rather mis-spent
| since in (at least most, if not all) unixes you can access a file with
| multiple slashes without a problem.
Indeed. *Including* trailing slashes for plain files, too:
% ls -l foo
-rw-r--r-- 1 rpw3 engr 27 Oct 27 20:18 foo
% cat foo
This is a plain text file.
% cat foo/
This is a plain text file.
% pwd
/u/rpw3
% cat ///u///..///u///.///rpw3///.///.///foo///
This is a plain text file.
%
-Rob
-----
Rob Warnock, 30-3-510 <rp...@sgi.com>
SGI Network Engineering <http://www.meer.net/~rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]
Barry Fishman
> Ingvar Mattsson <ing...@cathouse.bofh.se> wrote:
> +---------------
> | And the effort spent in squishing slashes is, eh, rather mis-spent
> | since in (at least most, if not all) unixes you can access a file with
> | multiple slashes without a problem.
> +---------------
>
> Indeed. *Including* trailing slashes for plain files, too:
>
> % ls -l foo
> -rw-r--r-- 1 rpw3 engr 27 Oct 27 20:18 foo
> % cat foo
> This is a plain text file.
> % cat foo/
> This is a plain text file.
> % pwd
> /u/rpw3
> % cat ///u///..///u///.///rpw3///.///.///foo///
> This is a plain text file.
> %
Section 2.2.2.121 of POSIX Part-2 Shell and Utilities indicates that
multiple slashes between components of a path are to be treated as if
there was a single slash, and one or more slashes are permitted at the
trailing end of a *directory* path.
Slashes at ends of simple file names are not considered.
For GNU utilties (Under SUSE Linux)
% cat foo/
cat: foo/: Not a directory
Regularizing paths is not a matter of cleaning up the syntax for the
computer, but making things clearer to the human reading the code, and
any error messages.
Kent M Pitman
Heh. And I bet it's the community that tolerates all of those /'s in the
manner that Rob cites that is always saying to the other "you guys use too
many /'s" just as people always say of Lisp "you guys use too many parens".
When in fact, it's non-Lispers that generate the FAQ-inducing questions like
"why does (+ (3) ((+ 4 5))) blow up?" after using twice as many parens as
any Lisper would use. (Almost) paradoxically, it's the toleration of extra
notational devices like that that steals meaning from them. Lispers never
put "too many" parens because that's not allowed; only people who assign no
serious meaning to parens can put too many, since only if they mean nothing
(or nearly nothing) does it make sense to cake them on thick.
It's a shame that extra /'s are tolerated as they are. It must hide all
kinds of program errors that really ought to be fixed.
Barry Fishman
> Barry Fishman <barry_...@acm.org> writes:
>> Section 2.2.2.121 of POSIX Part-2 Shell and Utilities indicates that
>> multiple slashes between components of a path are to be treated as if
>> there was a single slash, and one or more slashes are permitted at the
>> trailing end of a *directory* path.
>>
>> Slashes at ends of simple file names are not considered.
> Heh. And I bet it's the community that tolerates all of those /'s in the
> manner that Rob cites that is always saying to the other "you guys use too
> many /'s" just as people always say of Lisp "you guys use too many parens".
> When in fact, it's non-Lispers that generate the FAQ-inducing questions like
> "why does (+ (3) ((+ 4 5))) blow up?" after using twice as many parens as
> any Lisper would use. (Almost) paradoxically, it's the toleration of extra
> notational devices like that that steals meaning from them. Lispers never
> put "too many" parens because that's not allowed; only people who assign no
> serious meaning to parens can put too many, since only if they mean nothing
> (or nearly nothing) does it make sense to cake them on thick.
Multiple paran have a separate and important meaning which is basic to
Lisp. I think this is quite different than the / issue.
> It's a shame that extra /'s are tolerated as they are. It must hide all
> kinds of program errors that really ought to be fixed.
I suspect the extra /'s are tolerated partly because people writing
the standard did not want to fix/change all their software. I don't
think it leads to programming errors. Its just an annoyance brought
on by a few people recognizing early on that '//' would be interpreted
as "/./" and they could save a line of code and demonstrate their Unix
prowess at the same time. On 16 bit machines such feats were more
appreciated. Now only some Perl programmers care about it :-)
It is also, probably, related to the long time acceptance of null
entries in PATH to mean the current directory.
I think a closer Lisp situation would be accepting things like:
(cddr '(1))
Is this a programming convenience, or does it indicate a programming
error that really ought to be fixed? (Please don't answer!)
Its just that cdr'ing your way through a nil and parsing your way
through multiple slashes are things which seem wasteful but can reduce
lines of code.
I am not implying one's conclusions about each of them should be the
same.
Barry Fishman
Erik Naggum
| And I bet it's the community that tolerates all of those /'s in the
| manner that Rob cites that is always saying to the other "you guys use
| too many /'s" just as people always say of Lisp "you guys use too many
| notational devices like that that steals meaning from them.
|
| kinds of program errors that really ought to be fixed.
Actually, foo//bar is valid for a very different reason than most people
seem to believe. The empty string was a valid pathname, and it resolved
to the current directory, the same value as ".", except it did not use
consult the inode for ".". The kernel routine "namei" started with this
value and returned it if it got the empty string. foo//bar is processed
the standard way, where the empty string is the current directory as it
in the parsing process. It is quite likely that treating an empty string
as a pathname was a bug that got exploited because of its convenience.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
Kaz Kylheku
> Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
That's an outrage! Should we be expecting the Swiss to retaliate
by banning Norwegian army knives from the streets of Bern?
--
. .
. .
. . <- Mysterious Powdery Substance
.
Raymond Laning
Switzerland...
Erik Naggum
| perhaps carrying concealed lutefisk should carry criminal penalties in
| Switzerland...
Only a small number of people have concealed carry licenses for lutefisk
in Norway. Most counties were "shall issue" before a recent accident
where a taxi driver driver was assaulted with frozen meatloaf, obviously
because the assailant was a law-abiding citizen who did not carry a
pocket knife, but now they are mostly "may issue". The police are in
general quite sympathetic to people who apply for a license to carry
lutefisk for personal or home protection, however. And I bet most of you
furriners thought lutefisk was foodstuff, but it is way more lethal than
you can imagine in the wrong hands!
But seriously, lutefisk just has a seriously bad reputation. It can be
really good if prepared right.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Kaz Kylheku
> But seriously, lutefisk just has a seriously bad reputation. It can be
> really good if prepared right.
That reminds me. Some time ago, I was listening to recordings of some
baroque guitar music played by one Elliot Fisk. I promptly summarized
the experience in two words: ``lute fisk''. :)
Lieven Marchand
> I suspect the extra /'s are tolerated partly because people writing
> the standard did not want to fix/change all their software. I don't
> think it leads to programming errors. Its just an annoyance brought
> on by a few people recognizing early on that '//' would be interpreted
> as "/./" and they could save a line of code and demonstrate their Unix
> prowess at the same time. On 16 bit machines such feats were more
> appreciated. Now only some Perl programmers care about it :-)
If I remember the Posix spec correctly, a leading // indicates entry
in an implementation defined part of the file system. So there is no
guarantee that //etc/hosts is the same as /etc/hosts.
> I think a closer Lisp situation would be accepting things like:
>
> (cddr '(1))
>
> Is this a programming convenience, or does it indicate a programming
> error that really ought to be fixed? (Please don't answer!)
Since CL defines CAR and CDR of NIL to be NIL, CL accepts the above.
It's a programming convenience.
Thomas F. Burdick
> * Raymond Laning
> | perhaps carrying concealed lutefisk should carry criminal penalties in
> | Switzerland...
>
> Only a small number of people have concealed carry licenses for lutefisk
> in Norway. Most counties were "shall issue" before a recent accident
> where a taxi driver driver was assaulted with frozen meatloaf, obviously
> because the assailant was a law-abiding citizen who did not carry a
> pocket knife, but now they are mostly "may issue". The police are in
> general quite sympathetic to people who apply for a license to carry
> lutefisk for personal or home protection, however. And I bet most of you
> furriners thought lutefisk was foodstuff, but it is way more lethal than
> you can imagine in the wrong hands!
Ah, you uptight Europeans, you should come out West some time.
Everyone's got a burrito in their pocket down here in Cali, and
lutefisk up in Minnesota and the Olympic peninsula. That pretty much
guarantees that no one can just ride into town with a side of salt
pork and expect to get away with it :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
j...@itasoftware.com
> Ah, you uptight Europeans, you should come out West some time.
> Everyone's got a burrito in their pocket down here in Cali, and
> lutefisk up in Minnesota and the Olympic peninsula.
And I thought they were just real happy to see me.