On 4 December 2017 at 08:25, Richard A. O'Keefe <o...@cs.otago.ac.nz> wrote:
> > Ben Coman <b...@openinworld.com> wrote: > >> While 'canonicalize' obviously fits, it seems a bit exotic and a tongue >> twist at five syllables. >> I wonder if 'flatten' might also be suitable. Is there some concept this >> wouldn't cover? >> > > There are two distinct issues. > (1) Can this file name be put into a form that would have the > same reference as the original whatever the state of the > file system? (That is, whatever the same of the file > system, the original name and the new form will reference > to the same thing or neither will refer to anything, as > long as I don't change directory.) > > For this, it _is_ safe to collapse // to / (except at the > beginning) and to elide "." entries, but because of > symbolic links it is *not* safe to elide ".." entries. > > (2) Give me an absolute path name that does not contain any > symbolic links and will refer to the same file as long > as no directories along the way are renamed or deleted. > > Thanks for you input. Thats a nice framework to consider this. Someone else will have to advise the intent of the method. > There is no POSIX function to do (1). > The POSIX function that does (2) is realpath(2). > If the Smalltalk method is intended to have the same semantics > as the realpath() function, it should have the same name, > possibly spelled #realPath. > btw, my personal preference where we echo another api is to use identical capitalization. I believe this reduces friction transferring knowledge between domains. Lucky for me Pharo at least partially follows that convention e.g. `basename`... https://github.com/pharo-project/pharo/blob/development/src/FileSystem-Core/FileSystemDirectoryEntry.class.st#L75 cheers -ben There is a Solaris function called resolvepath() which is subtly > different from realpath() and not generally available. > >
