How do I get a binary that reads files to start looking from the root directory or the folder it is in instead of the home folder? I'm using Suse 9.1 and when ever my programs(c++) read or write files they do so from my home dir not the folder they are in like windows. I can understand why it is like this but if someone could explain to me how I can get my programs to search for files a different way I would be very greatful.

You need to specify the path, e.g. prefix file names with the current directory tag './' to read them from the current directory.

Sample:
"./your_file.dat" instead of "your_file.dat"

Quote: Original post by onthetweek
How do I get a binary that reads files to start looking from the root directory or the folder it is in instead of the home folder?

I'm using Suse 9.1 and when ever my programs(c++) read or write files they do so from my home dir not the folder they are in like windows. I can understand why it is like this but if someone could explain to me how I can get my programs to search for files a different way I would be very greatful.

umm run it in that directory

Quote: Original post by darookie
You need to specify the path, e.g. prefix file names with the current directory tag './' to read them from the current directory.

Sample:
"./your_file.dat" instead of "your_file.dat"

I have tried your suggestion but without any success. Not being 100% certain about what you meant, I tried "./Data/Fonts/cour.ttf" "Data/Fonts./cour.ttf" "Data/Fonts/./cour.ttf" and other combinations aswell. These still look in my home folder for the files. I'm sure it's a stupid mistake that I'm making but I can't see what it is.

Generally speaking the program will look for files whereever you are when you start it. I guess you're launching it from a file manager?

Try using a combination of argv[0] and getcwd() you should be able to piece together the executable path from there and remove the last part, then chdir() to your new path.

-oddbot

Ok, part of my problem was that I was using a filemanager to run my programs. I'm kind of glad this happened, I have a better understanding of how to use the console now.

The Linux Way is to not do stuff like that. Everything should be installed to fixed paths. i.e. All my data will always be in /usr/share/myprogram/...

automake is good with handling this sort of thing, but that's probably a bigger change than you want to do right now.

Anything that involves doing relative paths is a hack. The least hacky way I know of is to readlink() /proc/self/exe, which will always get you the path to your executable, but only on linux, not bsd/etc.

Quote: Original post by C-Junkie
The Linux Way is to not do stuff like that. Everything should be installed to fixed paths. i.e. All my data will always be in /usr/share/myprogram/...

Exactly. The problem with storing it in the program directory is that you'll get in trouble with multiple users and access permissions. Each user will have to install his own copy of your program if you do that, because they can't access the home directory of another user.

Your programs generic data (the one that is user independent and read only, for example images, icons, ...) should be stored in a generally accessible location within usr/share. Usually, the install script/executable does that.

The user dependent information (eg config files) should be stored in ~/.myprogram, so that each user can have his own independent settings. These files and the subdir must be generated the first time you run the program from a new account, and filled with meaningful default values. You can also launch a config wizard, if you don't find the directory for the currently logged in user.

Separate user settings aren't very different in Windows, btw, just that most Windows programs aren't coded with multiple user capabilities in mind (because Windows used to be a single user system for a long time).