[Haskell-cafe] File path programme

[Ben Rudiak-Gould]

Robert Dockins wrote:

 >This is true in a sense, but I think making the distinction explicit is
 >helpful for a number of the operations we want to do.  For example, what
 >is the parent of the relative path "."?  Answer is "..".  What is the
 >parent of "/." on unix?  Answer is "/.".

While true, I don't see what this has to do with the choice between 
PathStart and Maybe PathRoot. The types are isomorphic; we can detect 
and simplify the /.. case either way.

 >Relative paths can refer to different things in the filesystem depending
 >on process-local state, whereas absolute paths will always refer to the
 >same thing (until the filesystem changes, or if you do something
 >esoteric like "chroot").  Relative paths are really "path fragments."

Okay, this is a good point. There is a difference between a path 
fragment (i.e. a path with no starting point specified) and a path which 
explicitly starts in the process's default directory. You're right that 
the pathname "foo/bar" can only sensibly be put in the former category.

The problem is that where Posix has just

       Absolute
          |
       Relative

Win32 has

       Absolute
       /     \
      /       \
  Rel:Abs   Abs:Rel
      \       /
       \     /
       Relative

where "Rel:Abs" means something like "\foo" and "Abs:Rel" means 
something like "c:foo". I never realized before what a nightmare it is 
to handle this sensibly. The problem is that pathAppend "c:\foo\bar" 
"d:." == "d:.", but pathAppend "d:\foo\bar" "d:." == "d:\foo\bar\.". 
Therefore, pathAppend "\foo\bar" "d:." doesn't have a value at all, 
since its meaning depends on the current drive in a way that can't be 
expressed in the Win32 path syntax.

Because of the above problem, I'm willing to treat path fragments 
(Relative in both lattices) as a special case. But we still need to be 
able to round-trip rel:abs and abs:rel pathnames, meaning that the 
PathRoot type won't necessarily be a genuine cwd-independent root any more.

 >There are a few others.  I took a look at MSDN earlier and was
 >astounded.

Is there an MSDN page that actually gives a grammar, or at least a 
taxonomy, of Win32 pathnames? That would be useful.

Incidentally, NT doesn't do a perfect job of parsing its own pathnames. 
While experimenting I managed to create a file named "..", different 
from the directory ".." (both show up in the directory listing), which I 
was subsequently unable to read or delete. The command was something 
like "cat > ..:foo". I doubt that this behavior is by design.

 >> > pathCleanup :: p -> p           -- remove .. and suchlike
 >>
 >>This can't be done safely except in a few special cases (e.g. "/.." ->
 >>"/"). I'm not sure it should be here.
 >
 >More than you would think, if you follow the conventions of modern unix
 >shells.

It's not a general convention even in the shell, just a peculiarity of 
the cd builtin:

  GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)
  # mkdir /bar
  # mkdir /bar/baz
  # ln -s /bar/baz /foo
  # echo /file > /file
  # echo /bar/file > /bar/file
  # cat /foo/../file
  /bar/file
  # ls /foo/..
  baz  file
  # cd /foo
  # cat ../file
  /bar/file

In the vast majority of cases it's not safe to collapse "/foo/.." to "/".

On reflection I think the function should be provided, but with a name 
like pathCancel and a usage warning in the documentation. If it's not 
provided people will write it themselves without realizing that it's unsafe.

-- Ben