Terminals do not have process IDs.
It is processes that have process IDs, of course. Terminals have IDs of their own, and you'll see them in the outputs of tools like w
, who
, and (in the TTY
column) ps
. But these are not process IDs.
The relationship between processes and terminals is not 1:1. Moreover, as grawity
pointed out, a shell is not a terminal. A terminal is a device. A shell is a program. The bash
program is a shell, whose input and output (in interactive mode at least) are read from and written to a terminal device.
Terminals on personal computer Linuxes and Unices are generally not real, physical, devices, plugged into a serial port of some sort. Rather, they are either virtual terminals or pseudo terminals. Both are the products of terminal emulator programs.
- In the case of virtual terminals, that program is embedded into the operating system kernel (albeit that there have been moves to change this) and it doesn't have a process ID because it isn't a distinct process in its own right.
- In the case of pseudo-terminals there's a process that manages the "master" side of the device, and displays the contents of the terminal in some fashion. Usually it is a GUI program, such as
xterm
, lxterminal
, konsole
, gnome-terminal
, or rxvt
. (It could, alternatively, be the SSH or TELNET daemons.) Those do have process IDs. But it is the terminal emulator that is the process, not the pseudo-terminal device.
As to why you see two bash
processes: You have two bash
processes running. It's that simple. They aren't necessarily associated with the same terminal device, or even with any terminal device. Again, the TTY
column in the output of ps
will tell you what controlling terminal each process has. (Terminals don't have process IDs, but in a way processes have terminal IDs.)
$$
and$PPID
expand to PIDs of the shell itself and its parent.