Each command line should take the form of a process group, created using setpgrp. All off the different programs involved in I/O redirection will be separate processes but will belong to the same process group. For example, with a command line of ls | grep hello you would create a set of pipe descriptors with pipe and two forks with fork (one for ls and one for grep hello,) making the output descriptor standard output for ls and the input descriptor standard input for grep hello. Normally you'd want to raise(SIGSTOP) in the fork(s) right before calling execvp (etc.) to give the shell time to set everything up. The shell would then set the process group of both forks to the process ID of the first fork and then send a SIGCONT signal to the process group to start command execution.
To determine which process group controls the terminal, the shell needs to call tcsetpgrp using the file descriptor of the controlling terminal as well as the group number of the command line which needs to take control. If the command is to be executed in the foreground right away, the shell should tcsetpgrp to the new process group before signaling the new process group with SIGCONT. The shell should tcsetpgrp back to itself when the foreground process ends. That should also be the behavior if the foreground process is stopped with SIGSTOP, as with [Ctrl]+Z in bash.
If a program is in the background and wants the terminal, it can call tcsetpgrp using getpgrp() as the process group and it will block until the shell gives it terminal control (the shell will be sent a SIGCHLD signal.)
In order for the shell to control which commands go to the foreground and background it must be a session leader. If the shell will be opening the terminal itself it will probably need setsid at some point. If you are going to call it from another shell such as bash you can just start it with exec and the shell program must avoid using setsid.