Opened 13 years ago

Last modified 9 months ago

#132 assigned defect

Inconsistent use of :case :common for pathnames

Reported by: Mark Evenson Owned by: Mark Evenson
Priority: critical Milestone: 1.9.3
Component: interpreter Version: 0.24
Keywords: ansi-conformance pathname needs-tests ansi_correctness Cc:
Parent Tickets:

Description

Pascal Bourguignon notes:


CLHS says:

    19.2.2.1.2.2 Common Case in Pathname Components

    For the functions in Figure 19-2, a value of :common for the :case
    argument that these functions should receive and yield strings in
    component values according to the following conventions:

    * All uppercase means to use a file system's customary case.
    * All lowercase means to use the opposite of the customary case.
    * Mixed case represents itself.

    Note that these conventions have been chosen in such a way that
    translation from :local to :common and back to :local is
    information-preserving.



[pjb@kuiper :0.0 lisp]$ abcl
Armed Bear Common Lisp 0.20.0
Java 1.6.0_22 Sun Microsystems Inc.
Java HotSpot(TM) Server VM
Low-level initialization completed in 0.265 seconds.
Startup completed in 0.718 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (make-pathname :name "TEST" :type "LISP" :case :common)
#P"TEST.LISP"
CL-USER(2): (namestring (make-pathname :name "TEST" :type "LISP" :case :common))
"TEST.LISP"


I'm on a linux system on a ext3 file system.  The customary case is
lower case (case significant on this particular file system, but
99.999% of the files on unix are lower case).

Therefore I would expect to get #P"test.lisp"


Notice that:

    (make-pathname :name "test" :type "lisp" :case :common)
    should produce #P"TEST.LISP"

and that:

    (make-pathname :name "Test" :type "Lisp" :case :common)
    should produce #P"Test.Lisp"
Mark Evenson writes:

> > On 11/7/10 5:02 AM, Pascal J. Bourguignon wrote:
>> >>
>> >> CLHS says:
>> >>
>> >>      19.2.2.1.2.2 Common Case in Pathname Components
>> >>
>> >>      For the functions in Figure 19-2, a value of :common for the :case
>> >>      argument that these functions should receive and yield strings in
>> >>      component values according to the following conventions:
>> >>
>> >>      * All uppercase means to use a file system's customary case.
>> >>      * All lowercase means to use the opposite of the customary case.
>> >>      * Mixed case represents itself.
>> >>
>> >>      Note that these conventions have been chosen in such a way that
>> >>      translation from :local to :common and back to :local is
>> >>      information-preserving.
> >
> > What an odd corner of the CLHS, littered with the bones of extinct 
> > filesystems! This behavior that seems like it would produce 
> > unpleasantries much more than it would help anyone, violating the 
> > principle of least surprise.  But we claim that ABCL will be ANSI first 
> > and foremost, so I guess we have to pay attention here…
I should mention that I use routinely logical pathnames, and they work
very well, on all implementations that conformantly implement them.

That means that all my logical pathnames are always upcase letters, and
no special symbols (apart from an occasional dash).


I understand that using implementation dependant syntax (special
characters, lower-case, mixed-case) in logical pathnames can lead to
surprises, but I avoid them.


Now, it's not a question of extinct file systems.  You still have to
deal with at least two different major syntaxes: POSIX and
MS-Windows/MS-DOS.

I just cannot use in programs that will have to run on both Linux or
MacOSX and MS-Windows physical pathname literals, because they don't use
the same syntax.

On the other hand, #P"HOME:SRC;LISP;EXAMPLE.LISP" 
can be translated to either
#P"C:\\Users Files\\Pascal\\src\\lisp\\example.lisp" or
#P"/home/pjb/src/lisp/example.lisp"
portably on these targets.


The point for an implementation is to know what it's targets are, and to
implement proper behavior when translating and merging logical
pathnames.  You must be careful when merging logical pathnames with
physical pathnames, notably when it's done in make-pathname: the :case
parameter must have effect only on the new strings, not on the :defaults
parameter.



> > I suppose there is no definition of "customary case", huh?  
Indeed.


