Need help with relative file path

[=?ISO-8859-1?Q?Thomas_B=F8rlum?=]

Hey all,

I'm writing a c++ program that needs to read a file. I'm trying to read
a file that is in the same directory as the executable.

Everything works fine if I execute the program while in the program's
directory. What I need to do is read that file regardless of where
(cwd) I execute the program from, without hardcoding the absolute since
the program might be moved or be in differant locations on other
computers.

What should I do?

PS. I'm using the boost filesystem framework if it helps.

[Martin York]

On Jun 21, 8:11*am, Thomas Børlum <[e-mail]:

Hey all,

I'm writing a c++ program that needs to read a file. I'm trying to read
a file that is in the same directory as the executable.

Everything works fine if I execute the program while in the program's
directory. What I need to do is read that file regardless of where
(cwd) I execute the program from, without hardcoding the absolute since
the program might be moved or be in differant locations on other
computers.

What should I do?

PS. I'm using the boost filesystem framework if it helps.

Most OS's will give you the command used to execute your program in
argv[0]
This will usually include the path

int main(int argc,char* argv[])
{
std::cout << argv[0] << "\n\n";
}

NB. It may be absolute or relative.

[Juha Nieminen]

Martin York wrote:

Most OS's will give you the command used to execute your program in
argv[0]
This will usually include the path

Actually it's rather usual that argv[0] is simply what you wrote in
the command line as the program's name, without any additions.

[=?ISO-8859-1?Q?Thomas_B=F8rlum?=]

On 2008-06-21 17:50:33 +0200, Martin York <Ma***************@gmail.comsaid:

On Jun 21, 8:11*am, Thomas Børlum <[e-mail]:

>Hey all,

I'm writing a c++ program that needs to read a file. I'm trying to read
a file that is in the same directory as the executable.

Everything works fine if I execute the program while in the program's
directory. What I need to do is read that file regardless of where
(cwd) I execute the program from, without hardcoding the absolute since
the program might be moved or be in differant locations on other
computers.

What should I do?

PS. I'm using the boost filesystem framework if it helps.

Most OS's will give you the command used to execute your program in
argv[0]
This will usually include the path

int main(int argc,char* argv[])
{
std::cout << argv[0] << "\n\n";
}

NB. It may be absolute or relative.

Thanks that got me on the right track. I've done the following:

path program_path(string(argv[0]) + "/..");
program_path = complete(program_path);
string settings_file = program_path.string() + "/settings.txt";

works great.

[James Kanze]

On Jun 21, 5:50 pm, Martin York <[e-mail]:

On Jun 21, 8:11 am, Thomas Børlum <[e-mail]:

I'm writing a c++ program that needs to read a file. I'm
trying to read a file that is in the same directory as the
executable.

Everything works fine if I execute the program while in the
program's directory. What I need to do is read that file
regardless of where (cwd) I execute the program from,
without hardcoding the absolute since the program might be
moved or be in differant locations on other computers.

What should I do?

PS. I'm using the boost filesystem framework if it helps.

Most OS's will give you the command used to execute your
program in argv[0] This will usually include the path

First, of course: I'm not sure what you mean by "most OS's", but
Unix certainly doesn't, and IIRC, nor does Windows. Unix, at
any rate, gives you whatever the invoking program decides.
(Note that this is NOT conform to the C or C++ standards;
strictly speaking, a conforming implementation of C or C++ is
impossible under Unix, and I'm pretty sure under Windows as
well.)

Secondly, of course, it's quite exceptional, both under Unix and
under Windows, for the invoking command to include the path.
In these two systems, the actual path is normally obtained from
an environment variable.

int main(int argc,char* argv[])
{
std::cout << argv[0] << "\n\n";
}

NB. It may be absolute or relative.

Most of the time, it's relative from some arbitrary entry in the
PATH environment variable.

I've encountered this problem several times in the past; at
least under Unix, there is no possible solution from within the
program.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 21, 6:21 pm, Juha Nieminen <[e-mail]:

