Shell – IO and other shell commands when a program is not started by a terminal

I think you're confusing a shell (a command line interpreter) with a terminal emulator.

A shell, when run interactively and pine require a terminal or terminal emulator to interact with the user. pine has nothing to do with the shell though.

A terminal in the older days was a device with a monitor and keyboard connected to a computer over a serial line to interact with the computer (which itself had no monitor or keyboard). The interface is simple and text based.

The serial line on the computer is a character device file (something like /dev/ttyS0 on Linux for instance). Applications that interact with the terminal write data to that device for display on the terminal.

For instance, in the simplest case, pine writing ASCII a to /dev/ttyS0 would cause the sequence of bits corresponding to that a character to be sent over the serial line, and the terminal displays a a on the screen at the current cursor position.

And when the user presses a on the keyboard, in the simplest case, the terminal sends that same sequence of bits on the other wire that goes to the computer and the system puts the a character on a buffer, and when pine does a read() on /dev/ttyS0, it returns that a character.

Terminals have evolved from a things like tele-typewriters (no screen, the a was printed on paper) to ones with CRT monitors, then some with more an more capabilities like cursor positioning, region clearing/scrolling, colour support all of which pine uses, or even graphical capabilities. X later provided with a much more advanced way to interact with a computer this time over a network instead of serial line and windowing capabilities and this time using a much more complex protocol than just a sequence of characters to be sent and a few escape sequences.

Still, decades of applications had been written for the terminal. There are a lot of things that can be done with the terminal that can't be done with X. Because the data is just two streams of characters going in both directions, it's easy for instance to export a terminal session over the network (think telnet, ssh), and an application like cat can be used to write to a terminal to display the content of a file for the user to view on his screen and can be used the exact same way, unmodified for that same content to be stored in a file or sent over the network to some server... (all is needed is redirect where that output goes). The same kind of thing can't be done with X applications that generally have one usage and can't cooperate with each other easily.

For those reasons and more, terminals have always been in use even long after X was wild-spread.

Only, now, instead of having real terminals, we have terminal emulators like xterm, gnome-terminal, eterm... Those emulate a terminal but are just themselves X applications (that run on the computer and are displayed on a X server, on the same computer or another).

By default, when you start such a terminal emulator application, a shell is started in them, which is why there's sometimes confusion between the two. You don't have to run a shell in a terminal emulator, pine doesn't have to be started by a shell, but it does require a terminal. It is a semi-graphic terminal application. It interacts with a terminal device, and at the other end of that device, it expects a terminal or terminal emulator with a minimal set of capabilities like cursor positioning, standout character highlighting...

Look at the man page for fork(2). A child process inherits the parent's file descriptors, including standard input and standard output. For a single command, the shell simply lets the child process inherit those descriptors and write its output to the terminal. For a pipeline, it forks each process, sets up a pipe between the output of one and the input of the next, and then executes (exec(2)) each child's executable.