Hi,
problem is this part: '../e’
it has to be any of this:
('/a/b/c/d' asFileReference / '..' / 'e') path. "Path / 'a' / 'b' / 'c' / 'd' /
'..' / 'e'"
('/a/b/c/d' asFileReference parent / 'e') path. "Path / 'a' / 'b' / 'c' / 'e'"
the rationale is that “..” is not modelled as a special kind of node, just a
string.
and the reason is that that’s commonly like that, but it doesn’t *has to* be
like that… there could be file systems that interprets .. as a simple string.
and everything can be improved :)
Esteban
> 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)
> ! !
>
