[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
|