Both CMUCL and SBCL downcase the namestring passed to
TRANSLATE-LOGICAL-PATHNAME. And both upcase the namestring pased
to PARSE-NAMESTRING. I am sure they are doing the right thing,
but I don't want that. How should I tell them to keep the original
cases?
Thanks
T.
Takehiko Abe wrote:
> Both CMUCL and SBCL downcase the namestring passed to
> TRANSLATE-LOGICAL-PATHNAME. And both upcase the namestring pased
> to PARSE-NAMESTRING. I am sure they are doing the right thing,
> but I don't want that. How should I tell them to keep the original
> cases?
You can preserve case if you create the original pathname using
(MAKE-PATHNAME) with its keyword arguments (as opposed to passing it a
string representing the path).
Check out Peter Seibel's Practical Common Lisp chapter on File I/O
(http://gigamonkeys.com/book/files-and-file-io.html) -- start with the
paragraph entitled "Filenames: So far you've used strings to represent
filenames..."
Here's a quick example -- if your path is all lowercase (and you want
it to stay that way):
* (make-pathname :directory '(:absolute "foo" "bar") :name "baz" :type
"txt")
#P"/foo/bar/baz.txt"
* (parse-namestring (make-pathname :directory '(:absolute "foo" "bar")
:name "baz" :type "txt"))
#P"/foo/bar/baz.txt"
0
* (translate-logical-pathname (make-pathname :directory '(:absolute
"foo" "bar") :name "baz" :type "txt"))
#P"/foo/bar/baz.txt"
Likewise, if your path is all uppercase, that stays preserved, too:
* (make-pathname :directory '(:absolute "FOO" "BAR") :name "BAZ" :type
"TXT")
#P"/FOO/BAR/BAZ.TXT"
* (parse-namestring (make-pathname :directory '(:absolute "FOO" "BAR")
:name "BAZ" :type "TXT"))
#P"/FOO/BAR/BAZ.TXT"
0
* (translate-logical-pathname (make-pathname :directory '(:absolute
"FOO" "BAR") :name "BAZ" :type "TXT"))
#P"/FOO/BAR/BAZ.TXT"
* (make-pathname :directory '(:absolute "foo" "bar") :name "baz" :type
"txt")
dpapathanasiou:
> > Both CMUCL and SBCL downcase the namestring passed to
> > TRANSLATE-LOGICAL-PATHNAME. And both upcase the namestring pased
> > to PARSE-NAMESTRING. I am sure they are doing the right thing,
> > but I don't want that. How should I tell them to keep the original
> > cases?
>
> You can preserve case if you create the original pathname using
> (MAKE-PATHNAME) with its keyword arguments (as opposed to passing it a
> string representing the path).
I don't want to use MAKE-PATHNAME, at least not everywhere.
logical pathnames are sometimes very convenient so I use them
here & there. but I am not that a fan of the pathname facility.
I use (format nil ...) to produce namestrings. and MAKE-PATHNAME
looks heavy.
> [...]
>
> * (parse-namestring (make-pathname :directory '(:absolute "foo" "bar")
> :name "baz" :type "txt"))
Agh.
* (make-pathname :directory '(:absolute "foo" "bar"))
#P"/foo/bar/"
* (eql * (parse-namestring *))
T
regards,
T.
Takehiko Abe wrote:
> I don't want to use MAKE-PATHNAME, at least not everywhere.
> logical pathnames are sometimes very convenient so I use them
> here & there. but I am not that a fan of the pathname facility.
> I use (format nil ...) to produce namestrings. and MAKE-PATHNAME
> looks heavy.
I can empathize: I'd written a bunch of code using (with-open-file
"/path/to/file" ..) before I'd read Seibel's book, and my immediate
thought was "oh no, I've got to change it all to pathnames!".
But, having looked at the rationale for and the practical flexibility
of using (MAKE-PATHNAME), I'd say the switch is worth it.
Also, note that you can create relative paths with (MAKE-PATHNAME) --
the :absolute keyword was just an example.
dpapathanasiou
> I can empathize: I'd written a bunch of code using (with-open-file
> "/path/to/file" ..)
I got bitten by writing (with-open-file (in "myhost:to;FiLe"))
(it ends up with "/myhost/to/file").
> before I'd read Seibel's book, and my immediate
> thought was "oh no, I've got to change it all to pathnames!".
>
> But, having looked at the rationale for and the practical flexibility
> of using (MAKE-PATHNAME), I'd say the switch is worth it.
My problem is this:
* (setf (logical-pathname-translations "test")
(list (list "**;*.*.*" "/usr/local/")))
(("**;*.*.*" "/usr/local/"))
* (translate-logical-pathname "test:Foo")
#P"/usr/local/foo"
And MAKE-PATHNAME doesn't help:
* (translate-logical-pathname (make-pathname :host "test"
:name "Foo"))
#P"/usr/local/foo"
Thanks,
T.
····@gol.com (Takehiko Abe) writes:
> dpapathanasiou
>
>> I can empathize: I'd written a bunch of code using (with-open-file
>> "/path/to/file" ..)
>
> I got bitten by writing (with-open-file (in "myhost:to;FiLe"))
> (it ends up with "/myhost/to/file").
>
>> before I'd read Seibel's book, and my immediate
>> thought was "oh no, I've got to change it all to pathnames!".
>>
>> But, having looked at the rationale for and the practical flexibility
>> of using (MAKE-PATHNAME), I'd say the switch is worth it.
>
> My problem is this:
>
> * (setf (logical-pathname-translations "test")
> (list (list "**;*.*.*" "/usr/local/")))
> (("**;*.*.*" "/usr/local/"))
> * (translate-logical-pathname "test:Foo")
> #P"/usr/local/foo"
>
> And MAKE-PATHNAME doesn't help:
>
> * (translate-logical-pathname (make-pathname :host "test"
> :name "Foo"))
> #P"/usr/local/foo"
First, you should write "TEST" and "FOO", because anything else is
implementation dependant, and better used in a physical pathname than
a logical pathname.
But logical pathnames are NOT made to access the native file system.
They're made to access a _logical_ file system, mapped to the native
file system by way of the logical-pathname-translations.
The purpose is not to access any random item in the native file
system. It's to provide a clean, logical file system implemented over
the native one.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
On 2006-12-02 03:48:22 +0000, ····@gol.com (Takehiko Abe) said:
> My problem is this:
>
> * (setf (logical-pathname-translations "test")
> (list (list "**;*.*.*" "/usr/local/")))
> (("**;*.*.*" "/usr/local/"))
> * (translate-logical-pathname "test:Foo")
> #P"/usr/local/foo"
You probably should not be using logical pathnames here. This doesn't
mean you should be using strings.
--tim
Takehiko Abe wrote:
>
> I don't want to use MAKE-PATHNAME, at least not everywhere.
> logical pathnames are sometimes very convenient so I use them
> here & there. but I am not that a fan of the pathname facility.
> I use (format nil ...) to produce namestrings. and MAKE-PATHNAME
> looks heavy.
Yeah, I know. Data types, who needs 'em when you have strings? All
those constructors and accessors and crap. Strings are just so much
... oh sorry, wrong newsgroup.
> Yeah, I know. Data types, who needs 'em when you have strings? All
> those constructors and accessors and crap. Strings are just so much
> ... oh sorry, wrong newsgroup.
???
"dpapathanasiou" <···················@gmail.com> writes:
> Takehiko Abe wrote:
>
> You can preserve case if you create the original pathname using
> (MAKE-PATHNAME) with its keyword arguments (as opposed to passing it a
> string representing the path).
This has nothing to do with using MAKE-PATHNAME instead of using
strings. All implementations I know of always preserve case when
parsing namestrings that aren't syntactically valid logical pathname
namestrings.
* (with-open-file (f "/etc/passwd")
(read-line f))
=> "root:x:0:0:root:/root:/bin/bash"
=> NIL
The OP was asking about preserving case when using logical pathnames.
> Here's a quick example -- if your path is all lowercase (and you
> want it to stay that way):
<snip>
> * (translate-logical-pathname (make-pathname :directory '(:absolute
> "foo" "bar") :name "baz" :type "txt"))
>
> #P"/foo/bar/baz.txt"
>
> Likewise, if your path is all uppercase, that stays preserved, too:
<snip>
> * (translate-logical-pathname (make-pathname :directory '(:absolute
> "FOO" "BAR") :name "BAZ" :type "TXT"))
>
> #P"/FOO/BAR/BAZ.TXT"
Your examples are accidentally misleading. The pathnames you're
constructing are physical pathnames. When TRANSLATE-LOGICAL-PATHNAME
receives a physical pathname designator as an argument, it returns the
designated pathname.
Here are the relevant counterexamples (run on SBCL):
* (make-pathname :host "sys" :name "bar" :type "lisp")
=> #P"SYS:BAR.LISP"
Logical pathname components are always uppercase.
* (translate-logical-pathname
(make-pathname :host "SYS" :name "BAR" :type "LISP"))
=> #P"/home/me/sbcl/bar.lisp"
Translation of a logical pathname may involve any sort of
implementation-defined conversion, including downcasing.
--
RmK
Richard M Kreuter wrote:
> The OP was asking about preserving case when using logical pathnames.
>
> Your examples are accidentally misleading. The pathnames you're
> constructing are physical pathnames. When TRANSLATE-LOGICAL-PATHNAME
> receives a physical pathname designator as an argument, it returns the
> designated pathname.
>
> Here are the relevant counterexamples (run on SBCL):
>
> * (make-pathname :host "sys" :name "bar" :type "lisp")
> => #P"SYS:BAR.LISP"
>
Ah, my mistake: I misunderstood the original question; thanks for the
clarification.
In article <·····················@192.168.1.2>,
····@gol.com (Takehiko Abe) wrote:
> Both CMUCL and SBCL downcase the namestring passed to
> TRANSLATE-LOGICAL-PATHNAME. And both upcase the namestring pased
> to PARSE-NAMESTRING. I am sure they are doing the right thing,
> but I don't want that. How should I tell them to keep the original
> cases?
I don't think you can, at least not portably. The logical pathname
filesystem is essentially an uppercase-only filesystem. The logical
pathname translation mechanism is then supposed to map this to the
normal case for the target filesystem. The CLHS says:
19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring
When parsing words and wildcard-words, lowercase letters are translated
to uppercase.
Logical pathnames are not intended to be able to represent all possible
filenames on any particular system. It's defined to be a minimal
subset, useful for portable filenames across a wide variety of operating
systems. What would you expect to happen if you used case-sensitive
logical filenames, and then tried to port your application to a
case-insensitive system?
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin wrote:
> > Both CMUCL and SBCL downcase the namestring passed to
> > TRANSLATE-LOGICAL-PATHNAME. And both upcase the namestring pased
> > to PARSE-NAMESTRING. I am sure they are doing the right thing,
> > but I don't want that. How should I tell them to keep the original
> > cases?
>
> I don't think you can, at least not portably.
I see.
> The logical pathname
> filesystem is essentially an uppercase-only filesystem. The logical
> pathname translation mechanism is then supposed to map this to the
> normal case for the target filesystem. The CLHS says:
>
> 19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring
> When parsing words and wildcard-words, lowercase letters are translated
> to uppercase.
>
> Logical pathnames are not intended to be able to represent all possible
> filenames on any particular system. It's defined to be a minimal
> subset, useful for portable filenames across a wide variety of operating
> systems. What would you expect to happen if you used case-sensitive
> logical filenames, and then tried to port your application to a
> case-insensitive system?
Aha! Thank you.
Incidentally, I have just found a c.l.l article by Erik Naggum.
http://groups.google.com/group/comp.lang.lisp/msg/a6aeff0b733d98ba
So you construct the logical file system with a small number
of logical hosts and name all your files within it/them,
and then arrange for the physical world to have the physical
files and directories to which they are mapped. Going the
other way around is simply misguided.
I need to ponder more how to solve my problem at hand (already
fixed the problem by ensuring never produce uppercase letters
for filenames -- but I considered it a workaround). But I think
I have a correct overall picture now.
Thanks,
T.
····@gol.com (Takehiko Abe) writes:
> Both CMUCL and SBCL downcase the namestring passed to
> TRANSLATE-LOGICAL-PATHNAME...
Implementations are expressly permitted to perform translations such
as case conversion when going from logical pathnames to physical
pathnames. This is convenient, given that logical pathname components
are always uppercase because...
> ... And both upcase the namestring pased to PARSE-NAMESTRING.
Implementations are required to translate lowercase letters to
uppercase when parsing a logical pathname namestring. When passed a
non-logical pathname namestring, SBCL does not perform any case
conversion.
> I am sure they are doing the right thing, but I don't want that.
> How should I tell them to keep the original cases?
You can't. The namespace provided by logical pathnames is not
case-preserving.
Logical pathnames were devised only for the problem of letting a Lisp
program designate in a filesystem-independent way the files that the
program itself uses. They're not meant as a general-purpose file
namespace abstraction.
--
RmK
Richard M Kreuter wrote:
> Implementations are expressly permitted to perform translations such
> as case conversion when going from logical pathnames to physical
> pathnames. This is convenient, given that logical pathname components
> are always uppercase because...
>
> > ... And both upcase the namestring pased to PARSE-NAMESTRING.
>
> Implementations are required to translate lowercase letters to
> uppercase when parsing a logical pathname namestring.
I am surprised.
> When passed a
> non-logical pathname namestring, SBCL does not perform any case
> conversion.
>
> > I am sure they are doing the right thing, but I don't want that.
> > How should I tell them to keep the original cases?
>
> You can't. The namespace provided by logical pathnames is not
> case-preserving.
>
> Logical pathnames were devised only for the problem of letting a Lisp
> program designate in a filesystem-independent way the files that the
> program itself uses. They're not meant as a general-purpose file
> namespace abstraction.
Darn. I've been using them as just that. A convenient abstraction.
So that I can move some directories around. Portablity across
filesystems is not my concern.
It is not hard to modify my expectation and codes since
I use all lowercase file names anyway. (The bug was in
(format nil "~X") to name a file.)
But still, I must wonder if it is worth that logical pathnames
behave as defined in the spec today. Who cares about the
portablity when all we have is unix filesystem.
Thanks,
T.
····@gol.com (Takehiko Abe) wrote on Sat, 02 Dec 2006:
> But still, I must wonder if it is worth that logical pathnames
> behave as defined in the spec today. Who cares about the
> portablity when all we have is unix filesystem.
Surely you didn't mean to leave out the Windows filesystem(s), which probably
run on a greater number of computers and storage devices than any unix system.
You are right that the spec might be slightly different if designed today,
rather than in its original time. But you may have missed part of the design
goal. CL was designed as a language for expressing computation for all time,
needing to live not only in past and current operating systems, but also in
future ones. Even if every computer today ran unix, CL still has an interest
in being compatible with whatever succeeds unix.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I have been complimented many times and they always embarrass me; I always
feel that they have not said enough. -- Mark Twain
Don Geddis:
> CL was designed as a language for expressing computation for all time,
> needing to live not only in past and current operating systems, but also in
> future ones. Even if every computer today ran unix, CL still has an interest
> in being compatible with whatever succeeds unix.
Yes... Maybe I am too short sighted, but I don't see the future is
coming. And CL's pathname facility seems more complex than necessary
for today's requiremnt, and that I believe is taxing implementors.
As for the future, I think we will be able cope with it when it
arrvies.
Not that I think CL's filesystem interface was badly designed.
And I learned how I should use logical pathnames.
regards,
T.
····@gol.com (Takehiko Abe) wrote on Sun, 03 Dec 2006:
> And CL's pathname facility seems more complex than necessary for today's
> requiremnt, and that I believe is taxing implementors.
Well, for what it's worth, I think many in the CL community would agree that
the pathname section of the ANSI CL spec is one of the worst-designed parts
of what is otherwise a very impressive specification.
As I recall, the explanation was that this was one of the last sections added
to the standard, and time and energy (and money) were slipping away at the
end of the standardization process.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
If being an eagle is such a good idea, why are there so few of them?
-- Wally, from Dilbert
In article <·····················@192.168.1.2>,
····@gol.com (Takehiko Abe) wrote:
> But still, I must wonder if it is worth that logical pathnames
> behave as defined in the spec today. Who cares about the
> portablity when all we have is unix filesystem.
First of all, consider that the standard was being written about 20
years ago. The computing industry had not converged on just a couple of
operating systems and a common filesystem model. Logical pathnames were
adopted from Lisp Machines, which were actively using a wide variety of
different file servers at the time: Unix, ITS, VMS, LMFS. Portability
was a real problem at the time, and required a solution like this.
And even now, not everything is Unix. Windows is incredibly popular,
although it's probably not the majority of CL programmers. And it has a
case-insensitive filesystem. So does Mac OS X by default, although it's
otherwise very Unix-like.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Am 02.12.2006 13:28 Uhr schrieb "Takehiko Abe" unter <····@gol.com> in
·····················@192.168.1.2:
> Richard M Kreuter wrote:
>
>> Implementations are expressly permitted to perform translations such
>> as case conversion when going from logical pathnames to physical
>> pathnames. This is convenient, given that logical pathname components
>> are always uppercase because...
>>
>>> ... And both upcase the namestring pased to PARSE-NAMESTRING.
>>
>> Implementations are required to translate lowercase letters to
>> uppercase when parsing a logical pathname namestring.
>
> I am surprised.
>
>> When passed a
>> non-logical pathname namestring, SBCL does not perform any case
>> conversion.
>>
>>> I am sure they are doing the right thing, but I don't want that.
>>> How should I tell them to keep the original cases?
>>
>> You can't. The namespace provided by logical pathnames is not
>> case-preserving.
>>
>> Logical pathnames were devised only for the problem of letting a Lisp
>> program designate in a filesystem-independent way the files that the
>> program itself uses. They're not meant as a general-purpose file
>> namespace abstraction.
>
> Darn. I've been using them as just that. A convenient abstraction.
> So that I can move some directories around. Portablity across
> filesystems is not my concern.
>
> It is not hard to modify my expectation and codes since
> I use all lowercase file names anyway. (The bug was in
> (format nil "~X") to name a file.)
>
> But still, I must wonder if it is worth that logical pathnames
> behave as defined in the spec today. Who cares about the
> portablity when all we have is unix filesystem.
>
>
> Thanks,
> T.
But WHEN will that be? Today we have all kinds of different
file systems in use.
Example: My MacBook runs HFS+ natively and I have to use NTFS and FAT32.
Data media uses ISO 9660 or UDF.
Above that I use network file systems with NFS, AFP, SMB, FTP and WebDAV.
See also:
http://en.wikipedia.org/wiki/List_of_file_systems
http://en.wikipedia.org/wiki/Comparison_of_file_systems
Rainer Joswig <······@lisp.de> writes:
> But WHEN will that be? Today we have all kinds of different
> file systems in use.
>
> Example: My MacBook runs HFS+ natively and I have to use NTFS and FAT32.
> Data media uses ISO 9660 or UDF.
> Above that I use network file systems with NFS, AFP, SMB, FTP and WebDAV.
The problem is that the standard doesn't specify anything precise for
each of the different kind of file system, therefore we get diverging
implementation.
Nobody complains that a CL pathname operation gives different results
on a different file system.
What we complain, is that two different implementations on the same OS
with the same file system give different results.
> See also:
>
> http://en.wikipedia.org/wiki/List_of_file_systems
> http://en.wikipedia.org/wiki/Comparison_of_file_systems
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
Am 03.12.2006 5:04 Uhr schrieb "Pascal Bourguignon" unter
<···@informatimago.com> in ··············@thalassa.informatimago.com:
> Rainer Joswig <······@lisp.de> writes:
>> But WHEN will that be? Today we have all kinds of different
>> file systems in use.
>>
>> Example: My MacBook runs HFS+ natively and I have to use NTFS and FAT32.
>> Data media uses ISO 9660 or UDF.
>> Above that I use network file systems with NFS, AFP, SMB, FTP and WebDAV.
>
> The problem is that the standard doesn't specify anything precise for
> each of the different kind of file system, therefore we get diverging
> implementation.
It is beyond the scope of a static standard like ANSI to define
such things like the behaviour of real file systems.
These already differ in their specifications and also
differ from their implementation version to the next.
Tracking this in an ANSI standard is a bad idea.
> Nobody complains that a CL pathname operation gives different results
> on a different file system.
>
> What we complain, is that two different implementations on the same OS
> with the same file system give different results.
I am not sure who is 'we', but I complain ;-) that pathnames are
non-extensible and not object-oriented in the ANSI CL standard.
I'm not sure that one can write down sensible common behaviour
for current pathnames for the various file systems and
the various Lisp implementations.
PATHNAME should be a CLOS class with some basic protocol.
Various subclass then would implement specific pathname
classes. If one wants to go the way of structured pathname
objects, then it should be CLOS and extensible.
If one doesn't want that, then we can get back to pathnames
as strings and live with just that.
PATHNAMEs as structured objects were once object-oriented modelled.
For Common Lisp this has been reduced and simplified. I am
not sure if the resulting pathname specification is very useful
and has a right to survive. ;-)
If one wants to unify common pathname behaviour, a good start
would be to write down a simple specification with lots of examples
in some of the communities wiki (say, http://wiki.alu.org/).
Since the ANSI CL standard is mostly fixed for any practical
purposes, writing a good proposal on the ALU wiki would be
a good start.
>
>
>> See also:
>>
>> http://en.wikipedia.org/wiki/List_of_file_systems
>> http://en.wikipedia.org/wiki/Comparison_of_file_systems
>
Pascal Bourguignon <···@informatimago.com> writes:
> Nobody complains that a CL pathname operation gives different results
> on a different file system.
>
> What we complain, is that two different implementations on the same OS
> with the same file system give different results.
But when does this happen?
a) When using standard MAKE-PATHNAME and friends?
b) When using logical pathnames according to the standard, limited to
using only uppdercase letters, digits and hyphens?
c) When using logical pathnames not according to the standard, but with
some implementation-defined extension?
It is certainly the case that the logical-pathname translations work
differently on different lisp implementations, which effectively means
that even on the same platform, you may need separate translation
declarations depending on the lisp implementation.
--
Thomas A. Russ, USC/Information Sciences Institute
On Wed, 06 Dec 2006 20:57:03 +0100, Thomas A. Russ <···@sevak.isi.edu>
wrote:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> Nobody complains that a CL pathname operation gives different results
>> on a different file system.
>>
>> What we complain, is that two different implementations on the same OS
>> with the same file system give different results.
>
> But when does this happen?
>
> a) When using standard MAKE-PATHNAME and friends?
>
> b) When using logical pathnames according to the standard, limited to
> using only uppdercase letters, digits and hyphens?
>
> c) When using logical pathnames not according to the standard, but with
> some implementation-defined extension?
>
> It is certainly the case that the logical-pathname translations work
> differently on different lisp implementations, which effectively means
> that even on the same platform, you may need separate translation
> declarations depending on the lisp implementation.
>
To sum up a few things I figured out:
There is no way to generalize the production of all direcories on all
platforms in all compilers.
However it helps matters in common cases.
Here is a example of a common use:
(defparameter *game-help-directory*
(merge-pathnames
(make-pathname :directory '(:RELATIVE "game" "help"))
(user-homedir-pathname)))
All standard ANSI CL.
Works at least on Windows and Unix and under ACL and LispWorks.
Here I build on the last example:
(defun game-help (subject)
(check-type subject string)
(let ((filename (merge-pathnames
(make-pathname :name subject :type "hlp")
*game-help-directory*)))
(dump-file filename)))
A bit more verbose than I would like but workable.
Here is the biggest discrepancy under windows.
For Lispworks:
(pathname-host (user-homedir-pathname)) -> C
For the others:
(pathname-device (user-homedir-pathname)) -> C
So take care if reading from DVD/CDROM say.
Compilers tend to return (pathname-host ..) -> nil even though that is
questionable
under the standard.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Rainer Joswig:
> But WHEN will that be? Today we have all kinds of different
> file systems in use.
>
> Example: My MacBook runs HFS+ natively and I have to use NTFS and FAT32.
> Data media uses ISO 9660 or UDF.
> Above that I use network file systems with NFS, AFP, SMB, FTP and WebDAV.
um, you use Mac OS which does the abstraction.
On 2006-12-02 12:28:29 +0000, ····@gol.com (Takehiko Abe) said:
> Darn. I've been using them as just that. A convenient abstraction.
> So that I can move some directories around. Portablity across
> filesystems is not my concern.
It's very easy to define an abstraction that uses ordinary pathnames.
> But still, I must wonder if it is worth that logical pathnames
> behave as defined in the spec today. Who cares about the
> portablity when all we have is unix filesystem.
Well, there's this other system called Windows that I hear has some
users. And not all Unix filesystems behave the way you probably expect
(what does the Mac's FS do for instance, I suspect it does at least
some case-folding).
+ Tim Bradshaw <···@tfeb.org>:
| And not all Unix filesystems behave the way you probably expect
| (what does the Mac's FS do for instance, I suspect it does at least
| some case-folding).
Yup, the standard filesystem on macosx is case-preserving but
case-insensitive. Just like on windows, I guess. Even more fun, it's
all Unicode, or more precisely UTF-8, and the file system enforces
that, so you cannot name a file using some string of bytes that isn't
valid UTF-8. And it's smart enough to understand about accented
letters, so that it recognizes the two ways of writing � as being the
same:
� U+00F6 LATIN SMALL LETTER O WITH DIAERESIS
� U+006F LATIN SMALL LETTER O followed by U+0308 COMBINING DIAERESIS
(Verified by using Finder to create a directory called G�del. The
resulting encoding of the filename was as � above. I then ran ls -d
with the filename spelled using �, and not only did it show the
directory, but it showed it with the spelling I had given to ls.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Am 03.12.2006 19:35 Uhr schrieb "Harald Hanche-Olsen" unter
<······@math.ntnu.no> in ···············@shuttle.math.ntnu.no:
> + Tim Bradshaw <···@tfeb.org>:
>
> | And not all Unix filesystems behave the way you probably expect
> | (what does the Mac's FS do for instance, I suspect it does at least
> | some case-folding).
>
> Yup, the standard filesystem on macosx is case-preserving but
> case-insensitive. Just like on windows, I guess. Even more fun, it's
> all Unicode, or more precisely UTF-8,
Isn't it UTF-16?
> and the file system enforces
> that, so you cannot name a file using some string of bytes that isn't
> valid UTF-8. And it's smart enough to understand about accented
> letters, so that it recognizes the two ways of writing � as being the
> same:
>
> � U+00F6 LATIN SMALL LETTER O WITH DIAERESIS
> � U+006F LATIN SMALL LETTER O followed by U+0308 COMBINING DIAERESIS
>
> (Verified by using Finder to create a directory called G�del. The
> resulting encoding of the filename was as � above. I then ran ls -d
> with the filename spelled using �, and not only did it show the
> directory, but it showed it with the spelling I had given to ls.)
+ Rainer Joswig <······@lisp.de>:
|> Yup, the standard filesystem on macosx is case-preserving but
|> case-insensitive. Just like on windows, I guess. Even more fun, it's
|> all Unicode, or more precisely UTF-8,
|
| Isn't it UTF-16?
Not if this experiment does what I /thought/ it does:
; echo G*del | od -t ax1
0000000 G o ? 88 d e l nl
47 6f cc 88 64 65 6c 0a
0000010
Note that (#xcc #x88) is the correct UTF-8 sequence for U+0308
COMBINING DIAERESIS. Let me add that the shell I'm using (es) is
ancient enough not to have any notion of multibyte character sets
built in. And, lest you think some dynamic library has more clue than
the shell (a distinct possibility), setting the "C" locale does not
change the result of this experiment. But it could well be that
they're using UTF-16 inside the filesystem, and then translating to
and from UTF-8 except for applications that specifically wish to talk
UTF-16 to the filesystem? Such translation would seem necessary in
order to not break old unibyte applications too horribly.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Ar an tri� l� de m� na Nollaig, scr�obh Rainer Joswig:
> > Yup, the standard filesystem on macosx is case-preserving but
> > case-insensitive. Just like on windows, I guess. Even more fun, it's
> > all Unicode, or more precisely UTF-8,
>
> Isn't it UTF-16?
No. See http://developer.apple.com/qa/qa2001/qa1173.html .
--
Santa Maradona, priez pour moi!
Am 03.12.2006 23:02 Uhr schrieb "Aidan Kehoe" unter <······@parhasard.net>
in ·························@parhasard.net:
>
> Ar an tri� l� de m� na Nollaig, scr�obh Rainer Joswig:
>
>>> Yup, the standard filesystem on macosx is case-preserving but
>>> case-insensitive. Just like on windows, I guess. Even more fun, it's
>>> all Unicode, or more precisely UTF-8,
>>
>> Isn't it UTF-16?
>
> No. See http://developer.apple.com/qa/qa2001/qa1173.html .
http://developer.apple.com/technotes/tn/tn1150.html#HFSPlusNames
UInt16
> > Yup, the standard filesystem on macosx is case-preserving but
> > case-insensitive. Just like on windows, I guess. Even more fun, it's
> > all Unicode, or more precisely UTF-8,
>
> Isn't it UTF-16?
It doesn't matter. If you use posix interface, it is utf-8 as far
as you're concerned.
> > and the file system enforces
> > that, so you cannot name a file using some string of bytes that isn't
> > valid UTF-8. And it's smart enough to understand about accented
> > letters, so that it recognizes the two ways of writing � as being the
> > same:
OS normalizes filenames to some unicode form [was HFS+ normalized form
the last time I heard].
regards,
T.
Tim Bradshaw <···@tfeb.org> writes:
> Well, there's this other system called Windows that I hear has some
> users. And not all Unix filesystems behave the way you probably expect
> (what does the Mac's FS do for instance, I suspect it does at least some
> case-folding).
It depends on which particular file system you put on the disk. You can
choose to install a standard Unix File System (UFS), which is a
case-preserving and case-differentiating file system. UFS is not the
default and is actually pretty rare.
The more common Mac standard file system (Hierarchical File System -
HFS) is a case-preserving and case-folding file system. It will adopt
the case of the first use of a file and then fold into this. So, you
would get the following results under Unix/Darwin on a Mac with an HFS
file system:
touch foo
touch Foo
touch Bar
touch bar
ls => Bar foo
Each disk (or disk partition) can have its own file system type, so the
results on a Mac can depend on which particular mounted disk one does
this on.
--
Thomas A. Russ, USC/Information Sciences Institute
····@gol.com (Takehiko Abe) writes:
> > Logical pathnames were devised only for the problem of letting a Lisp
> > program designate in a filesystem-independent way the files that the
> > program itself uses. They're not meant as a general-purpose file
> > namespace abstraction.
>
> Darn. I've been using them as just that. A convenient abstraction.
> So that I can move some directories around. Portablity across
> filesystems is not my concern.
Well, they do work well if your only concern is moving directories
around. You do have to take care in the naming of files, though.
But the point was to make it easy to have a mechanism which allowed your
program to not have to worry about where files were located, nor even
what sort of file system they were on. That allows a fair degree of
portability, but as others have pointed out it is not a full model of
all possible file systems. It is instead a minimal model of an abstract
file system that can be mapped to a large number of real file systems
without requiring the program itself to do the mapping.
The mapping is instead in a configuration file which defines the logical
host name translations.
> It is not hard to modify my expectation and codes since
> I use all lowercase file names anyway. (The bug was in
> (format nil "~X") to name a file.)
Well, it is also easy to change this, or more generally for any
generated names:
(format nil "~(~A~)" "AnyStringUwaNT")
Interestingly, in my lisp implementation ~X prints using lowercase
characters for the hex digits.
> But still, I must wonder if it is worth that logical pathnames
> behave as defined in the spec today. Who cares about the
> portablity when all we have is unix filesystem.
Hardly.
Anyway, if you want more flexibility, then you will need to handle more
of this yourself, using (presumably) special variables for particular
directories and MERGE-PATHNAMES or binding or specifying the
DEFAULT-PATHNAME for merging.
--
Thomas A. Russ, USC/Information Sciences Institute