In P3: FileSystem disk workingDirectory =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared In P7: FileSystem disk workingDirectory =>File @ /home/hilaire Is it a bug? -- Dr. Geo http://drgeo.eu
Le 15/12/2017 à 21:24, Hilaire a écrit :
In P3:
FileSystem disk workingDirectory =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared
In P7:
FileSystem disk workingDirectory =>File @ /home/hilaire
Is it a bug?
Hi! In Pharo 3 workingDirectory = imageDirectory. In Pharo 7 workingDirectory = directory from where Pharo was launched. Maybe you launched Pharo from the terminal with this command like this one? Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image If you wish to use the old behaviour, you can replace `FileSystem disk workingDirectory` by `FileLocator imageDirectory asFileReference`. This change was done because, not getting the real working directory make it really hard to script things in Pharo. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Thanks for the update Le 15/12/2017 à 21:34, Cyril Ferlicot D. a écrit :
If you wish to use the old behaviour, you can replace `FileSystem disk workingDirectory` by `FileLocator imageDirectory asFileReference`.
This change was done because, not getting the real working directory make it really hard to script things in Pharo.
-- Dr. Geo http://drgeo.eu
On 16 December 2017 at 04:34, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 15/12/2017 à 21:24, Hilaire a écrit :
In P3:
FileSystem disk workingDirectory =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared
In P7:
FileSystem disk workingDirectory =>File @ /home/hilaire
Is it a bug?
Hi!
In Pharo 3
workingDirectory = imageDirectory.
In Pharo 7
workingDirectory = directory from where Pharo was launched.
just double-checking... with equivalent shell commands... $ DIR1 = `pwd` $ $DIR2/pharo $DIR3/Pharo.image Pharo 3 ==> workingDirectory = $DIR3 Pharo 7 ==> workingDirectory = $DIR1 ? I wonder for such a semantic API change it might be good to introduce #workDirectory and deprecate #workingDirectory so the need for user-devs to change their code is more explicit. It might make easier to have an auto-conversion rule #workingDirectory ==> #imageDirectory, and make it harder to shoot yourself in the foot producing cross-platform libraries. cheers -ben
Maybe you launched Pharo from the terminal with this command like this one?
Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image
If you wish to use the old behaviour, you can replace `FileSystem disk workingDirectory` by `FileLocator imageDirectory asFileReference`.
This change was done because, not getting the real working directory make it really hard to script things in Pharo.
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Hi ben We should think about it. Indeed. Now about the names. I'm wondering if they cover well enough the situation. In fact I would like to have imageDirectory (it exists but not in FileSystem) and workingDirectory (I would prefer startupDirectory or something like that). For me workingDirectory is totally unclear. Now this change is super important for making Pharo a good platform for script execution. So let me make it even nicer. Stef On Fri, Dec 15, 2017 at 10:14 PM, Ben Coman <btc@openinworld.com> wrote:
On 16 December 2017 at 04:34, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 15/12/2017 à 21:24, Hilaire a écrit :
In P3:
FileSystem disk workingDirectory =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared
In P7:
FileSystem disk workingDirectory =>File @ /home/hilaire
Is it a bug?
Hi!
In Pharo 3
workingDirectory = imageDirectory.
In Pharo 7
workingDirectory = directory from where Pharo was launched.
just double-checking... with equivalent shell commands... $ DIR1 = `pwd` $ $DIR2/pharo $DIR3/Pharo.image
Pharo 3 ==> workingDirectory = $DIR3 Pharo 7 ==> workingDirectory = $DIR1 ?
I wonder for such a semantic API change it might be good to introduce #workDirectory and deprecate #workingDirectory so the need for user-devs to change their code is more explicit. It might make easier to have an auto-conversion rule #workingDirectory ==> #imageDirectory, and make it harder to shoot yourself in the foot producing cross-platform libraries.
cheers -ben
Maybe you launched Pharo from the terminal with this command like this one?
Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image
If you wish to use the old behaviour, you can replace `FileSystem disk workingDirectory` by `FileLocator imageDirectory asFileReference`.
This change was done because, not getting the real working directory make it really hard to script things in Pharo.
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
On 16 December 2017 at 16:02, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi ben
We should think about it. Indeed. Now about the names. I'm wondering if they cover well enough the situation. In fact I would like to have imageDirectory (it exists but not in FileSystem) and workingDirectory (I would prefer startupDirectory or something like that).
startupDirectory sounds like its where the startup scripts are kept, and common across many Images. For me workingDirectory is totally unclear.
Its a fairly well defined concept. Its starts as the shell directory where you type the command to run a program. https://en.wikipedia.org/wiki/Working_directory We should align with the operating system since file access is ultimately through system calls like fopen() where relative paths are ultimately affected by what the operating system considers to be the working directory (or do we *always* fully resolve paths in-Image and only pass absolute paths to fopen() ?) Here is a demonstration of working directory on Unix ... $ mkdir temp && cd temp $ cat << 'EOF' > testcwd.c #include <unistd.h> #include <stdio.h> char buf[1000]; int main() { printf("MYCWD=%s\n", getcwd(buf,1000)); } EOF $ gcc testcwd.c -o testcwd $ ./testcwd MYCWD=/home/ben/dev/temp $ cd .. $ temp/testcwd MYCWD=/home/ben/dev i.e. its the directory where the command was typed in to run the program. Since we build on Windows using Cygwin/Ming, its basically the same semantic for Windows. and even Win32 has similar function GetCurrentDirectory().... https://msdn.microsoft.com/en-us/library/windows/desktop/aa364934(v=vs.85).a... Now I guess confusion may arise when in Pharo you want to "change the working directory". if we only modify some in-Image instance variable? Then a difference of opinion might arise between Pharo and operating system calls as to what is the working-directory" when relative paths are used. Perhaps we should only refer to the operating system's current working directory. (Sorry I'm not in a position to dig into that right now) cheers -ben
Now this change is super important for making Pharo a good platform for script execution. So let me make it even nicer.
Stef
On Fri, Dec 15, 2017 at 10:14 PM, Ben Coman <btc@openinworld.com> wrote:
On 16 December 2017 at 04:34, Cyril Ferlicot D. <
cyril.ferlicot@gmail.com>
wrote:
Le 15/12/2017 à 21:24, Hilaire a écrit :
In P3:
FileSystem disk workingDirectory =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-
pharo3.0/shared
In P7:
FileSystem disk workingDirectory =>File @ /home/hilaire
Is it a bug?
Hi!
In Pharo 3
workingDirectory = imageDirectory.
In Pharo 7
workingDirectory = directory from where Pharo was launched.
just double-checking... with equivalent shell commands... $ DIR1 = `pwd` $ $DIR2/pharo $DIR3/Pharo.image
Pharo 3 ==> workingDirectory = $DIR3 Pharo 7 ==> workingDirectory = $DIR1 ?
I wonder for such a semantic API change it might be good to introduce #workDirectory and deprecate #workingDirectory so the need for user-devs to change their code is more explicit. It might make easier to have an auto-conversion rule #workingDirectory ==> #imageDirectory, and make it harder to shoot yourself in the foot producing cross-platform libraries.
cheers -ben
Maybe you launched Pharo from the terminal with this command like this one?
Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image
If you wish to use the old behaviour, you can replace `FileSystem disk workingDirectory` by `FileLocator imageDirectory asFileReference`.
This change was done because, not getting the real working directory make it really hard to script things in Pharo.
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
On Sat, Dec 16, 2017 at 12:01 PM, Ben Coman <btc@openinworld.com> wrote:
On 16 December 2017 at 16:02, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi ben
We should think about it. Indeed. Now about the names. I'm wondering if they cover well enough the situation. In fact I would like to have imageDirectory (it exists but not in FileSystem) and workingDirectory (I would prefer startupDirectory or something like that).
startupDirectory sounds like its where the startup scripts are kept, and common across many Images.
For me workingDirectory is totally unclear.
Its a fairly well defined concept. Its starts as the shell directory where you type the command to run a program. https://en.wikipedia.org/wiki/Working_directory
then we keep it.
We should align with the operating system since file access is ultimately through system calls like fopen() where relative paths are ultimately affected by what the operating system considers to be the working directory (or do we *always* fully resolve paths in-Image and only pass absolute paths to fopen() ?)
Here is a demonstration of working directory on Unix ...
$ mkdir temp && cd temp
$ cat << 'EOF' > testcwd.c #include <unistd.h> #include <stdio.h> char buf[1000]; int main() { printf("MYCWD=%s\n", getcwd(buf,1000)); } EOF
$ gcc testcwd.c -o testcwd
$ ./testcwd MYCWD=/home/ben/dev/temp
$ cd ..
$ temp/testcwd MYCWD=/home/ben/dev
i.e. its the directory where the command was typed in to run the program.
Since we build on Windows using Cygwin/Ming, its basically the same semantic for Windows. and even Win32 has similar function GetCurrentDirectory().... https://msdn.microsoft.com/en-us/library/windows/desktop/aa364934(v=vs.85).a...
Now I guess confusion may arise when in Pharo you want to "change the working directory". if we only modify some in-Image instance variable? Then a difference of opinion might arise between Pharo and operating system calls as to what is the working-directory" when relative paths are used.
Perhaps we should only refer to the operating system's current working directory. (Sorry I'm not in a position to dig into that right now)
cheers -ben
Now this change is super important for making Pharo a good platform for script execution. So let me make it even nicer.
Stef
On Fri, Dec 15, 2017 at 10:14 PM, Ben Coman <btc@openinworld.com> wrote:
On 16 December 2017 at 04:34, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 15/12/2017 à 21:24, Hilaire a écrit :
In P3:
FileSystem disk workingDirectory =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared
In P7:
FileSystem disk workingDirectory =>File @ /home/hilaire
Is it a bug?
Hi!
In Pharo 3
workingDirectory = imageDirectory.
In Pharo 7
workingDirectory = directory from where Pharo was launched.
just double-checking... with equivalent shell commands... $ DIR1 = `pwd` $ $DIR2/pharo $DIR3/Pharo.image
Pharo 3 ==> workingDirectory = $DIR3 Pharo 7 ==> workingDirectory = $DIR1 ?
I wonder for such a semantic API change it might be good to introduce #workDirectory and deprecate #workingDirectory so the need for user-devs to change their code is more explicit. It might make easier to have an auto-conversion rule #workingDirectory ==> #imageDirectory, and make it harder to shoot yourself in the foot producing cross-platform libraries.
cheers -ben
Maybe you launched Pharo from the terminal with this command like this one?
Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image
If you wish to use the old behaviour, you can replace `FileSystem disk workingDirectory` by `FileLocator imageDirectory asFileReference`.
This change was done because, not getting the real working directory make it really hard to script things in Pharo.
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Hi Ben, 2017-12-16 8:01 GMT-03:00 Ben Coman <btc@openinworld.com>:
On 16 December 2017 at 16:02, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi ben
We should think about it. Indeed. Now about the names. I'm wondering if they cover well enough the situation. In fact I would like to have imageDirectory (it exists but not in FileSystem) and workingDirectory (I would prefer startupDirectory or something like that).
startupDirectory sounds like its where the startup scripts are kept, and common across many Images.
For me workingDirectory is totally unclear.
Its a fairly well defined concept. Its starts as the shell directory where you type the command to run a program. https://en.wikipedia.org/wiki/Working_directory
Note that in R you can set the current working directory with setwd() and this is very common in R scripts. I like the idea around #imageDirectory and #vmStartupDirectory or just #vmDirectory. And maybe renaming #workingDirectory to #userWorkingDirectory would be more clear? Assuming 1 image = 1 user? Cheers, Hernán
Hi Hernán, On 18 January 2018 at 05:41, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Note that in R you can set the current working directory with setwd() and this is very common in R scripts.
I like the idea around #imageDirectory and #vmStartupDirectory or just #vmDirectory. And maybe renaming #workingDirectory to #userWorkingDirectory would be more clear? Assuming 1 image = 1 user?
In Pharo 7: FileLocator workingDirectory = C getcwd() # same as R and most languages FileLocator imageDirectory = the directory where the image is located FileLocator vmDirectory = the directory where the vm is located + several others FileLocator class>>workingDirectory: (i.e. setwd()) doesn't exist, but is straightforward to add. Pharo 6 has the same, but workingDirectory = imageDirectory. Cheers, Alistair
On 18 January 2018 at 14:33, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Hernán,
On 18 January 2018 at 05:41, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Note that in R you can set the current working directory with setwd() and this is very common in R scripts.
I like the idea around #imageDirectory and #vmStartupDirectory or just #vmDirectory. And maybe renaming #workingDirectory to #userWorkingDirectory would be more clear? Assuming 1 image = 1 user?
In Pharo 7:
FileLocator workingDirectory = C getcwd() # same as R and most languages FileLocator imageDirectory = the directory where the image is located FileLocator vmDirectory = the directory where the vm is located
I like the distinction of having all three. cheers -ben
On 18/01/18 20:11, Ben Coman wrote:
On 18 January 2018 at 14:33, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Hernán,
On 18 January 2018 at 05:41, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Note that in R you can set the current working directory with setwd() and this is very common in R scripts.
I like the idea around #imageDirectory and #vmStartupDirectory or just #vmDirectory. And maybe renaming #workingDirectory to #userWorkingDirectory would be more clear? Assuming 1 image = 1 user? In Pharo 7:
FileLocator workingDirectory = C getcwd() # same as R and most languages FileLocator imageDirectory = the directory where the image is located FileLocator vmDirectory = the directory where the vm is located I like the distinction of having all three.
cheers -ben
+1 Offray
On 19 Jan 2018, at 02:11, Ben Coman <btc@openInWorld.com> wrote:
On 18 January 2018 at 14:33, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Hernán,
On 18 January 2018 at 05:41, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Note that in R you can set the current working directory with setwd() and this is very common in R scripts.
I like the idea around #imageDirectory and #vmStartupDirectory or just #vmDirectory. And maybe renaming #workingDirectory to #userWorkingDirectory would be more clear? Assuming 1 image = 1 user?
In Pharo 7:
FileLocator workingDirectory = C getcwd() # same as R and most languages FileLocator imageDirectory = the directory where the image is located FileLocator vmDirectory = the directory where the vm is located
I like the distinction of having all three.
yes⦠but I would like an idiom to make declarations easier. for example, you made './somethingâ asFileReference â> this is a cwd path '{image}/somethingâ asFileReference â> image path etc. because right now I have to do: FileLocator imageDirectory / âsomething' and it annoys me a bit (not that I cannot live with it, but⦠) ;) Esteban
cheers -ben
+1 -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."
On 19 Jan 2018, at 02:11, Ben Coman <btc@openinworld.com> wrote:
On 18 January 2018 at 14:33, Alistair Grant <akgrant0710@gmail.com> wrote: Hi Hernán,
On 18 January 2018 at 05:41, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Note that in R you can set the current working directory with setwd() and this is very common in R scripts.
I like the idea around #imageDirectory and #vmStartupDirectory or just #vmDirectory. And maybe renaming #workingDirectory to #userWorkingDirectory would be more clear? Assuming 1 image = 1 user?
In Pharo 7:
FileLocator workingDirectory = C getcwd() # same as R and most languages FileLocator imageDirectory = the directory where the image is located FileLocator vmDirectory = the directory where the vm is located
I like the distinction of having all three.
cheers -ben
Hi Ben, On 15 December 2017 at 22:14, Ben Coman <btc@openinworld.com> wrote:
On 16 December 2017 at 04:34, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 15/12/2017 à 21:24, Hilaire a écrit :
In P3:
FileSystem disk workingDirectory =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared
In P7:
FileSystem disk workingDirectory =>File @ /home/hilaire
Is it a bug?
Hi!
In Pharo 3
workingDirectory = imageDirectory.
In Pharo 7
workingDirectory = directory from where Pharo was launched.
just double-checking... with equivalent shell commands... $ DIR1 = `pwd` $ $DIR2/pharo $DIR3/Pharo.image
Pharo 3 ==> workingDirectory = $DIR3 Pharo 7 ==> workingDirectory = $DIR1 ?
I wonder for such a semantic API change it might be good to introduce #workDirectory and deprecate #workingDirectory so the need for user-devs to change their code is more explicit. It might make easier to have an auto-conversion rule #workingDirectory ==> #imageDirectory, and make it harder to shoot yourself in the foot producing cross-platform libraries.
cheers -ben
I raised this concern when the change was first proposed. The only responses I saw were that it doesn't matter. Also, prior to Pharo 6, it was possible to change the working directory, so programs shouldn't have assumed that workingDirectory = imageDirectory.
Perhaps we should only refer to the operating system's current working directory. (Sorry I'm not in a position to dig into that right now)
Rajula wrote the code to allow the working directory to be updated, i.e. calling setwd(). I don't think it made it in to the submitted patch, but it obviously could be added in future. The working directory is cached (in DiskStore DefaultWorkingDirectory), but currently there is no way of changing the value, so effectively it is always the OS cwd. Cheers, Alistair
Now introducing a new name means that all the documentation, books, videos are obsolete. And this is a cost too. On Sat, Dec 16, 2017 at 5:03 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Ben,
On 15 December 2017 at 22:14, Ben Coman <btc@openinworld.com> wrote:
On 16 December 2017 at 04:34, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 15/12/2017 à 21:24, Hilaire a écrit :
In P3:
FileSystem disk workingDirectory =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared
In P7:
FileSystem disk workingDirectory =>File @ /home/hilaire
Is it a bug?
Hi!
In Pharo 3
workingDirectory = imageDirectory.
In Pharo 7
workingDirectory = directory from where Pharo was launched.
just double-checking... with equivalent shell commands... $ DIR1 = `pwd` $ $DIR2/pharo $DIR3/Pharo.image
Pharo 3 ==> workingDirectory = $DIR3 Pharo 7 ==> workingDirectory = $DIR1 ?
I wonder for such a semantic API change it might be good to introduce #workDirectory and deprecate #workingDirectory so the need for user-devs to change their code is more explicit. It might make easier to have an auto-conversion rule #workingDirectory ==> #imageDirectory, and make it harder to shoot yourself in the foot producing cross-platform libraries.
cheers -ben
I raised this concern when the change was first proposed. The only responses I saw were that it doesn't matter.
Also, prior to Pharo 6, it was possible to change the working directory, so programs shouldn't have assumed that workingDirectory = imageDirectory.
Perhaps we should only refer to the operating system's current working directory. (Sorry I'm not in a position to dig into that right now)
Rajula wrote the code to allow the working directory to be updated, i.e. calling setwd(). I don't think it made it in to the submitted patch, but it obviously could be added in future.
The working directory is cached (in DiskStore DefaultWorkingDirectory), but currently there is no way of changing the value, so effectively it is always the OS cwd.
Cheers, Alistair
Oh, in a build for a DrGeo app based on P7, the working directory is one level highter to the image folder. So in P7, there are two different results for the working directory: the user home directory, and one level hight to image dir. What's the context? Where to look at? -- Dr. Geo http://drgeo.eu
Also notice that OS can give program very surprising working directory when you run it using UI tools. For example in MacOS drag image to the vm using Finder assigns root (/) as working directory. 2017-12-15 21:38 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Oh, in a build for a DrGeo app based on P7, the working directory is one level highter to the image folder.
So in P7, there are two different results for the working directory: the user home directory, and one level hight to image dir.
What's the context? Where to look at?
-- Dr. Geo http://drgeo.eu
Hi Hilaire & Denis, On 18 January 2018 at 09:38, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Also notice that OS can give program very surprising working directory when you run it using UI tools. For example in MacOS drag image to the vm using Finder assigns root (/) as working directory.
2017-12-15 21:38 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Oh, in a build for a DrGeo app based on P7, the working directory is one level highter to the image folder.
So in P7, there are two different results for the working directory: the user home directory, and one level hight to image dir.
What's the context? Where to look at?
For Pharo 7: The working directory is C getcwd(). The differences you are seeing will be the result of how Pharo is launched. If you run it from the command line, it will be the current directory of the shell. I don't use MacOS, but it sounds like dragging a file to an executable always uses the root directory as cwd. The working directory is cached in DiskStore DefaultWorkingDirectory. It's set at session startup to DiskStore class>>defaultWorkingDirectory, which ultimately calls getcwd(). HTH, Alistair
Tx alistair this is great that we made progress on this point. May be we should update the fileSystem chapter Stef On Thu, Jan 18, 2018 at 9:51 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Hilaire & Denis,
On 18 January 2018 at 09:38, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Also notice that OS can give program very surprising working directory when you run it using UI tools. For example in MacOS drag image to the vm using Finder assigns root (/) as working directory.
2017-12-15 21:38 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Oh, in a build for a DrGeo app based on P7, the working directory is one level highter to the image folder.
So in P7, there are two different results for the working directory: the user home directory, and one level hight to image dir.
What's the context? Where to look at?
For Pharo 7:
The working directory is C getcwd(). The differences you are seeing will be the result of how Pharo is launched. If you run it from the command line, it will be the current directory of the shell. I don't use MacOS, but it sounds like dragging a file to an executable always uses the root directory as cwd.
The working directory is cached in DiskStore DefaultWorkingDirectory. It's set at session startup to DiskStore class>>defaultWorkingDirectory, which ultimately calls getcwd().
HTH, Alistair
Hi Stef, On 18 January 2018 at 18:43, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Tx alistair
this is great that we made progress on this point. May be we should update the fileSystem chapter
Yep. Can you point me to the source? I will try and take a look. I also think I'll add #workingDirectory: (be able to set the working directory). I know Rajula did the work, but it didn't make it in to the PR for some reason. Hopefully I can dig it up. Cheers, Alistair
On Thu, Jan 18, 2018 at 9:51 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Hilaire & Denis,
On 18 January 2018 at 09:38, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Also notice that OS can give program very surprising working directory when you run it using UI tools. For example in MacOS drag image to the vm using Finder assigns root (/) as working directory.
2017-12-15 21:38 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Oh, in a build for a DrGeo app based on P7, the working directory is one level highter to the image folder.
So in P7, there are two different results for the working directory: the user home directory, and one level hight to image dir.
What's the context? Where to look at?
For Pharo 7:
The working directory is C getcwd(). The differences you are seeing will be the result of how Pharo is launched. If you run it from the command line, it will be the current directory of the shell. I don't use MacOS, but it sounds like dragging a file to an executable always uses the root directory as cwd.
The working directory is cached in DiskStore DefaultWorkingDirectory. It's set at session startup to DiskStore class>>defaultWorkingDirectory, which ultimately calls getcwd().
HTH, Alistair
https://github.com/SquareBracketAssociates/DeepIntoPharo I will wait for the new version of pillar to port it. Right now I cannot latex it on my machine. Stef On Thu, Jan 18, 2018 at 7:25 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Stef,
On 18 January 2018 at 18:43, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Tx alistair
this is great that we made progress on this point. May be we should update the fileSystem chapter
Yep. Can you point me to the source? I will try and take a look.
I also think I'll add #workingDirectory: (be able to set the working directory). I know Rajula did the work, but it didn't make it in to the PR for some reason. Hopefully I can dig it up.
Cheers, Alistair
On Thu, Jan 18, 2018 at 9:51 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Hilaire & Denis,
On 18 January 2018 at 09:38, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Also notice that OS can give program very surprising working directory when you run it using UI tools. For example in MacOS drag image to the vm using Finder assigns root (/) as working directory.
2017-12-15 21:38 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Oh, in a build for a DrGeo app based on P7, the working directory is one level highter to the image folder.
So in P7, there are two different results for the working directory: the user home directory, and one level hight to image dir.
What's the context? Where to look at?
For Pharo 7:
The working directory is C getcwd(). The differences you are seeing will be the result of how Pharo is launched. If you run it from the command line, it will be the current directory of the shell. I don't use MacOS, but it sounds like dragging a file to an executable always uses the root directory as cwd.
The working directory is cached in DiskStore DefaultWorkingDirectory. It's set at session startup to DiskStore class>>defaultWorkingDirectory, which ultimately calls getcwd().
HTH, Alistair
participants (10)
-
Alistair Grant -
Ben Coman -
Cyril Ferlicot D. -
Denis Kudriashov -
Esteban Lorenzano -
Hernán Morales Durand -
Hilaire -
Offray Vladimir Luna Cárdenas -
Stephane Ducasse -
Tudor Girba