UNIX: Calling exec on the parent process after a fork

Question

Hello,

I am writing in my grammar, in LEX, some code to fork() my process and run a child. The child actually gets some input from the parent, and then returns a result.

I need to call exec on the same binary that loaded the parent, but there I am having an issue. I know that exec does not mean complete sense, but I do this because I have some previous grammar in LEX that I simply want to get rid off, so reloading the process is easier.

I have the following code in the children, after the fork():

char *path = strdup(getenv("PWD"));
size_t size = strlen(path) + strlen("/shell") + 1;
path = (char *) realloc(path, sizeof(char) * size);
path = strcat(path, "/shell");

// call exec
execl(path, NULL);

The issue with this code, is that it works if the process is launched from the same directory, but if I try to load from a folder within this directory, like say, ../shell, then the path is actually wrong, it will include this directory.

I would like to please know how I could get the correct path of the process, and if there is a way to also get the process actual name please? I have looked at the environments variable but have not found anything useful.

Thank you very much,

Jary

Answer 1

The objective, as I understand it, it to have the child process re-execute the same program that represents the parent process.

In the absence of tricks using data from the /proc file system, I don't believe there is a completely reliable way to do it.

Normally, you rely on the value of argv[0] being sufficient to find the program, and use execvp() to find the program via $PATH.

Attempt 2 - maybe less confusing

I will rephrase [the question] if you don't mind: Right now, execl() does execute the binary, but only if I load the parent directly from its folder. If I go in a subfolder, let's call it fd, then the path will be "correctPath/fd/shell" rather than "correctPath/shell". The issue seems to be that calling getenv("PWD") to find the path is not always right.

So the goal is to load the same process, or the binary; let's assume the binary is called "shell". The issue is to find the path. The code I am showing works in the case that the shell is loaded (parent) from the folder it is in itself, otherwise it does not work. I suspect calling getenv("PWD") is not right, but I am not sure what else to call.

You are correct that using getenv("PWD") or getcwd() is not usually correct.

char *arg0 = 0;

int main(int argc, char **argv)
{
    ...declarations...

    arg0 = argv[0];

    ...actions...
}

The main program, therefore, stashes the value of its argv[0] in the global variable arg0 to make it available to other parts of the process - in particular, the code that is going to (re)run the command.

If the program is invoked in the same directory as where the executable resides using "./shell", then argv[0] (and hence arg0) will contain that pathname. If it is executed using "shell" relying on $PATH to locate the program, then argv[0] will contain either just "shell" or the absolute pathname of "shell" (less common).

If the program is invoked from the fd subdirectory, it might be invoked as "../shell", or it might be invoked as "/absolute/path/to/shell" or it might be invoked as "shell" relying on $PATH to find the executable. Again, in any of these cases, the value in arg0 is the name by which the program was originally invoked, or is equivalent to it.

The only time this fails is if someone is deliberately setting out to confuse the executable, which is (fortunately) seldom the case.

So, in the child code, you can use:

char *args[] = { arg0, 0 };
execvp(arg0, args);

to re-execute the command as it was originally executed (apart from any auxilliary arguments that were passed originally).

Attempt 1 - somewhat confusing

Assuming that the value of argv[0] is available via a variable char *arg0, all that's necessary is:

char *args[] = { arg0, 0 };
execvp(arg0, args);

If you must use execl(), then you need:

execl(arg0, arg0, (char *)0);

The cast is necessary; execl() is a variable argument list function, and if you write 0, it will be converted to int which will fail on a 64-bit system where int is 32-bits and a pointer is 64-bits. However, that will fail if arg0 does not represent the path (relative or absolute) to the executable. You'd then have to decide what to do if execl() returns - you can either give up or search for the program via $PATH, but in that case, why not use execvp() in the first place to save yourself the pain.