On 4 December 2017 at 01:48, Ben Coman <b...@openinworld.com> wrote: > > > 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?
Just my personal preference, but I think canonicalize is better in this case. Flatten to me implies taking all the entries in a collection and removing the structure. In this case, we aren't removing the structure completely, the order of the segments still has meaning. >> 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. #canonicalize isn't intended to have the same semantics as realpath. Like it's python and java equivalents, it explicitly ignores symbolic links. It should be possible to implement realpath, however the current stat() / lstat() functionality is broken in Pharo. I've submitted an enhancement that fixes this, hopefully it will be merged in soon. :-) See https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Linux Cheers, Alistair > 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.
