FileDirectory fails

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

FileDirectory fails

K K Subbu
Hi,

On the latest alpha, I see
{
  FileDirectory on: '.'.
  FileDirectory on: './test'.
  FileDirectory on: ''}

{UnixFileDirectory on '/.' . UnixFileDirectory on '/./test' .
UnixFileDirectory on '/'}

Anyone else see the same problems? What about on Macs?

The file tests are all green :-(.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

David T. Lewis
On Sat, Jun 13, 2020 at 07:32:37PM +0530, K K Subbu wrote:

> Hi,
>
> On the latest alpha, I see
> {
>  FileDirectory on: '.'.
>  FileDirectory on: './test'.
>  FileDirectory on: ''}
>
> {UnixFileDirectory on '/.' . UnixFileDirectory on '/./test' .
> UnixFileDirectory on '/'}
>
> Anyone else see the same problems? What about on Macs?
>
> The file tests are all green :-(.
>

Confirmed. It does not seem right to me, but it has been that way for
a long time. I just tried it on Squeak 3.8 and got the same results.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

Tobias Pape
In reply to this post by K K Subbu

> On 13.06.2020, at 16:02, K K Subbu <[hidden email]> wrote:
>
> Hi,
>
> On the latest alpha, I see
> {
> FileDirectory on: '.'.
> FileDirectory on: './test'.
> FileDirectory on: ''}
>
> {UnixFileDirectory on '/.' . UnixFileDirectory on '/./test' . UnixFileDirectory on '/'}
>
> Anyone else see the same problems? What about on Macs?
>
> The file tests are all green :-(.

This is actually the currently expected behavior.
What was your expectation?
-t

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

K K Subbu
On 13/06/20 7:47 pm, Tobias Pape wrote:

>
>> On 13.06.2020, at 16:02, K K Subbu <[hidden email]> wrote:
>>
>> Hi,
>>
>> On the latest alpha, I see
>> {
>> FileDirectory on: '.'.
>> FileDirectory on: './test'.
>> FileDirectory on: ''}
>>
>> {UnixFileDirectory on '/.' . UnixFileDirectory on '/./test' . UnixFileDirectory on '/'}
>>
>> Anyone else see the same problems? What about on Macs?
>>
>> The file tests are all green :-(.
>
> This is actually the currently expected behavior.
> What was your expectation?

Each one is a valid path.

'.' is lazily bound name for current directory. './test' is
#(dirname->'.' basename->'test') and '' (empty string) evaluates to '.'
in a directory context and an error in a file context since empty
filenames are not allowed. nil is not a valid path but commands do have
their own defaults ($HOME for chdir, '.' for ls, ..). E.g.

  $ cd . # remain in current directory
  $ cd '' # empty path. remain in current directory
  $ cd   # no directory specified. use $HOME
  $ ls ./test # list test in current directory
  $ ls test  # valid file but no dir. use current directory
  $ ls .  # valid dir but no file. list directory
  $ ls '' # empty path. cannot access '': No such file or directory
  $ ls    # no path specified. show all files in '.'
  $ ls -d  # no path specified. show dir info for '.'

Regards .. Subbu


Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

K K Subbu
In reply to this post by David T. Lewis
On 13/06/20 7:40 pm, David T. Lewis wrote:
> Confirmed. It does not seem right to me, but it has been that way
> for a long time. I just tried it on Squeak 3.8 and got the same
> results.

Thank you, Dave, for the confirmation.

Paths are used for vm, image, plugins and startup document. The first
three are handled by platform code, so paths are not an issue.

I was trying out startup documents from a different directory and
stumbled on these fails :-(.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

Levente Uzonyi
On Sat, 13 Jun 2020, K K Subbu wrote:

> On 13/06/20 7:40 pm, David T. Lewis wrote:
>> Confirmed. It does not seem right to me, but it has been that way
>> for a long time. I just tried it on Squeak 3.8 and got the same
>> results.
>
> Thank you, Dave, for the confirmation.
>
> Paths are used for vm, image, plugins and startup document. The first
> three are handled by platform code, so paths are not an issue.
>
> I was trying out startup documents from a different directory and
> stumbled on these fails :-(.

Why not use FileDirectory default / '.' instead of FileDirectory on: '.'?
The former does what you want, the latter does what's specified by the
tests. After a quick glimpse on #on:'s implementation, my impression is
that it expects an absolute path.


Levente

>
> Regards .. Subbu
>
>

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

David T. Lewis
In reply to this post by Tobias Pape
On Sat, Jun 13, 2020 at 04:17:21PM +0200, Tobias Pape wrote:

>
> > On 13.06.2020, at 16:02, K K Subbu <[hidden email]> wrote:
> >
> > Hi,
> >
> > On the latest alpha, I see
> > {
> > FileDirectory on: '.'.
> > FileDirectory on: './test'.
> > FileDirectory on: ''}
> >
> > {UnixFileDirectory on '/.' . UnixFileDirectory on '/./test' . UnixFileDirectory on '/'}
> >
> > Anyone else see the same problems? What about on Macs?
> >
> > The file tests are all green :-(.
>
> This is actually the currently expected behavior.
> What was your expectation?
> -t
>

If I delete the method UnixFileDirectory>>setPathName: then the behavior
is exactly what I would expect.

The setPathName: is an override for unix file systems. I don't know the
original motivation for that override, but its behavior does not seem
right to me. I'm going to leave it out of my working image for a while
and see if anything horrible happens.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

Tobias Pape

> On 13.06.2020, at 17:31, David T. Lewis <[hidden email]> wrote:
>
> On Sat, Jun 13, 2020 at 04:17:21PM +0200, Tobias Pape wrote:
>>
>>> On 13.06.2020, at 16:02, K K Subbu <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> On the latest alpha, I see
>>> {
>>> FileDirectory on: '.'.
>>> FileDirectory on: './test'.
>>> FileDirectory on: ''}
>>>
>>> {UnixFileDirectory on '/.' . UnixFileDirectory on '/./test' . UnixFileDirectory on '/'}
>>>
>>> Anyone else see the same problems? What about on Macs?
>>>
>>> The file tests are all green :-(.
>>
>> This is actually the currently expected behavior.
>> What was your expectation?
>> -t
>>
>
> If I delete the method UnixFileDirectory>>setPathName: then the behavior
> is exactly what I would expect.
>
> The setPathName: is an override for unix file systems. I don't know the
> original motivation for that override, but its behavior does not seem
> right to me. I'm going to leave it out of my working image for a while
> and see if anything horrible happens.

No no no :)
#on: is for Absolute stuff.

There is no real notion of a "current" directory in Squeak.
The closest is, as Levente points out, FileDirectory default. This typically is the right directory (meaning, image directory).



Best regards
        -Tobias

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

David T. Lewis
On Sat, Jun 13, 2020 at 06:58:18PM +0200, Tobias Pape wrote:

>
> > On 13.06.2020, at 17:31, David T. Lewis <[hidden email]> wrote:
> >
> > On Sat, Jun 13, 2020 at 04:17:21PM +0200, Tobias Pape wrote:
> >>
> >>> On 13.06.2020, at 16:02, K K Subbu <[hidden email]> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On the latest alpha, I see
> >>> {
> >>> FileDirectory on: '.'.
> >>> FileDirectory on: './test'.
> >>> FileDirectory on: ''}
> >>>
> >>> {UnixFileDirectory on '/.' . UnixFileDirectory on '/./test' . UnixFileDirectory on '/'}
> >>>
> >>> Anyone else see the same problems? What about on Macs?
> >>>
> >>> The file tests are all green :-(.
> >>
> >> This is actually the currently expected behavior.
> >> What was your expectation?
> >> -t
> >>
> >
> > If I delete the method UnixFileDirectory>>setPathName: then the behavior
> > is exactly what I would expect.
> >
> > The setPathName: is an override for unix file systems. I don't know the
> > original motivation for that override, but its behavior does not seem
> > right to me. I'm going to leave it out of my working image for a while
> > and see if anything horrible happens.
>
> No no no :)
> #on: is for Absolute stuff.

Well it would have to be so, given that the current behavior breaks
relative paths specifications on unix file systems.

>
> There is no real notion of a "current" directory in Squeak.

Yes, I understand.

> The closest is, as Levente points out, FileDirectory default. This typically is the right directory (meaning, image directory).
>

Right. And removing UnixFileDirectory>>setPathName: gives behavior that
handles relative path names with respect to FileDirectory default,
which is what I would have expected.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

Tobias Pape

> On 13.06.2020, at 19:07, David T. Lewis <[hidden email]> wrote:
>
> On Sat, Jun 13, 2020 at 06:58:18PM +0200, Tobias Pape wrote:
>>
>>> On 13.06.2020, at 17:31, David T. Lewis <[hidden email]> wrote:
>>>
>>> On Sat, Jun 13, 2020 at 04:17:21PM +0200, Tobias Pape wrote:
>>>>
>>>>> On 13.06.2020, at 16:02, K K Subbu <[hidden email]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On the latest alpha, I see
>>>>> {
>>>>> FileDirectory on: '.'.
>>>>> FileDirectory on: './test'.
>>>>> FileDirectory on: ''}
>>>>>
>>>>> {UnixFileDirectory on '/.' . UnixFileDirectory on '/./test' . UnixFileDirectory on '/'}
>>>>>
>>>>> Anyone else see the same problems? What about on Macs?
>>>>>
>>>>> The file tests are all green :-(.
>>>>
>>>> This is actually the currently expected behavior.
>>>> What was your expectation?
>>>> -t
>>>>
>>>
>>> If I delete the method UnixFileDirectory>>setPathName: then the behavior
>>> is exactly what I would expect.
>>>
>>> The setPathName: is an override for unix file systems. I don't know the
>>> original motivation for that override, but its behavior does not seem
>>> right to me. I'm going to leave it out of my working image for a while
>>> and see if anything horrible happens.
>>
>> No no no :)
>> #on: is for Absolute stuff.
>
> Well it would have to be so, given that the current behavior breaks
> relative paths specifications on unix file systems.
>
>>
>> There is no real notion of a "current" directory in Squeak.
>
> Yes, I understand.
>
>> The closest is, as Levente points out, FileDirectory default. This typically is the right directory (meaning, image directory).
>>
>
> Right. And removing UnixFileDirectory>>setPathName: gives behavior that
> handles relative path names with respect to FileDirectory default,
> which is what I would have expected.

What about paths with slashes in them?
-t


Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

K K Subbu
In reply to this post by Levente Uzonyi
On 13/06/20 8:36 pm, Levente Uzonyi wrote:
> Why not use FileDirectory default / '.' instead of FileDirectory on:
> '.'? The former does what you want, the latter does what's specified by
> the tests. After a quick glimpse on #on:'s implementation, my impression
> is that it expects an absolute path.

But a path like ./foo/bar is a complete path. The '.' is just a short cut.

A name like foo/bar is incomplete and needs a list of potential
directories (e.g. {vmPath . imagePath} which the path may be found.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

Jakob Reschke
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.

If on: expects an absolute path as Tobias said, you could also say it expects an already resolved path, which ./foo/bar is not.


K K Subbu <[hidden email]> schrieb am Sa., 13. Juni 2020, 20:01:
On 13/06/20 8:36 pm, Levente Uzonyi wrote:
> Why not use FileDirectory default / '.' instead of FileDirectory on:
> '.'? The former does what you want, the latter does what's specified by
> the tests. After a quick glimpse on #on:'s implementation, my impression
> is that it expects an absolute path.

But a path like ./foo/bar is a complete path. The '.' is just a short cut.

A name like foo/bar is incomplete and needs a list of potential
directories (e.g. {vmPath . imagePath} which the path may be found.

Regards .. Subbu


Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

Tobias Pape

> On 13.06.2020, at 22:22, Jakob Reschke <[hidden email]> 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.
>
> If on: expects an absolute path as Tobias said, you could also say it expects an already resolved path, which ./foo/bar is not.

Jakob is right.
-t

>
>
> K K Subbu <[hidden email]> schrieb am Sa., 13. Juni 2020, 20:01:
> On 13/06/20 8:36 pm, Levente Uzonyi wrote:
> > Why not use FileDirectory default / '.' instead of FileDirectory on:
> > '.'? The former does what you want, the latter does what's specified by
> > the tests. After a quick glimpse on #on:'s implementation, my impression
> > is that it expects an absolute path.
>
> But a path like ./foo/bar is a complete path. The '.' is just a short cut.
>
> A name like foo/bar is incomplete and needs a list of potential
> directories (e.g. {vmPath . imagePath} which the path may be found.
>
> Regards .. Subbu
>



Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

David T. Lewis
In reply to this post by Tobias Pape
On Sat, Jun 13, 2020 at 07:17:27PM +0200, Tobias Pape wrote:

>
> > On 13.06.2020, at 19:07, David T. Lewis <[hidden email]> wrote:
> >
> > Right. And removing UnixFileDirectory>>setPathName: gives behavior that
> > handles relative path names with respect to FileDirectory default,
> > which is what I would have expected.
>
> What about paths with slashes in them?
> -t
>

If you happen to have OSProcess/CommandShell loaded in your image, then
have a look at ShellSyntaxTestCase. For any kind of file path exxpansion
implemented in the image, those tests document my expections :-)

For example:

    ShellSyntaxTestCase>>testAppendPathToPath04
        | path |
        self unix ifTrue:
            [path := shellSyntax appendPath: '../bin/vi' toPath: '/usr/bin'.
            self should: [path = '/usr/bin/vi']]

So if FileDirectory default was '/usr/bin' and if I specified the relative path
'../bin/vi', then my expectation is that the path would resolve to '/usr/bin/vi'.

But we probably both agree that this kind of path expansion does not need to be
done in the image.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

K K Subbu
In reply to this post by Jakob Reschke
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

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

marcel.taeumel
Hi Subbu.

On Windows, you need a triple (drive, dirname, entry).

You could treat the "drive" as part of the "dirname", just like the leading "/" on Unix for the root path. The drive letter itself could be treated as a directory. Cygwin does this already (/cygdrive/c/...)

On Windows UNC paths  can be used to denote the "root" in a similar fashion:
 \\?\C:\...

So, every path that begins with "\\" can be treated as root.

Best,
Marcel

Am 14.06.2020 09:49:52 schrieb K K Subbu <[hidden email]>:

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



Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

K K Subbu
On 14/06/20 1:50 pm, Marcel Taeumel wrote:

>
>  > On Windows, you need a triple (drive, dirname, entry).
>
> You could treat the "drive" as part of the "dirname", just like the
> leading "/" on Unix for the root path. The drive letter itself could be
> treated as a directory. Cygwin does this already (/cygdrive/c/...)
>
> On Windows UNC paths  can be used to denote the "root" in a similar fashion:
>   \\?\C:\...
>
> So, every path that begins with "\\" can be treated as root.

Yes. With UNC, Windows paths may also be treated as (container, entry)
pairs. This would be handled in the Windows FilePlugin.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

marcel.taeumel
This would be handled in the Windows FilePlugin.

It supports UNC paths already.

Best,
Marcel

Am 14.06.2020 10:36:43 schrieb K K Subbu <[hidden email]>:

On 14/06/20 1:50 pm, Marcel Taeumel wrote:
>
> > On Windows, you need a triple (drive, dirname, entry).
>
> You could treat the "drive" as part of the "dirname", just like the
> leading "/" on Unix for the root path. The drive letter itself could be
> treated as a directory. Cygwin does this already (/cygdrive/c/...)
>
> On Windows UNC paths  can be used to denote the "root" in a similar fashion:
>  \\?\C:\...
>
> So, every path that begins with "\\" can be treated as root.

Yes. With UNC, Windows paths may also be treated as (container, entry)
pairs. This would be handled in the Windows FilePlugin.

Regards .. Subbu



Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

Tobias Pape

> On 14.06.2020, at 12:06, Marcel Taeumel <[hidden email]> wrote:
>
> > This would be handled in the Windows FilePlugin.
>
> It supports UNC paths already.
>
It actually forces them when necessary…
-t

> Best,
> Marcel
>> Am 14.06.2020 10:36:43 schrieb K K Subbu <[hidden email]>:
>>
>> On 14/06/20 1:50 pm, Marcel Taeumel wrote:
>> >
>> > > On Windows, you need a triple (drive, dirname, entry).
>> >
>> > You could treat the "drive" as part of the "dirname", just like the
>> > leading "/" on Unix for the root path. The drive letter itself could be
>> > treated as a directory. Cygwin does this already (/cygdrive/c/...)
>> >
>> > On Windows UNC paths  can be used to denote the "root" in a similar fashion:
>> >  \\?\C:\...
>> >
>> > So, every path that begins with "\\" can be treated as root.
>>
>> Yes. With UNC, Windows paths may also be treated as (container, entry)
>> pairs. This would be handled in the Windows FilePlugin.
>>
>> Regards .. Subbu
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory fails

marcel.taeumel
It actually forces them when necessary…

You mean "also", not "actually". :-)

So, from within Squeak you can either use UNC paths directly or provide a too long path string to the plugin, which will then convert it automatically to its UNC representation, if it isn't already in such a form.

Here are working examples:

PNGReadWriter formFromFileNamed: '\\?\C:\Tools\squeak_trunk\ffi-icons\ffi-union.png'
PNGReadWriter formFromFileNamed: 'C:\Tools\squeak_trunk\ffi-icons\ffi-union.png'
PNGReadWriter formFromFileNamed: 'C:\Tools\squeak_trunk\way-too-long-path\way-too-long-path\way-too-long-path\way-too-long-path\way-too-long-path\way-too-long-path\way-too-long-path\way-too-long-path\ffi-icons\ffi-union.png'

Best,
Marcel

Am 14.06.2020 12:13:51 schrieb Tobias Pape <[hidden email]>:


> On 14.06.2020, at 12:06, Marcel Taeumel wrote:
>
> > This would be handled in the Windows FilePlugin.
>
> It supports UNC paths already.
>
It actually forces them when necessary…
-t

> Best,
> Marcel
>> Am 14.06.2020 10:36:43 schrieb K K Subbu :
>>
>> On 14/06/20 1:50 pm, Marcel Taeumel wrote:
>> >
>> > > On Windows, you need a triple (drive, dirname, entry).
>> >
>> > You could treat the "drive" as part of the "dirname", just like the
>> > leading "/" on Unix for the root path. The drive letter itself could be
>> > treated as a directory. Cygwin does this already (/cygdrive/c/...)
>> >
>> > On Windows UNC paths can be used to denote the "root" in a similar fashion:
>> > \\?\C:\...
>> >
>> > So, every path that begins with "\\" can be treated as root.
>>
>> Yes. With UNC, Windows paths may also be treated as (container, entry)
>> pairs. This would be handled in the Windows FilePlugin.
>>
>> Regards .. Subbu
>>
>





12