Martin York wrote:

Most OS's will give you the command used to execute your program in
argv[0]
This will usually include the path

Actually it's rather usual that argv[0] is simply what you
wrote in the command line as the program's name, without any
additions.

That's more or less what the standard requires. Under Unix, of
course, this only works if the shell used to start the command
collaborates (most do). And it leaves open the question as to
what should be in argv[0] if the command is not started from the
command line, but from some other program.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Paavo Helde]

Thomas Børlum <bo****@gmail.comkirjutas:

Hey all,

I'm writing a c++ program that needs to read a file. I'm trying to read
a file that is in the same directory as the executable.

Everything works fine if I execute the program while in the program's
directory. What I need to do is read that file regardless of where
(cwd) I execute the program from, without hardcoding the absolute since
the program might be moved or be in differant locations on other
computers.

What should I do?

PS. I'm using the boost filesystem framework if it helps.

On Windows, getting the directory where the executable file is located is
easy (GetModuleFileName(NULL, ...)). On Linux/Unix it's much harder, for
starters the problem is not uniquely defined (you can have hardlinks to the
same inode in different directories). One can mimick it to some extent by
using argv[0], cwd() and which/PATH, but this requires collaboration by the
caller, as already mentioned by other responders.

Paavo

[Juha Nieminen]

James Kanze wrote:

On Jun 21, 6:21 pm, Juha Nieminen <[e-mail]:

>Martin York wrote:

>>Most OS's will give you the command used to execute your program in
argv[0]
This will usually include the path

>Actually it's rather usual that argv[0] is simply what you
wrote in the command line as the program's name, without any
additions.

That's more or less what the standard requires. Under Unix, of
course, this only works if the shell used to start the command
collaborates (most do). And it leaves open the question as to
what should be in argv[0] if the command is not started from the
command line, but from some other program.

Also, if I'm not mistaken, the C standard doesn't actually guarantee
that argv[0] will contain anything at all (although I don't remember if
that means that argv[0] could actually be a null pointer, or if it
simply means that it points to an empty string).

I assume the C++ standard inherits the same specification.

[emarcari]

On Jun 21, 12:11 pm, Thomas Børlum <[e-mail]:

Hey all,

I'm writing a c++ program that needs to read a file. I'm trying to read
a file that is in the same directory as the executable.

Everything works fine if I execute the program while in the program's
directory. What I need to do is read that file regardless of where
(cwd) I execute the program from, without hardcoding the absolute since
the program might be moved or be in differant locations on other
computers.

What should I do?

PS. I'm using the boost filesystem framework if it helps.

You may use getenv, doing something like this:
std::string source_dir = getenv( "srcdir" );

Look at http://www.cplusplus.com/reference/c...ib/getenv.html,
that there are another examples.

[Paavo Helde]

"Alf P. Steinbach" <al***@start.nokirjutas:

* James Kanze:

[...]

>Of course, this requirement is ignored more often than it is
met; Unix doesn't make the program name available in any shape,
form or fashion, and I don't think Windows does either,

Huh?

From Windows SDK documentation:

LPTSTR WINAPI GetCommandLine(void);

The return value is a pointer to the command-line string for the current
process.
....
Note The name of the executable in the command line that the operating
system provides to a process is not necessarily identical to that in the
command line that the calling process gives to the CreateProcess
function. The operating system may prepend a fully qualified path to an
executable name that is provided without a fully qualified path.

So it seems Windows makes it available in some shape or fashion ;-)

Regards
Paavo

[James Kanze]

On Jun 27, 7:15 pm, Paavo Helde <[e-mail]:

"Alf P. Steinbach" <[e-mail]:

* James Kanze:

[...]

Of course, this requirement is ignored more often than it
is met; Unix doesn't make the program name available in any
shape, form or fashion, and I don't think Windows does
either,

Huh?

From Windows SDK documentation:

