Linux – Echo problems with execv() after fork()

cforklinuxunix

AFAICS, the child process inherits stdout/stdin from the parent process on fork(). This leaves me wondering why the following code does NOT work:

int main(int argc, char *argv[])
{
    char *earg[] = {"echo", "Hello", NULL};

    if(fork() == 0) {
        printf("running echo...\n");
        execv("echo", earg);
        printf("done!\n");
        exit(0);
    } else {
        sleep(2);
    }

    return 0;
}

When running this little program, the two printf() calls appear just fine on the console. But the call to echo somehow gets lost! The output on the console is just:

running echo...
done!

Can somebody explain to me why the echo output doesn't appear on the console? And how I can fix this?

Best Answer

Since your printf("done") gets invoked your execv() clearly failed. All exec() functions do only return if an error occurred. Evaluating errno should help you to find out why it failed.

try using the whole path to echo:

 execv("/bin/echo", earg);

EDIT: if you want to print done as soon as the child exited you should add a wait(NULL) call to your parent. see the manpage of wait() for more information and an example how to use it.

Related Solutions

With arrays, why is it the case that a[5] == 5[a]

The C standard defines the [] operator as follows:

a[b] == *(a + b)

Therefore a[5] will evaluate to:

*(a + 5)

and 5[a] will evaluate to:

*(5 + a)

a is a pointer to the first element of the array. a[5] is the value that's 5 elements further from a, which is the same as *(a + 5), and from elementary school math we know those are equal (addition is commutative).

Unix – text files end with a newline

Because that’s how the POSIX standard defines a line:

3.206 Line

A sequence of zero or more non- <newline> characters plus a terminating <newline> character.

Therefore, lines not ending in a newline character aren't considered actual lines. That's why some programs have problems processing the last line of a file if it isn't newline terminated.

There's at least one hard advantage to this guideline when working on a terminal emulator: All Unix tools expect this convention and work with it. For instance, when concatenating files with cat, a file terminated by newline will have a different effect than one without:

$ more a.txt
foo
$ more b.txt
bar$ more c.txt
baz
$ cat {a,b,c}.txt
foo
barbaz

And, as the previous example also demonstrates, when displaying the file on the command line (e.g. via more), a newline-terminated file results in a correct display. An improperly terminated file might be garbled (second line).

For consistency, it’s very helpful to follow this rule – doing otherwise will incur extra work when dealing with the default Unix tools.

Think about it differently: If lines aren’t terminated by newline, making commands such as cat useful is much harder: how do you make a command to concatenate files such that

it puts each file’s start on a new line, which is what you want 95% of the time; but
it allows merging the last and first line of two files, as in the example above between b.txt and c.txt?

Of course this is solvable but you need to make the usage of cat more complex (by adding positional command line arguments, e.g. cat a.txt --no-newline b.txt c.txt), and now the command rather than each individual file controls how it is pasted together with other files. This is almost certainly not convenient.

… Or you need to introduce a special sentinel character to mark a line that is supposed to be continued rather than terminated. Well, now you’re stuck with the same situation as on POSIX, except inverted (line continuation rather than line termination character).

_{Now, on non POSIX compliant systems (nowadays that’s mostly Windows), the point is moot: files don’t generally end with a newline, and the (informal) definition of a line might for instance be “text that is separated by newlines” (note the emphasis). This is entirely valid. However, for structured data (e.g. programming code) it makes parsing minimally more complicated: it generally means that parsers have to be rewritten. If a parser was originally written with the POSIX definition in mind, then it might be easier to modify the token stream rather than the parser — in other words, add an “artificial newline” token to the end of the input.}

Best Answer

Related Solutions

With arrays, why is it the case that a[5] == 5[a]

Unix – text files end with a newline

Related Topic