quote: Original post by YoshiN
And C-Junkie, I really don''t need your holier-than-thou attitude. I have my reasons for keeping the file in the same directory, and if you don''t like it I can tell you where to cram it.

I suppose I should point out that C-Junkie didn''t say anything about keeping the executable and data in the same directory specifically. He said not to rely on it (Windows-ism), and to figure out how Unix applications insulate themselves from environmental differences instead.

Details.

Oh, and Windows is "teh suck."

Seriously, though, there''s a reasong argv[0] gives you the path to the executable. That''s your portable solution right there. And did you know that Unix-style path separators work in C on any platform? Say goodbye to "\\" once and for all.

argv[0] actually only gives the invocation line of the executable.

In windows, I think it may always be a complete path. Not sure if its relative when you're using cmd.exe to run a program, and I don't feel like checking.

On unix, it will be whatever is typed. typing 'ls' at a terminal will make the argv[0] for ls be just 'ls' typing /bin/ls would be '/bin/ls' and so on and so forth.

argv[0] can't really be relied upon.

I'm really not sure how to figure out the location of the executable, since the general design pattern centers around where the user is not where the executable is, so there really isn't a mechanism for this. (afaik)

maybe check what the first line of /proc/self/maps is? it should be the executable, full path included. This might be linux-only, however.

[edit: also, argv[0] may point to a (symbolic|hard) link to your program. this is how things like busybox work even though everything is just a link to one executable. They check what argv[0] is and behave accordingly.]

[edited by - C-Junkie on October 20, 2003 4:59:07 PM]

#ifdef UNIXstd::string prefix("/usr/share/progname/");#else //WINDOWSstd::string prefix("");#endif //platform checkstd::ifstream in (prefix + std::string("file.txt")); 

That''s what I would recommend.

In a bash script, to find the directory the program resides in, you''d run "which programname", so I suppose running which argv[0] might do the trick.

quote: maybe check what the first line of /proc/self/maps is? it should be the executable, full path included. This might be linux-only, however.

There are systems other than linux on which this works, but it doesn''t generalize to all unices (or even most).

quote: Original post by Flarelocke
In a bash script, to find the directory the program resides in, you'd run "which programname", so I suppose running which argv[0] might do the trick.

"which" only searches directories that are in your PATH so unless you add your program directory to everyone's PATH that wants to use it that method will fail.

didn't someone post some function a while ago (possibly a few months) that would find the program path for you by examining /proc//something.. ? can't really remember the details and have no desire to hunt for it, but that might be useful.

edit: added "" to make more sense

[edited by - necromancer_df on October 21, 2003 7:16:39 PM]

I think (under Linux anyway) /proc/$(PID)/exe is a symlink to the executible, so you can figure out the executible directory from that.

And sticking the data in the same directory as the program is NOT good for portability... it''ll probably conflict with whatever filesystem division is set up... for example, check out http://www.pathname.com/fhs/