On 2012-05-26, at 06:41, David T. Lewis wrote: > 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.
I don't think so... if we can unify them we should! And in this case I would say its simply a matter of calling the right c-function? And I would even say by solely relying on the OS' working directory implementation you can avoid some nasty issues we have with the working directory right now. For instance on OSX the whole thing doesn't behave that nicely. > 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. well on all unix there is a very clear precise definition of it "getcwd()"! and on all decent platforms there's a more or less clear notion of what is a file and what is a directory? Talking about Pharo, which platforms do we target? - Linux - OS X - Win maybe I am wrong, but I think we could assume a common denominator here? (Using python and ruby yields to the same results AFAIK) > 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. Indeed specific locations are to be modeled differently, see FileLocator for that reason. > 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 > >
