Hiura, but that defeats the whole purpose of relative paths. Isn't there a possibility to keep the working directory unchanged when using symbolic links?
It all depends on how you implement resources loading in your app. If it makes sense to use the working directory to load different files for different launch command, go ahead and you have nothing to do. I think it is useful for a marginal number of apps only.
Generally, you (the developer) create an app and its resources. Let's say you only need 'cat.png'. You will probably put that file in a subdirectory like 'res' and put you app (called 'lolcatz') in the same directory as 'res'. Let's assume we want to load that specific file and not another cat.png that could be relative to another working directory.
Then, in your code, you will do something like that:
sf::Texture cat;
cat.loadFromFile(resourcePath() + "cat.png");
(And check that the load command hasn't failed, of course.)
When you load the picture of cutty kitten, you don't care about absolute path. In fact, at this point, you don't want absolute path! You only know that the file is in the resources directory. So you call this 'resourcePath()' function that does the abstraction for you.
Now, you need the full path of your app to implement "correctly" (i.e. regarding the assumption made above) the 'resourcePath()' function.
There is another point to have this 'resourcePath' function which has nothing to do with working directory. So even if you're absolutely sure that using absolute path can always be avoided (on which I disagree ;-) you should still consider it for your app. Let me explain:
Assuming you want to load resource files depending on the current working directory but you know that all resource files are in a local folder called 'res'. Then your function can simply return './res/'. And remember that your function can return "./" (or something similar) if you don't need this
yet.
So even if you disagree that absolute path are required, you do want (or at least you should want) to have a little bit of abstraction here.
On Mac OS X we have 'bundle application'. That is, some kind of directory (that ends with .app) containing everything your app needs, or pretty much everything. From binary, to deps libs, and resources. With those application it make a lot of sense to use this 'resourcePath' function for the two reasons mentioned above (abstraction & full path).
I think
ln -s /full/path/to/my/program/exe MyShortcut
works as intended (and as on windows).
Nope, that doesn't work (at least on Mac, so I guess we can extend that to Unix). I didn't new symlink existed on Window, though.
ln -s /Users/m/Desktop/tmp/exe fulllnexe
m@mambp ~/D/t/inner> ./fulllnexe
Failed to load image "img.png". Reason : Unable to open file
Working directory: /Users/m/Desktop/tmp/inner~
BTW, I edited the code to use SFML in it. Just to convince you guys.
#include <unistd.h>
#include <iostream>
#include <SFML/Graphics.hpp>
int main(int, char**) {
char* pwd = getwd(NULL);
std::cout << "Working directory: " << pwd;
free(pwd);
sf::Image img;
img.loadFromFile("img.png");
return 0;
}
There
might exist a way to create some kind of symlink on Unix that guarantee to use a specific working directoy. But that all depends on the user at the end: will he do something stupid and launch you lolcatz app without this neat symlink?
On a side note, some software comes with a launch script that do something like that:
cd $(dirname "$0")
in order to get always the same working directory (i.e. the one containing the shell script in this case).
