Troubles passing arguments through execlp function - C

Question

i'm using a given md5 function who calculates a file hash when you feed it with a file address. Thing is that i need to execute this program using fork() and then load it using any exe...() function(im trying with execlp()) but when i do it and i pass the single argument i need to calculate the hash it fails. I tried running md5 program manually with the exact argument i use in execlp and it doesn't fail so i'm just assuming it must be something wrong with execlp parameters. Here's an example i made to explain the scenario:

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int main(){
  pid_t cpid;int status;
  cpid = fork();
  if(cpid < 0){
    printf("Error fork\n");
    exit (EXIT_FAILURE);
  }else if (!cpid){
        if (execlp("./hashMD5/me/md5","md5","testfile.a",(char*)NULL) == -1){
          printf("Error: Loading process\n");
          exit(EXIT_FAILURE);
        }
  }else{
    waitpid(cpid,&status,0);
  }
    exit (EXIT_SUCCESS);
}

when i use this i got an error in terminal:

$testfile.a can't be opened

but if i manually execute the md5 program with the exactly same argument i got the correct execution.

What's wrong? Help!

Good: casting `NULL` in `execlp`. Bad: casting the return value of `malloc`. Neutral: `sizeof (char)` doesn't exactly change... — Antti Haapala -- Слава Україні, Nov 26 '17 at 18:09
BTW how come your pathaux can be `testfile.a` *after* the `strcat`?! — Antti Haapala -- Слава Україні, Nov 26 '17 at 18:10
there is no meaning of writing printf statement after execlp, it won't prints because execlp will replace whole child/parent process with md5 process — Achal, Nov 26 '17 at 18:11
You have apparently made no attempt to debug this yourself. There is no [mcve], and you don't check *why* your operations fail (if they fail). — melpomene, Nov 26 '17 at 18:11
Did you remember to remove the newline at the end of the name read from the input? — Jonathan Leffler, Nov 26 '17 at 18:12
I've been trying to debug this myself about an hour and a half, otherwise i wouldn't have come to here if that was not the case. — Frank Ponte, Nov 26 '17 at 18:14
@AnttiHaapala pathaux won't look like "testfile.a", was just an example. it will look more like "../../adirectory/testfile.a" that's just bc i saved the executable i need inside folders in main program directory. i Don't get why you say casting the return value of malloc. Can you explain further please? — Frank Ponte, Nov 26 '17 at 18:16
@FrankPonte https://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc — Antti Haapala -- Слава Україні, Nov 26 '17 at 18:23
@achal it is there in the branch that is executed **if** execlp fails — Antti Haapala -- Слава Україні, Nov 26 '17 at 18:24
New thing i learned! thanks! btw im gonna edit the code to a simple one and meavy can be a " Minimal, Complete, and Verifiable example" — Frank Ponte, Nov 26 '17 at 18:27
Yes, i edited bc might be easier to understand.. But it still failing! @alk — Frank Ponte, Nov 26 '17 at 18:44
Neither of these issues is directly a cause of your troubles, but … Note that because there are slashes in the path name given for the command (not function) `"./hashMD5/me/md5"`, you might as well use `execl()` as `execlp()` — `execlp()` will never use the path setting because the name contains slashes. You should also report error messages on standard error (`stderr`), not standard output. Also, there's no need to test the return status of `execlp()`; if it returns, it failed (and if it succeeds, it never returns). — Jonathan Leffler, Nov 26 '17 at 20:02
For debugging, I recommend capturing the return value from `waitpid()` and printing that and the status returned — use `0x%.4X` or similar to print the status readably. — Jonathan Leffler, Nov 26 '17 at 20:03

score 2 · Answer 1 · answered Nov 26 '17 at 20:27

2

the following proposed code:

cleanly compiles
documents why each header file is included
uses a proper call to execl() rather than execlp() because execl() expects the first parameter to be a complete path while execlp() expects the first parameter to be just a file name.
properly formats the code, for ease of readability and understanding
properly handles calling execl() and possible failure of that call
properly passes error messages to stderr rather than stdout, using perror(), so the reason the system thinks the error occurred is also displayed on stderr.

And now, the proposed code:

