FileDirectory fails
Locked
12
12
 
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 > > |
|
|
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 |
|
|
> 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 |
|
|
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 |
|
|
> 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 |
|
|
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 |
|
|
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: |
|
|
> 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 > |
|
|
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 |
|
|
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 |
|
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
|
|
|
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 |
|
|
> This would be handled in the Windows FilePlugin. It supports UNC paths already. Best, Marcel
|
|
|
> 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 >> > |
|
|
> 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
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |