Relative File Names (how to call them from anywhere?)

Started by
12 comments, last by leiavoia 18 years, 1 month ago
Quote:Original post by leiavoia
That's good for unix, but most windows games i played in years past usually come in one big lump with no installation (especially freebie games that you just unzip and run).


Lei,

As far as Windows games are concerned (commercial ones at least), the 'big lump' approach is beginning to more or less disappear these days. It seems a common practice now that the games will install themselves and the basic data into some directory of the user's choosing (usually C:\Program Files\ by default), but will put the user-specific data, like user preferences, saved games, and mods somewhere in the user's home directory (usually the My Documents folder). That way the user sort of sees the separation between the files he can mess without breaking the game, and those that should probably not be touched unless the user knows what he's doing.

But of course, for smaller games, especially ones that don't require installation, probably just one big lump is the best approach. Although, this needs a qualifier. It's probably still a good idea to organize your big lump. ;) Don't just stick all the files in the same directory as the executable, but, ya know, make like a "data" folder, or like a "models" folder, and what-not. It's probably obvious.

Also, regarding the shortcuts, you may have figured it out by now, but basically, whenever you open up a shortcut, your working directory will be the one where the shortcut is located, so it's the same as if you just opened up the prompt in that directory and ran the program from there without the whole cd bit.

So... I hope I helped clarify some things, instead of confusing them further. :)
Vovan
Advertisement
On linux though, it doesn't seem to work like that (much of the time). Usually if i click a shortcut or something to my own program, it won't find its (relative file name) resources. Thus bringing up the whole topic.
Quote:Original post by leiavoia
Usually if i click a shortcut or something to my own program, it won't find its (relative file name) resources.


Right, what I meant was that's more or less the way it works in Windows, too.

Also, I just had the following simple idea, which I think might work well, though I haven't thought about it too much yet, so it might have drawbacks I haven't considered. At the start of the program, take the first item in the argv's, and use everything before the last slash as a prefix for paths in all your file opening functions.

That should work, because whichever directory you are executing your binary from, that will be the base directory for all the relative paths you use. Since everything before the name of the bin will be the path to the bin, by prefixing it to all your hard-coded paths (or relative paths you get from a config file or what-not), you'll basically turn every path into one relative to the location of the bin (if that's what you want to do). So then you would be able to locate your resources wherever you run the executable from, and you wouldn't need to use any platform-specific WhereAmI functions. (Since file manipulation functions don't mind constructs like /path/to/bin/../data, you won't even need to do much parsing to handle that special case.)
Vovan
http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC23
Quote:1.14 How can I find a process' executable file?

This would be a good candidate for a list of `Frequently Unanswered Questions', because the fact of asking the question usually means that the design of the program is flawed. :-)

You can make a `best guess' by looking at the value of argv[0]. If this contains a `/', then it is probably the absolute or relative (to the current directory at program start) path of the executable. If it does not, then you can mimic the shell's search of the PATH variable, looking for the program. However, success is not guaranteed, since it is possible to invoke programs with arbitrary values of argv[0], and in any case the executable may have been renamed or deleted since it was started.

If all you want is to be able to print an appropriate invocation name with error messages, then the best approach is to have main() save the value of argv[0] in a global variable for use by the entire program. While there is no guarantee whatsoever that the value in argv[0] will be meaningful, it is the best option available in most circumstances.

The most common reason people ask this question is in order to locate configuration files with their program. This is considered to be bad form; directories containing executables should contain nothing except executables, and administrative requirements often make it desirable for configuration files to be located on different filesystems to executables.

A less common, but more legitimate, reason to do this is to allow the program to call exec() on itself; this is a method used (e.g. by some versions of sendmail) to completely reinitialise the process (e.g. if a daemon receives a SIGHUP).

1.14.1 So where do I put my configuration files then?

The correct directory for this usually depends on the particular flavour of Unix you're using; `/var/opt/PACKAGE', `/usr/local/lib', `/usr/local/etc', or any of several other possibilities. User-specific configuration files are usually hidden `dotfiles' under $HOME (e.g. `$HOME/.exrc').

From the point of view of a package that is expected to be usable across a range of systems, this usually implies that the location of any sitewide configuration files will be a compiled-in default, possibly using a `--prefix' option on a configure script (Autoconf scripts do this). You might wish to allow this to be overridden at runtime by an environment variable. (If you're not using a configure script, then put the default in the Makefile as a `-D' option on compiles, or put it in a `config.h' header file, or something similar.)

User-specific configuration should be either a single dotfile under $HOME, or, if you need multiple files, a dot-subdirectory. (Files or directories whose names start with a dot are omitted from directory listings by default.) Avoid creating multiple entries under $HOME, because this can get very cluttered. Again, you can allow the user to override this location with an environment variable. Programs should always behave sensibly if they fail to find any per-user configuration.

This topic is closed to new replies.

Advertisement