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.

Dave