Thread: Doing my own shell, how to properly execute processes in background/foreground?

Hi,

I have this stuff to do for university that's basically a simple custom shell and I'm currently having some difficulties.

The basic functionality is already done, I read a command from the stdin and execute it with execvp(). After that, with wait(NULL), I wait for that process to finish before returning to the shell. I now can properly run processes in the foreground one at a time. Time to implement background processes...

The first step is to check if the "&" is the last argument, if it is, run the process in the background. To do that I simply check for the "&" and set a background variable to true or false accordingly. Then, if background == false do not wait for the process to finish and return to the shell.

So far so good... Now my problem...

When running processes in the background like this, it's likely they end up "zombies" right? I need to take care of them and for that, I believe I need to handle the SIGCHLD signal... At least I need to use the signal() function to handle something because that's part of the exercise. And that's what I did as you'll see in the code below...

Now my questions:

1) Is this code ok or should I do it differently? I ask this because if I run a process in the foreground, there will be two waits, the first one (wait(NULL)) right after executing the command and a second one (waitpid(-1, &status, WNOHANG)) right after the process terminates or is killed/stopped/whatever.

I don't think that this should happen. First because it doesn't make sense to call wait two times for a foreground process, the first wait will turn the second one redundant. Second because part of my exercise is that I need to print the status changes of the processes but there's no reason to do this for foreground processes. So basically, I need to call the waitpid() in childSignalHandler() only for background processes.

How should I solve this then?

2) As I said in my first question, I need to print the status changes of the processes running in the background. Any changes how to handle this? My first guess is that I simply need to print the value of status after waitpid() in childSignalHandler(). Is that it?

That's almost all I want to know, I still have a couple of more things that I want to accomplish but they are not part of the exercise for university, they are just some things I want to do to improve my custom shell a little bit, I'll talk about them later...

I was just going to forget about the code lol, here it is:

Code:

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

#include "data.h"


void childSignalHandler(int signum) {
	int status;
	pid_t pid;
	
	pid = waitpid(-1, &status, WNOHANG);
}

int main(int argc, char **argv) {
	char bBuffer[BUFSIZ], *pArgs[10], *aPtr = NULL, *sPtr;
	bool background;
	ssize_t rBytes;
	int aCount;
	pid_t pid;
	
	signal(SIGCHLD, childSignalHandler);
	
	while(1) {
		write(1, "\e[1;31mmyBash \e[1;32m# \e[0m", 27);
		rBytes = read(0, bBuffer, BUFSIZ-1);
		
		if(rBytes == -1) {
			perror("read");
			exit(1);
		}
		
		bBuffer[rBytes-1] = '\0';
		
		if(!strcasecmp(bBuffer, "exit")) {
			exit(0);
		}
		
		sPtr = bBuffer;
		aCount = 0;
		
		do {
			aPtr = strsep(&sPtr, " ");
			pArgs[aCount++] = aPtr;
		} while(aPtr);

		background = FALSE;
		
		if(!strcmp(pArgs[aCount-2], "&")) {
			pArgs[aCount-2] = NULL;
			background = TRUE;
		}
		
		if(strlen(pArgs[0]) > 1) {
			pid = fork();
			
			if(pid == -1) {
				perror("fork");
				exit(1);
			}

			if(pid == 0) {
				execvp(pArgs[0], pArgs);
				exit(0);
			}
			
			if(!background) {
				wait(NULL);
			}
		}
	}

	return 0;
}

Originally Posted by Nazgulled

When running processes in the background like this, it's likely they end up "zombies" right?

Why do you believe that?

Anyway, I would say your whole approach is flawed. If you want the difference between background and foreground, consider 1) forking vs. not forking 2) exec vs. system. I would not try to write a function that does both things; you should parse the input somewhere and then send it to one of a number of functions depending upon what the input is.

Also look into popen().

So you are saying this:

Originally Posted by Nazgulled

The first step is to check if the "&" is the last argument, if it is, run the process in the background. To do that I simply check for the "&" and set a background variable to true or false accordingly. Then, if background == false do not wait for the process to finish and return to the shell.

