From marcoxa at cs.nyu.edu Tue Jun 24 06:53:47 2008 From: marcoxa at cs.nyu.edu (Marco Antoniotti) Date: Tue, 24 Jun 2008 08:53:47 +0200 Subject: [names-and-paths-devel] Re: Spaces in logical pathnames In-Reply-To: References: <485184BC.3040108@cmu.edu> <18513.39857.981982.319584@hubble.informatimago.com> <48582523.4020601@cmu.edu> <9A066E44-E46A-4E53-974F-203C431636C5@gmail.com> <0B102C96-0CCB-4B25-A570-05E983F252F0@cs.nyu.edu> Message-ID: <3BE94946-07BE-455D-BDEB-44C1857DC239@cs.nyu.edu> On Jun 18, 2008, at 17:30 , Chun Tian (binghe) wrote: > > Hi, Marco (or Macro?) Macro in the Lisp world, Marco elsewhere :) > I think the problem with CL pathname is different from others, like > networking, GUI... Though packages like CL-FAD already done big > help as an addition to exist pathname interface, I don't think a > portable pathname interface itself is necessary. It is your opinion. I think a portable pathname *specification* is necessary. > As far as I see, the biggest problem of CL pathname is that every > CL implementor has his own opinion on how to implement a "right" > pathname spec of CL standard. The problem is that the pathname spec is way too underspecified and concocted at a time when there were things like ITS and TOPS-10-20-42. > We, CL user, also have our own opinion. Fortunately we can talk > about this topic directly to all CL implementors as we wish on > mailing list, and keep talking to find out a common knowledge about > CL pathname. At present, I think I have to use the most common part > of pathname (on the way all CL supported), and just wait people who > can make them better to judge whether to get it slightly changed to > fit more people's tastes. Ok. But I do not understand. Is talking about a common specification a good thing or a bad thing? I am not saying it is immediately useful, but somohow, somewhere, the issues should to be discussed. Talking separatedly to the implementors is not IMHO very fruitful. I think that users and implementors discussing this issue together is a better way of proceeding. Once there is some consensus, then you can go ahead and write a CDR. But the bottom line stands. (parse-namestring ".cshrc") ; On a UN*X filesystem should return the "same" thing on every implementation. (Note: I don't care what, just the same, possibly 42 :) ). Cheers -- Marco PS. Sorry. I think this is a little OT. Please feel free to move the discussion on NAMES-AND-PATHS-DEVEL. > > Regards, > > Chun Tian (binghe) > >> >> Very interesting discussion. >> >> Do you all know that there is a venue for discussing all these >> vexing issues and try (at least *try*) to come up with a solution? >> >> http://common-lisp.net/project/names-and-paths >> >> Please join the mailing lists there and let's get to work. >> >> >> Cheers >> -- >> Marco >> >> PS. What is there is a *start*. Nothing more. One missing part >> is the recognition of different File Systems. >> >> >> >> >> On Jun 18, 2008, at 01:52 , Chun Tian (binghe) wrote: >> >>> >>>>> >>>> Thanks, but that's not the solution I'm looking for. Yes, using >>>> spaces in pathnames is not portable to other CL systems, but it >>>> is portable among all current OSes that matter. So I think CL >>>> systems should allow it. I think using a specific logical >>>> pathname translation for each folder or file that has a space in >>>> the name is pretty ugly, I'd rather give up using spaces. I >>>> still hope there is a solution to allow it in LW, what else >>>> could the system::*logical-pathname-allow-spaces-p* be intended >>>> for? >>> >>> Hi, >>> >>> In old Symbolics time, logical-pathnames do can have spaces (I >>> think so by reading some old documents), but like this: >>> >>> #p"HOME:ASDF;PACKAGES;" >>> #p"HOME: ASDF; PACKAGES;" >>> >>> When I saw system::*logical-pathname-allow-spaces-p*, I just >>> thought it's a switch to open above syntax, but unfortunately not... >>> >>> P.S. I think it's a big Challenge for modern CL systems to detect >>> whether a pathname string/object is a Logical-Pathname, and do >>> the other parsing job, but obviously enable spaces in logical- >>> pathname wouldn't cause much different meanings. >>> >>> Regards, >>> >>> Chun Tian (binghe) >>> >>>> >>>> >>>> Thanks, >>>> Octav >>>> >>> >> >> -- >> Marco Antoniotti >> >> > -- Marco Antoniotti From antoniotti.marco at disco.unimib.it Tue Jun 24 07:16:12 2008 From: antoniotti.marco at disco.unimib.it (Marco Antoniotti) Date: Tue, 24 Jun 2008 09:16:12 +0200 Subject: [names-and-paths-devel] Test 3 Message-ID: This should go through -- Marco Antoniotti