> > Pascal  suggests a notion of filesystem statistics ("99.999% of files
> > are  lowercase") but for a developer dealing with lots of Java files
> > this  isn't very releavant.
Does Java provide its own file system, or does it map to the host file
system?

Notice that logical pathnames don't have to be able to represent all the
physical pathnames, without an explicit translation.

If you have a file system that is case sensitive, then you may write:

(setf (logical-pathname-translations "APP")
      (list
       (list #P"APP:EXAMPLE;FILE.LISP"         #P"/MyApp/Example/File.lisp")
       (list #P"APP:EXAMPLE;ANOTHER-FILE.LISP" #P"/MyApp/Example/AnotherFile.lisp")
       (list #P"APP:EXAMPLE;*.DATA"            #P"/MyApp/Example/*.appdata")
       (list #P"APP:EXAMPLE;SOME-MODULE.*"     #P"/MyApp/Example/SomeBigModule.*")
       (list #P"APP:APP.CONFIGURATION"         #P"/MyApp/.config")
       (list #P"APP:CUSTOMARY;**;*"            #P"/MyApp;**;*")
       (list #P"APP:CUSTOMARY;**;*.*"          #P"/MyApp;**;*.*")))

to be able to access to files with strange physical names.

The question indeed is to decide what is the customary case.  You can
choose uppercase or you can choose lowercase.  This matters only for
file systems that are case sensitive, but even file systems that are not
case sensitive, such as MS-DOS, have a prefered way to display the
names.


> > Lacking a more precise definition, I would then advocate that we declare 
> > lowercase to be the customary case across UNIX, OSX, and Windows for 
> > ABCL, patching our behavior accordingly.  
That would be good.


> > I thought briefly about  advocating Windows to have "uppercase" as its
> > customary case, but that  is only really true in a DOS world which
> > "modern" Windows systems really  aren't any more.
Yes.


> > And although we theoretically run on JVMs on say VMS, if we run into 
> > such needs, we might devote a user-accessible special variable to 
> > control the implementation.
This is also a good option.

Change History (27)

comment:1 Changed 13 years ago by Mark Evenson

Probably the root case for #133.

comment:2 Changed 13 years ago by ehuelsmann

Milestone: 0.250.26

comment:3 Changed 13 years ago by Mark Evenson

Keywords: needs_tests ansi_correctness added
Milestone: 0.260.27

comment:4 Changed 13 years ago by Mark Evenson

Milestone: 0.270.28

comment:5 Changed 12 years ago by Mark Evenson

Milestone: 0.281.0.1

comment:6 Changed 12 years ago by Mark Evenson

Keywords: pathname added
Milestone: 1.0.11.1.0

comment:7 Changed 12 years ago by ehuelsmann

Owner: changed from ehuelsmann to Mark Evenson
Status: newassigned

Mark is usually the one to work on pathnames. Assigning him as the owner. :-)

comment:8 Changed 11 years ago by Mark Evenson

Milestone: 1.1.01.1.1

comment:9 Changed 11 years ago by Mark Evenson

Keywords: ansi-conformance needs-tests added; needs_tests removed

comment:10 Changed 11 years ago by Mark Evenson

Milestone: 1.1.11.2.0
Priority: majorcritical

comment:11 Changed 11 years ago by Evenson Not Org

Milestone: 1.2.01.3.0

comment:12 Changed 10 years ago by Mark Evenson

Milestone: 1.3.02.0

Ticket retargeted after milestone closed

comment:13 Changed 10 years ago by Mark Evenson

Milestone: 2.02.0.0

Milestone renamed

comment:14 Changed 10 years ago by Mark Evenson

Milestone: 2.0.01.4.0

comment:15 Changed 7 years ago by Mark Evenson

Milestone: 1.4.01.5.0

Ticket retargeted after milestone closed

comment:16 Changed 7 years ago by Mark Evenson

Milestone: 1.5.01.6.0

Ticket retargeted after milestone closed

comment:17 Changed 4 years ago by Mark Evenson

Milestone: 1.6.01.6.1

Ticket retargeted after milestone closed

comment:18 Changed 4 years ago by Mark Evenson

Milestone: 1.6.11.6.2

Ticket retargeted after milestone closed

comment:19 Changed 4 years ago by Mark Evenson

Milestone: 1.6.21.7.0

comment:20 Changed 4 years ago by Mark Evenson

Milestone: 1.7.01.7.1

Ticket retargeted after milestone closed

comment:21 Changed 4 years ago by Mark Evenson

Milestone: 1.7.11.7.2

Ticket retargeted after milestone closed

comment:22 Changed 3 years ago by Mark Evenson

Milestone: 1.7.21.8.0

Milestone renamed

comment:23 Changed 3 years ago by Mark Evenson

Milestone: 1.8.01.8.1

Ticket retargeted after milestone closed

comment:24 Changed 23 months ago by Mark Evenson

Milestone: 1.8.11.9.0

comment:25 Changed 14 months ago by Mark Evenson

Milestone: 1.9.01.9.1

comment:26 Changed 13 months ago by Mark Evenson

Milestone: 1.9.11.9.2

comment:27 Changed 9 months ago by Mark Evenson

Milestone: 1.9.21.9.3
Note: See TracTickets for help on using tickets.