is dictated by the assignment specs? And that you are to use a single function for both background and foreground processes? AND that you are to use exec, and not system() or popen()?

Those are some tough specs. I would *especially* make sure that you are supposed to fork a "foreground" process...as you point out, this creates an unnecessary complication with the signal handling. It is also counter intuitive. With bash, & will fork, but I don't *think* the shell forks foreground process. I would almost bet money it doesn't. You don't have to fork() to exec().

I've never done anything like this tho. Sorry...

Good luck

Originally Posted by cas

You can use sigprocmask() to block SIGCHLD when you're running your foreground process, so you won't have to worry about a signal being sent.

Can you provide a basic example please?

Originally Posted by cas

The problem with signal handlers is that you're somewhat limited in what you're allowed to do in one. You can't, for example, call printf(). I'm not sure what your teacher expects from you.

I'm not sure what you mean because I just added a printf("CALLING WAITPID...\n"); right before pid = waitpid(-1, &status, WNOHANG); in childSignalHandler() and it's working just fine...

Originally Posted by cas

(...)then I suppose you catch SIGCHLD and print out whatever you need to, all the while keeping in mind you're not supposed to be doing that.

Not sure I understand this either but why not? If I call, say, "gedit &" in bash, gedit will be executed in the background and be able to keep doing my work in the bash. Whenever I close gedit, a message will be printed in the bash saying the process was terminated. The bash does it, why can't I?

Not so fast brewbuck, listen to the OP

Originally Posted by Nazgulled

I'm not sure what you mean because I just added a printf("CALLING WAITPID...\n"); right before pid = waitpid(-1, &status, WNOHANG); in childSignalHandler() and it's working just fine...

Originally Posted by MK27

Not so fast brewbuck, listen to the OP

There are plenty of things you can do in C which seem to work but are completely wrong.

On average, you survive Russian Roulette -- wanna play?

Originally Posted by brewbuck

There are plenty of things you can do in C which seem to work but are completely wrong.

Yep. I might have been being tongue in cheek there, I don't remember

The point is, Nazgulled, your prof will know the standard and doc you for this. At least s/he should.

Look:

Code:

#include <stdio.h>
#include <string.h>

 int main () {
	char X[2];
	strcpy(X,"hello world");
	printf("%s",X);
	return 0;
}

Works for me! I guess that is correct then!

Originally Posted by MK27

Not so fast brewbuck, listen to the OP

Not so fast MK27, listen to the man page: ;-)

Originally Posted by man 7 signal

A signal handling routine established by sigaction(2) or signal(2) must
be very careful, since processing elsewhere may be interrupted at some
arbitrary point in the execution of the program. POSIX has the concept
of "safe function". If a signal interrupts the execution of an unsafe
function, and handler calls an unsafe function, then the behavior of
the program is undefined.

POSIX.1-2004 (also known as POSIX.1-2001 Technical Corrigendum 2)
requires an implementation to guarantee that the following functions
can be safely called inside a signal handler:

*long list of functions follows, of which printf is not one.*

...which is what brewbuck hinted at. But I myself never found any way to notify the main thread of an event from a signal handler. (and hence, I dropped signals altogether.) It would be interesting if someone could enlighten us -- If you have a SIGCHLD handler, how do you have the main thread wait for it to fire, and get information back from it?

With bash, & will fork, but I don't *think* the shell forks foreground process. I would almost bet money it doesn't. You don't have to fork() to exec().

Of course it does. As a shell, you have to fork() regardless of whether you're creating a background or a foreground process. If you exec'd without the fork - you'd be gone. From TFM:

Originally Posted by man 3 fork

replaces the current process image with a new process image.

I never bothered with signals when I wrote my shell. Too much crap to deal with. It's like multithreading, but much more painful. I notice that you have two wait()'s. One of them is going to error:

Code:

29 wait4(-1, NULL, 0, NULL)                = 12198
30 --- SIGCHLD (Child exited) @ 0 (0) ---
31 wait4(-1, 0x7fff12bc25a8, WNOHANG, NULL) = -1 ECHILD (No child processes)

Here, you signal handler got beat.

The bash does it, why can't I?

But does bash write to stdout from within the signal handler? Does it use a signal handler at all?