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