fork() [intercept child process err to stdout]

i coded a shell, and as usual it has a runcommand() function that uses fork() and executes a command in the child while the parent waits or prints out process ID and doesn't wait if the user selected it to be background

now when the child has an error msg it prints it outto the stdout, the problem is my Prompt shows up b4 that happens and doesn't wait for the child to print errors.

here is the code:



and here is a sample output when i try to execute kwrite in the background after i have choosen a different set of icons for my KDE and obviously kwrite can't find his icon:

[nash - /home/ahmed/Desktop/Project]>kwrite &
Process ID for application kwrite: 2277
To terminate the application Type: kill 2277
[nash - /home/ahmed/Desktop/Project]>kdecore (KIconLoader): WARNING: Icon directory /usr/share/icons/slick/ group not valid.
kdecore (KIconLoader): WARNING: Icon directory /usr/share/icons/slick/ group not valid.

now what i need is, either a way to make the parent wait till the child flushes it's err to stdout or a way to redirect the err to the parent for processing instead of stdout.

if you run a command in the b/g, that's what happens. if u want to redirect stderr stream to the parent, then create a set of pipes in the parent, then in the child, dup2 the write end of the pipe to stderr, and then the parent can read from the read end of pipe to get the errors.

Can u please elaborate as i don't know what is dup2, i tried to search for a definition for the function in the man pages but what i got was not so descriptive

dup2 is just like dup with one important exception; from the man page:

They both create a copy of the file descriptor, but dup choses the new file descriptor number for you whereas you can specify it explicitly with dup2. So dup2 gives you a bit more control over the process.

^^what he said, pseudo code:

Let's start again here, what i know about process creation and exectution in unix is the forking concept and the exec functions, i know the general concept of piping but not how it is implemented in C, so go easy on me guys. Thanks

We are going easy on you. You should see what happens when we play rough! [grin]

Please bear with me, because I'm doing this from memory (not having actually done this for at least a year).

The pipe() call creates a pair of pipes in an array: one for reading and the other for writing.

When you fork, the child gets the open file descriptors of the parent, which the parent also still has.

The dup2(pipe[WRITE], STDERR); call by the child duplicates stderr to its write pipe (which is the read pipe for the parent). I'm not completely sure about closing the write pipe there; I thought that stderr had to have been closed first, but I'm sure that infamous is more up on this than I am and can explain that part -- personally I think that it should have been the child's read pipe that gets closed instead. Anyway, this sets it up so that whatever the program writes to stderr will instead get written out to the child's write pipe.

On the parent's side, he closes his own write pipe (the child's read pipe), because there is nothing he will want to send to the child. Then he reads his read pipe (the child's write pipe) for anything that got written to stderr.

yup, in the child there should also be a close(pipes[READ]) as well, i forgots. the reason for closing the WRITE end also tho, is as follows:
dup2 will first close it's second argument, in this case STDERR. then it will re-open it, having it point to the file descriptor u pass as a first argument, the WRITE end of the pipe. at this point, u now have 2 references to the WRITE end of the pipe: 1)the fd returned by pipe, and 2)the reopened STDERR handle. on the other end, u have the parent waiting to read from the READ end of the pipe. that parent will keep reading until it receives an EOF. the problem is, u have 2 references to the same 'file', when STDERR is closed, that will leave 1 reference open still, and since there is still a reference, the parent will not be sent EOF until there are no refs left. now obviously in this particular situation, when the child exits all descriptors will be closed and EOF will be sent. but if u had different situation, say u had dup2'd two sockets for example, and u did not close the 2nd reference after the call to dup2, u can see the problem. so it's always good practice to close 2nd reference.

i'll try and expand on what dwise said a bit. on *nix, u have the concept "everything is a file". when u talk about STDOUT, STDIN, STDERR, these are all referenced thru file descriptors. when u open up a file with the open() system call, it returns to u a file descriptor, when u open up the serial port, it returns to u a file descriptor. the kernel views all these file descriptors as one and the same, a integer identifier used to reference a 'file' structure inside the kernel. each file descriptor is represented internally by a file structure. each process has a number of pointers to these file structures in its 'file table', a data structure maintained by the kernel. the number returned by open(), or the constants STDOUT_FILENO, etc, serve as an index into this table. when you call this:

what happens is the pointer stored at index fd2 in the process's file table gets pointed at the same 'file' structure that the pointer at index fd1 is pointing to. so, now when u access fd2 u are accessing the same underlying file as fd1. so when a process does this:
now everytime that process goes to write to STDOUT, it will actually be writing to some_Fd.

next thing u need to know is what pipe does. when u call:

u create 2 new file descriptors, one for each array index. these 2 descriptors are tied to each other, when u write to the 2nd one, u can then read what u wrote on the first one. so:

so u can see the use of pipes. as mentioned above by dwise, when a process forks a child, the child gets a copy of all the parents descriptors, ie a copy of the parents 'file table' i mentioned b4. if u create the pipes in the parent, they will then be available in the child as well, and what u write to write end of the pipe in the child will come out on the read end of the pipe in the parent(to be correct, it will also be readable thru the childs read end as well), and vice versa if u wanted to communicate other direction. u said u wanted the childs STDERR to be readable by the parent. so combine the 2 things i just talked about. what u want is the child to write its STDERR to the write end of the pipe, and for the parent to then read this output from the read end of the pipe. make sense?

note: if u really want to understand this stuff i suggest this book as i've left out some important stuff: http://www.kohala.com/start/apue.html

hey man ... i'd re-evaluate the if else statements b4 checking anything else...

LOL thanks einstein, i think it's pretty clear that is labeled PSEUDO CODE, and that the indentation defines what belongs where...

I think i got a grip of what u said guys, but now surfs two problems:
first, the dup2() accepts file descriptors, but STDERR is not a file descriptor, it's a _IO_FILE* or at least that's what gcc said.
now, i tried static cast : (int ) STDERR, but that trick didn't work

second, the read() function has the last argument to be the no. of bytes to read, and if set to zero it just returns zero and exits.

so?

thanks again and will really appreciate the reply

the constants u want are STDOUT_FILENO , STDERR_FILENO, etc.. and im not sure what you're talkin about /w read().. u shouldn't be passing 0 or u wont read anything of course.

thank u infamous, now it's working fine for the part of intercepting the STDERR, but i can't say print it my self
here is my code again:



and here is a sample output:

[nash - /home/ahmed/Desktop/Project]>kwrite &
0
Process ID for application kwrite: 5174
To terminate the application Type: kill 5174
[nash - /home/ahmed/Desktop/Project]>exit
Nada and Ahmed SHell, Terminating ...
[root@localhost Project]#

now see that zero b4 my usual output?? that is supposed to be what's in the buff variable, so??

You're reading and writing from the wrong pipe descriptor. pipe[0] is for reading, pipe[1] is for writing.

Thanks a million guys both of you, i finally did it, the problem with the last code was some mixing between the pipes[0] and the pipes[1]

i mixed which was the read and which was the write end, also i had declared the buff as int which was out off haste, hehe.

but now it works superbly, thanks again, i owe u two one, so anytime anyone of u need anything msg me and i'll do my best, and that's a word of honor