On 29 March 2017 at 14:02, Alistair Grant <akgrant0...@gmail.com> wrote:
> Except that ".." is treated as a special case at the moment in
> Path class>>addParentElementTo:, which is why #resolve: does the right
> thing (well, at least in my opinion :-)).
>
Well, not according to shell commands :
ls ./nonexistentdirectory/.. → cannot access, no such file or directory
So we have a divergence between FileSystem, where .. means "cancel the last
path segment, syntactically, without even checking the actual files and
directories" and the behavior of the shell command (and thus of the
underlying system call, I guess) which attempts to actually resolve each
segment and fails because it cannot go and look inside nonexistentdirectory
for the entry named '..'
This becomes important with symbolic links : try ls ./somesymlink/.. and
you'll see that you don't get the contents of $PWD but of the parent of the
symlink's destination.
> I'm having trouble understanding the Path class comments, however:
>
> "#* and #/ are mnemonic to . and /
> whose arguments should be string file- or directory names, not
> fragments of Unix path notation intended to be parsed."
>
> seems to imply that segments should not contain the delimiter (/), and
> the current implementation leaves the delimiter in the segment.
>
Yes. The point is, if you have an API that tries to be clever and guesses
what you meant (e.g. you could pass '../foo/bar' as a path element, it
might be convenient most of the time, but you lose control of what you
mean: the API, because it interprets the strings you pass, will make it
difficult or impossible to express some paths. For instance, on my current
filesystem, I can create a file named foo\bar. I'm guessing that's
impossible on Windows… It also leads to quoting, escaping, case sensitivity
and such problems (try writing shell scripts that are robust to file names
with spaces…)
The alternative is to have an API that does what you tell it to, no more,
no less. It should consider that if you pass a string with special
characters, you meant to have those characters in the result. Maybe that's
impossible on some filesystems, and raises an error, but the API will not
decide to do something different than you asked.
> >> On 29 Mar 2017, at 12:21, Alistair Grant <akgrant0...@gmail.com> wrote:
> >>
> >> Hi All,
> >>
> >> The current implementation of Path>>/, while functional, seems to me to
> >> create poorly formed paths, e.g.:
> >>
> >> ('/a/b/c/d' asFileReference / '../e') path ==> "Path / 'a' / 'b' / 'c'
> >> / 'd' / '../e'"
> >>
> >> As can be seen above, the last segment is '../e'.
> >>
> >> I would expect the result to be:
> >>
> >> "Path / 'a' / 'b' / 'c' / 'e'"
> >>
> >> Is there a reason for the current behaviour? If not, are people open to
> >> modifying Path>>/ to produce the suggested result above (in Pharo 7)?
> >>
> >> The method below produces the modified result above and doesn't change
> >> the result of running all automated tests. If this is going to be added
> >> to Pharo 7 I'll create an additional automated test to check that it is
> >> working properly.
> >>
> >> Cheers,
> >> Alistair
> >>
> >> 'From Pharo6.0 of 13 May 2016 [Latest update: #60451] on 29 March 2017
> >> at 9:40:41.681228 am'!
> >>
> >> !Path methodsFor: 'navigating' stamp: 'AlistairGrant 3/29/2017 09:39'!
> >> / aString
> >> | path |
> >>
> >> aString isEmptyOrNil
> >> ifTrue: [ Error signal: 'Path element cannot be empty or nil'].
> >>
> >> ^self resolve: (Path from: aString)
> >> ! !
>
>
--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet
