[squeak-dev] FileDirectory fails

Tobias Pape Das.Linux at gmx.de
Sat Jun 13 17:17:27 UTC 2020


> On 13.06.2020, at 19:07, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> On Sat, Jun 13, 2020 at 06:58:18PM +0200, Tobias Pape wrote:
>> 
>>> On 13.06.2020, at 17:31, David T. Lewis <lewis at mail.msen.com> wrote:
>>> 
>>> On Sat, Jun 13, 2020 at 04:17:21PM +0200, Tobias Pape wrote:
>>>> 
>>>>> On 13.06.2020, at 16:02, K K Subbu <kksubbu.ml at gmail.com> 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



More information about the Squeak-dev mailing list