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 <akgrant0710@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) ! !