On Fri, May 25, 2012 at 05:59:17PM -0700, Sean P. DeNigris wrote: > > Igor Stasenko wrote > > > > we should integrate the chdir fix to osprocess > > into jenkins vms > > > > Oops, I took the error handler off the wrong call... > > ??OSProcess thisOSProcess chDir: ospPwd. > should have been > > ??[ OSProcess thisOSProcess chDir: ospPwd ] on: Exception do: []. > > And, the question still stands as to whether OSP and FS should have two > separate concepts of the working directory...
Yes. They probably represent different concepts, so it is OK if they are implemented differently. What is a "working directory"? And for that matter, what is a "directory"? These are concepts and metaphors that have been used in various ways by some (but not all) operating systems, and that do not automatically have a well defined meaning independent of those metaphors and operating systems. There is really no such thing as "current working directory" in Squeak/Pharo, so if you want to create such a concept you are free to do so in any way you please. With respect to OSProcess, it is intentionally maintained separately from Squeak/Pharo and IMO should remain that way. It provides access to the external platform, which is useful. But the metaphorical desktop objects (files, desktops, file folders, etc) are artifacts of various operating systems and computing traditions, and there is no "right way" to represent the concept of a current working directory. OSProcess attempts to report CWD from the point of view of the external platform, but that does not make it right. It is perfectly legitimate for FS to define a concept of current working directory, and hopefully this would have a clear definition in terms of how it is to be used in the image. But there is no reason to expect that this definition of "current working directory" will be the same as the "current working directory" as understood by Unix, Windows, Android, or other computing platforms, some of which may not have any concept of "directory" at all. CommandShell also has a concept of current working directory, and this is also different from the CWD of OSProcess. CommandShell attempts to behave more like a shell, and when running on Windows it keeps track of the current volume (C: drive, D: drive, etc) in addition to the current working directory path associated with each volume. Again, then is platform dependent, and there is no particular reason to expect this concept of "current working directory" to make sense outside of the operating system that it is emulating. Dave