#include <stdio.h>   // perror()
#include <sys/types.h>
#include <stdlib.h>   // exit(), EXIT_FAILURE, EXIT_SUCCESS
#include <unistd.h>   // fork(), execlp()
#include <sys/wait.h> // waitpid()

int main( void )
{
    pid_t cpid;int status;
    cpid = fork();

    if(cpid < 0)
    { // error
        perror("Error fork\n");
        exit (EXIT_FAILURE);
    }

    else if (!cpid)
    { // child
        execl("./hashMD5/me/md5","md5","testfile.a", NULL);

        perror("Error: Loading process\n");
        exit(EXIT_FAILURE);
    }

    else
    { // parent
        waitpid(cpid,&status,0);
    }

    exit (EXIT_SUCCESS);
}

answered Nov 26 '17 at 20:27

user3629249

16,402
1
16
17

It doesn't document why `` is included. POSIX 2004 did away with the need to include `` explicitly (though it was theoretically needed in POSIX 1997). Also note that in theory, you should cast the `NULL` to `(char *)NULL`. Whether you get away without the cast depends on the definition of `NULL`. – Jonathan Leffler Nov 26 '17 at 20:44
@JonathanLeffler, the final `NULL` parameter can also be left off the call. The `sys/types.h` header file is included because some (older) C support headers failed to include it in their definition. Since it is not directly related to any objects in the OPs code, there is no clear reason for its inclusion. However, we have no guarantee that everyone is using an up-to-date compiler. Especially if using Visual Studio or Visual C. – user3629249 Nov 26 '17 at 20:53
No; the NULL cannot be left off the calls to `execl*()` functions. It marks the end of the argument list and is crucial, and must be a null character pointer, which is why the cast is necessary on some machines (e.g. a 64-bit system where `#define NULL 0` is used instead of `#define NULL ((void *)0)`). And I documented that older means 'archaic' as in "prior to POSIX 2004", which is itself very old these days. You claim to have documented why each header is included; you didn't annotate why `` was included. It's up to you; you can include it and add a commentary about why, or … – Jonathan Leffler Nov 26 '17 at 20:56
@JonathanLeffler, Here are the prototypes for `execl()` and `execlp()`, from the linux MAN page for those functions: `int execl(const char *path, const char *arg, ... /* (char *) NULL */); int execlp(const char *file, const char *arg, ... /* (char *) NULL */);` Which clearly indicates the NULL argument is optional – user3629249 Nov 26 '17 at 21:18
1

No; it clearly indicates that the NULL argument is mandatory, but cannot be specified as mandatory using the `...` notation because that says "all bets are off about what goes here". – Jonathan Leffler Nov 26 '17 at 21:21
1

Note that the POSIX description of [`execl()`](http://pubs.opengroup.org/onlinepubs/9699919799/functions/execl.html) includes: _`int execl(const char *path, const char *arg0, ... /*, (char *)0 */);`_ and _The arguments represented by `arg0,...` are pointers to null-terminated character strings. These strings shall constitute the argument list available to the new process image. **The list is terminated by a null pointer.** The argument `arg0` should point to a filename string that is associated with the process being started by one of the `exec` functions_ (emphasis added). – Jonathan Leffler Nov 26 '17 at 21:29

score 0 · Answer 2 · answered Nov 26 '17 at 21:11

0

I finally solved the problem. I appreciate the improvements people gave me, i'm always happy to learn new things!

The problem was with the argument itself: Even when you use execlp to create a brand new process the path of the argument remains relative to parent process, that's why was not working. After several headaches i finally realized that. Thanks to everyone!

answered Nov 26 '17 at 21:11

Frank Ponte

135
1
11

You mean that the `testfile.a` file was in the `hashMD5/me` directory, not in the directory containing that path? Yes, all relative paths are interpreted relative to the current directory of the process, which is the current directory of the parent process unless the program does an exlicit `chdir()` operation to change directory. – Jonathan Leffler Nov 26 '17 at 21:24
exactly, @JonathanLeffler. Oh, im gonna read about that function, awesome! – Frank Ponte Nov 27 '17 at 21:48

Troubles passing arguments through execlp function - C

2 Answers2