[squeak-dev] FileDirectory fails

K K Subbu kksubbu.ml at gmail.com
Sun Jun 14 07:49:36 UTC 2020


On 14/06/20 1:52 am, Jakob Reschke wrote:
> Even though the . stands for the current directory (whatever that is), 
> still ./foo/bar is a relative path. It cannot be resolved without 
> another value (the current or default directory) and is quite literally 
> relative to that.
Jakob,

It is not about a path being relative or absolute. Those concepts apply 
within the OS filesystem. It is about whether a path specification is 
complete or not. On Unix, a path is a pair (dirname, basename/entry). On 
Windows, you need a triple (drive, dirname, entry).

Squeak depends on a plugin to access files and needs to give out 
*complete* pathnames. Since the vm and plugins share the same OS process 
and the CWD (getcwd()) is a property of the OS process, there is no need 
for the vm to resolve '.' to CWD before handing it over to the plugin. 
In that sense, './foo/bar' is a complete pathname.

On the other hand, the path 'SourcesV50.sources' is incomplete (dirname 
missing) and should not be passed to plugin. The image has to resolve 
this file in imagePath, vmPath or getcwd() directories before passing it 
to the plugin.

Also, an absolute path like '/foo/bar' is an ambiguous object - is it 
(/foo/bar, *) or is it (/foo, bar)? Right now, the image treats it like 
latter :-( working purely at string level instead of semantic level.

  FileDirectory splitName: '/usr/lib' to: [:dirname :basename |
	{dirname. basename}]  #('/usr' 'lib')

  FileDirectory splitName: '/usr/lib/' to: [:dirname :basename |
	{dirname. basename}]  #('/usr/lib' '')

FileDirectory>>root returns ''. This is to coverup absolute path '/' 
being parsed as ('', '/').

Regards .. Subbu


More information about the Squeak-dev mailing list