Quote:

Original post by hydroo Well I personally would use argv[0]. If argv[0] appears to be a relative path you have to merge it with getcwd() ( your current working directory )

$ cat foo.c
#include <stdio.h>
int main(int argc, char *argv[]) {
  printf("%s\n", argv[0]);
  return 0;
}

$ make foo
$ /home/username/foo
/home/username/foo
$ mkdir somedir
$ cd somedir
$ ln -s ../foo bar
$ /home/username/somedir/bar
/home/username/somedir/bar

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
  char path[256];
  char id[256];
  sprintf(id, "/proc/%d/exe", getpid());
  readlink(id, path, 255);
  path[255] = '\0';
  printf("%s\n", path);
  return 0;
}

Quote:

Original post by let_bound Just as you wouldn't like a game storing its data in C:\usr\local\games\the-game on Windows, GNU/Linux users find it annoying when a program tries to behave like it's on Windows. There is a filesystem hierarchy, use it. Your application should behave properly, and not try to force the user to accept a behaviour alien to her system.

Quote:

Original post by Foxostro Quote: Original post by let_bound Just as you wouldn't like a game storing its data in C:\usr\local\games\the-game on Windows, GNU/Linux users find it annoying when a program tries to behave like it's on Windows. There is a filesystem hierarchy, use it. Your application should behave properly, and not try to force the user to accept a behaviour alien to her system. Ideally, I would like the game to be completely apathetic to where it is installed. Are you suggesting that I should avoid assuming that the executable is anywhere near the game's data? (Say, if game data was stored in /usr/local/share and the executable in /usr/local/bin)

Quote:

I'm already assuming that its OK to write data files like saved games and configuration settings to /home/user-name/.my-game's-name/ If this actually is acceptable, then maybe I'll just ask the user during installation what paths are appropriate and keep them in my setup.ini file.

• Your game is free/open source software (FOSS):
  
  
  
  • ./configure --prefix (or any other build system) will be used to determine the path to the executable and the data (it should default to /usr/local, configure does). The binary executables will be in ${prefix}/games/game_name/, the data in ${prefix}/share/games/game_name/, symlink to the executable binary/binaries if you want it/them in ${prefix}/bin/;
  
  
  • configure will define the prefix in config.h, so all you need to do is to include config.h in your code to know where to look for the data;
  
  
  • package maintainers of the various distros will modify your source code and build system to fit in their distro, and eventually submit their patches, so you don't have to worry about that as long as building your game can be done in a sensible way.
  
  
  
  


• Your game is proprietary:
  
  
  
  • I really shouldn't be helping you;
  
  
  • if the user is a lambda user (non-root):
    
    
    
    • have the prefix be /home/username by default (see above for subdirectories), and have the installer install there;
    
    
    • allow the user to specify another prefix (make sure it's writable);
    
    
    • write the prefix to /home/username/.yourgamerc or /home/username/.your_game/config, or something like that;
    
    
    
    
  
  
  • if the user is root ((e)uid = 0):
    
    
    
    • the prefix should be /usr/local/ by default, but you still want to allow root to specify another prefix;
    
    
    • make sure you can write to the directories (things like SELinux can and will deny permission to even root);
    
    
    • write the prefix to /etc/your_game/config, or /etc/yourgamerc, or anything you want under /etc (don't overwrite any existing file though);
    
    
    
    
  
  
  • When launched, have you game check for /etc/your_game/config (or /etc/yourgamerc) and /home/username/.your_game/config (or /home/username/.yourgamerc). Allow per-user configuration to override global configuration (useful if a user has installed add-ons, modded maps, or patched things while root was a lazy bastard ).
  
  
  
  

Quote:

Original post by Umesh G Tank Boost filesystem provides portable way of getting the current file path. boost::filesystem::path curPath = boost::filesystem::current_path(); std::string strPath = curPath.string(); std::cout<<strPath; this will give you the current directory path.