Why isn't the default directory of savefig() the folder where the file is?

pyplot
#1

Hello,

I expected the default directory for saving a figure is the same folder where the file is and found that this is not the case. So I have to specify a directory each time and it’s not very convenient for other users of my code when they run my code on their own machines. Is there a way to set the default directory? If not, how can I get the directory where the file is saved? Then I can change directory in a relative way.

Sorry if this is a silly question or doesn’t make much sense. Thanks!!

#2

What visualization package are you using?

#3

Sorry. I’m using pyplot.

#4

It’s not specific to any plotting packages or any file operations in general. Almost all file operations takes relative paths that are relative to the current directory, which has nothing to do with the current file being executed. The only exception I can think of is include, which uses the current toplevel file path since it’s more useful.

If you start julia from command line, the current directory should already be the directory you are in before starting julia. Otherwise (if you are on windows and clicked the icon to start julia) you can just cd into the right directory.

#5

I understand this is the case that the current directory is the directory pwd() returns in Julia terminal. But I don’t think this is very convenient. On the one hand, when one has all his/her files for a project in a folder, shouldn’t s/he expect the figure generated to be saved in the same folder for this project, not anywhere else. On the other hand, when an absolute path has to be given for a file to be saved in a place, the file is then not very portable. This is also quite irritating when people work on the same code for collaboration. That’s why I’m looking for an easiest way to specify a relative path.

Thanks!

#6

No. The location of the data has nothing to do with the location of the code, especially not with the top level file currently being evaluated. We provide @__FILE__ and @__DIR__ when you have a script that operate only on a project specific hard coded relative path.

#7

If you use Juno, you can specify the current work directory to be set to the current file’s folder, using the Julia dropdown menu. It will set the work directory thus automatically if you open Atom by opening a .jl file.

#8

No. The location of the data has nothing to do with the location of the code, especially not with the top level file currently being evaluated. We provide @FILE and @DIR when you have a script that operate only on a project specific hard coded relative path.

Thanks for the comments. I think this is all about the idealogy of design. For example, Matlab creates figures and save them in the directory where the file is. Could you please give me a concrete example for @FILE() and @DIR(). I don’t quite understand the explanation on http://docs.julialang.org/en/release-0.5/stdlib/file/

Thanks!

#9

Thanks for the hint. It works amazingly with Atom.

#10

e.g. put cd(dirname(@__FILE__())) at the top of your file

#11

Thanks a lot for the example. It works perfectly for my needs.

#12

Just to confirm - @DIR wasn’t included in 5.0, was it?

Could anyone let me know the difference between PROGRAM_FILE and @FILE? I added println(dirname(PROGRAM_FILE)) in a file and ran the file. But it doesn’t give me anything at the terminal.

#13

No, Matlab interprets relative paths with respect to the current working directory, just like Julia (and Python, I believe).

And rightly so. Now, if I want to do similar analysis on data in a different folder, is simply cd into the folder and rerun my code, confident that data will be saved to the correct relative position. It would be very inconvenient if I had to actually copy the code into each folder to achieve the same effect.

(There are of course multiple ways to achieve this, but I strongly support the status quo here.)

#14 
No, Matlab interprets relative paths with respect to the current working directory, just like Julia (and Python, I believe).

Well, you’re right. But note that each time you run a file, the current directory is automatically changed to the directory where the file is saved no matter where the working directory was. It’s equivalent to having the current directory sticking to the folder of the file.

I’m set now with Julia’s setting as I know how to change directory relatively. Thank you!

#15

This is not correct. Only if the file you are trying to run is not in the search path, Matlab will ask you whether you want to add it to the path or change the working path to the same path as where the file is located.

#16

Are you really sure this is the wisest course of action?

Changing your current working directory for each set of data can make a lot of sense. Changing it to the location of your code is a lot more questionable, in my opinion.

Remember, it is likely that you will run the same code on many different datasets. Will you move the code around to match the location of your data? Isn’t it better to let your code work relative to whatever is the current working directory, and leave it up to the user to change directory for each dataset? (Edit: I guess you could move your data to the location of your code, but that too seems awkward to me.)

I know that I, as a user, certainly do not appreciate it when scripts start changing my working directory. I suggest that you at least automatically change the directory back after the script has finished running.

#17

This is not correct. Only if the file you are trying to run is not in the search path, Matlab will ask you whether you want to add it to the path or change the working path to the same path as where the file is located.

Yes, you’re right. Does Julia change the current directory if the file that I’m running is not in the paths? I guess not and this will remain not in the future?

Changing your current working directory for each set of data can make a lot of sense. Changing it to the location of your code is a lot more questionable, in my opinion.

Remember, it is likely that you will run the same code on many different datasets. Will you move the code around to match the location of your data? Isn’t it better to let your code work relative to whatever is the current working directory, and leave it up to the user to change directory for each dataset? (Edit: I guess you could move your data to the location of your code, but that too seems awkward to me.)

You’re absolutely right when you have many sets of data located in different places and they’re to be processed by a same file. However, I’m collaborating with others on a paper using GIT and the Julia code and the TeX files are located in two sub-folders of the main directory of this project. In other words, the relative location of these two sub-folders are fixed. We wish the figures generated by our Julia code to be saved in the sub-folder where our TeX files are. Then after my collaborators check out the updates each time, they can run the code straight away, expecting the figures are saved in the correct location that they can compile the tex file without relocating the figures. That’s why I need relative locations in this case. Hope that I have made my case understandable.

I know that I, as a user, certainly do not appreciate it when scripts start changing my working directory. I suggest that you at least automatically change the directory back after the script has finished running.

This is a good point. Now I add a line at the end of my code to change my directory back after saving the figures in the desired location.

Thank you!

#18

Changing working directory only affects the current process, so there’s no need for this: a Julia script can only affect its own working directory, not that of its parent process. (This is why cd must be a shell built-in and cannot be a normal program.)

#19

Fair enough. Point taken.

Sorry. Didn’t see your comment. Thanks a lot!