How does the shell work

[nicko5]

How does the shell interact with the system as a whole?

For example, say I make a program that prints a number to stdout.

Then I go into the shell, and execute this program. What process follows?
Principally, how does the output get formatted?

This is what I know: When a this program is loaded, it is dynamically linked using ld.so. This allows it to use the glibc print function. What I want to know, is how does the output end up after the bash pront. Why doesn't the program take control of the screen itself?

This would be interesting for me to know, trying to understand how Linux works.

Cheers

[hazel]

The program does take control of the screen. When you launch a program via a command to bash and you don't put it into the background, bash goes into hibernation and your program takes over both screen and keyboard. When your program exits, bash wakes up again. Here's the sequence of events:

1) bash calls fork() to create a new process.
2) The parent process calls wait() and goes to sleep.
3) More or less simultaneously the child process calls exec() to switch to the specified program.
4) The program runs and outputs to the screen.
5) The program exits. The kernel notifies bash.
6) bash wakes up and prints a new prompt.

[ramin.honary]

I don't know too well myself, but I do know that the bash program is called a "controlling terminal" and that it interacts through the terminal emulator software (e.g. gnome-terminal, kterm, or xterm) which are software implementations of the defacto standard DEC corporation VT100 dumb terminals. A software communicating to a terminal emulator does IO using standard libraries through a device file called a "TTY", which I believe stands for "teletype", from the old days of UNIX when you had to log in through a teletype-terminal. Try running:

ls /dev/tty*
ls /dev/pts/*
tty

The tty command tells you what tty file you are using for the current shell. I know many Linux implementations have facilities to create TTY files in /dev/pts specifically for use with terminal emulator software.

GNU code libraries like "readline" and "ncurses" are specially designed to output the necessary ASCII control characters that interact with terminals that obey the VT100 protocol. The VT100 protocol has evolved functionality that allows color, bold, and underlined text, and allows a program to reposition a cursor on screen, all using the first 32 ASCII characters. It is by using "ncurses" that programs like emacs and vi can take control of the entire screen. This also explains why running "cat" on a binary file will often garble the text on your screen. The binary file will spit control characters to stdout that make your terminal do weird things.

Using the C standard "fgets" on stdin is the simplest way to read input from a terminal file, and as I understand it, the terminal driver (working in the kernel) is in control of buffering and handling back-space characters and so on, so the calling "fgets" pauses your program until the TTY driver running in the kernel receives a carriage return and sends a single line of input back to your program.

I imagine stdout works the same, where its the terminal driver that controls how the text on the screen is scrolled up when it receives data in the stdout buffer.

There is also a "termcap" database (which stands for Terminal Capabilities), which is a database that programs can use to lookup what functionality a given terminal has, like whether or not color text is supported.

But I am sure some Linux guru around here will correct me if I was wrong about any of that.

[drl]

Hi.

If you like visual explanations, the diagram and supporting text around the diagram [Chapter 1] 1.2 Who Listens to What You Type? may be useful ... cheers, drl