LPTSTR WINAPI GetCommandLine(void);

The return value is a pointer to the command-line string for
the current process.

And when the process wasn't started from a command line?

...
Note The name of the executable in the command line that the
operating system provides to a process is not necessarily
identical to that in the command line that the calling process
gives to the CreateProcess function. The operating system may
prepend a fully qualified path to an executable name that is
provided without a fully qualified path.

So it seems Windows makes it available in some shape or
fashion ;-)

I seem to recall experimenting at one time with Windows, and
seeing exactly the behavior I got from Unix. And if I
understand the documentation of CreateProcess correctly, if I
call it with something like:

CreateProcess( "C:\\Hidden\\even more hidden\\myProg.exe",
"C:\\Documents and Settings\\James Kanze\\...",
// all the rest of the verbage...
) ;

GetCommandLine is going to return the second string, which
doesn't begin to give the slightest hint about where the actual
executable is situated. (On the other hand, given the number of
functions in the Windows interface, it wouldn't surprise me if
there wasn't one to return the first argument to CreateProcess
as well. And from the documentation, that might be enough.)

In sum, it's exactly like the situation in Unix: if the invoking
program collaborates (and the various command interpreters
generally do), then it works, but everything depends on the
invoking program.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Joe Greer]

James Kanze <ja*********@gmail.comwrote in news:c069673d-4ce6-401b-b340-
3a**********@y21g2000hsf.googlegroups.com:

>
GetCommandLine is going to return the second string, which
doesn't begin to give the slightest hint about where the actual
executable is situated. (On the other hand, given the number of
functions in the Windows interface, it wouldn't surprise me if
there wasn't one to return the first argument to CreateProcess
as well. And from the documentation, that might be enough.)

GetModuleName() with a NULL will give you the exe-s name, but this
digresses from the topic. :)

joe

[Paavo Helde]

James Kanze <ja*********@gmail.comkirjutas:

On Jun 27, 7:15 pm, Paavo Helde <[e-mail]:

>"Alf P. Steinbach" <[e-mail]:

* James Kanze:

[...]

>Of course, this requirement is ignored more often than it
is met; Unix doesn't make the program name available in any
shape, form or fashion, and I don't think Windows does
either,

Huh?

>From Windows SDK documentation:

>LPTSTR WINAPI GetCommandLine(void);

>The return value is a pointer to the command-line string for
the current process.

And when the process wasn't started from a command line?

>...
Note The name of the executable in the command line that the
operating system provides to a process is not necessarily
identical to that in the command line that the calling process
gives to the CreateProcess function. The operating system may
prepend a fully qualified path to an executable name that is
provided without a fully qualified path.

>So it seems Windows makes it available in some shape or
fashion ;-)

I seem to recall experimenting at one time with Windows, and
seeing exactly the behavior I got from Unix. And if I
understand the documentation of CreateProcess correctly, if I
call it with something like:

CreateProcess( "C:\\Hidden\\even more hidden\\myProg.exe",
"C:\\Documents and Settings\\James Kanze\\...",
// all the rest of the verbage...
) ;

GetCommandLine is going to return the second string, which
doesn't begin to give the slightest hint about where the actual
executable is situated. (On the other hand, given the number of
functions in the Windows interface, it wouldn't surprise me if
there wasn't one to return the first argument to CreateProcess
as well. And from the documentation, that might be enough.)

In sum, it's exactly like the situation in Unix: if the invoking
program collaborates (and the various command interpreters
generally do), then it works, but everything depends on the
invoking program.

I read the documentation of Windows CreateProcess(), and it seems kind of
a serious hacking attempt. I cannot understand from the documentation if
the first and second argument are joined or not, and what is visible in
GetCommandLine(). But of course, this does not surprise me at least.

In any case, as GetModuleBaseName(...,NULL,...) gives the full path of
the executable file which was used for starting the process, one does not
have to worry too much about GetCommandLine().

Sorry about wandering off-topic!

Paavo