Define Unix Process

A Unix process is a running instance of a program. This definition is short, but it is one of the most important ideas in shell programming. When a command, script, or application is stored on disk, it is only a program file. When the operating system loads that program and begins executing it, the program becomes a process.

Processes are sometimes called tasks because they represent active work being performed by the operating system. A process consumes system resources, has an execution state, receives CPU time from the scheduler, may open files, may read from or write to a terminal, and eventually exits with a status code. Shell programming depends heavily on this model because nearly every command you type causes the shell to create, monitor, or control a process.

This lesson explains the difference between a program and a process, the purpose of a process ID, why your shell is itself a process, and how shell commands create child processes. These ideas prepare you for later lessons involving interactive shells, background jobs, exit status, and process control.

What Is a Unix Process?

A process is an active operating-system object created when a program begins running. The process contains the information the operating system needs to manage that running program. This includes a process ID, execution state, memory space, open files, environment variables, current working directory, user and group ownership, and eventually an exit status when the process terminates.

You do not need to understand every kernel-level detail at this stage. The essential idea is that a process is dynamic. It exists while work is being performed. It can be observed, managed, waited for, or terminated. When it finishes, it no longer runs as an active process.

For example, when you type a command at the shell prompt, the shell interprets your input and usually starts a new process to run the command. The operating system assigns resources to that process, allows it to execute, and then records the result when it exits.

Program versus Process

The definition of a process becomes clearer when you compare a process with a program. A program is a static file. It may be an executable binary, a shell script, or another file containing instructions. A process is the active execution of that program.

The command used to list files is commonly stored as a program file such as:

/bin/ls

The file /bin/ls is not itself a process while it is merely sitting on disk. It is a program. When you type ls at the shell prompt, the operating system runs that program. At that moment, a process is created.

If five users run the ls command at the same time, the same program file can produce five separate processes. Each process has its own process ID and its own execution context. The program file is shared as the stored instruction source, but each running instance is treated separately by the operating system.

This distinction is fundamental:

1. Program: a stored file containing instructions.
2. Process: a running instance of those instructions.
3. Command: the shell input that asks the system to run a program or perform a shell operation.

Process IDs and Process Lifetime

Unix assigns each process a process ID, usually called a PID. The PID is a number that identifies the process while it exists. Administrators and shell scripts use PIDs to inspect, wait for, signal, or terminate processes.

A PID is temporary. It lasts only for the lifetime of the process. When a process exits and the operating system has finished collecting its termination information, that PID can eventually be reused for another process. For that reason, a PID should not be treated as a permanent identity for a program.

This answers several common beginner questions:

1. Yes, a PID assignment lasts only while the process exists.
2. After a process finishes, it is no longer an active running process.
3. A process exists during the lifetime of the running program instance, although logs or accounting records may remain afterward.
4. Yes, there is a practical need to view PIDs. Commands such as ps, kill, jobs, and wait use process information.

For example, if you need to terminate a misbehaving process, you usually identify its PID first and then send it a signal. If a shell script starts a background command, the script may need to wait for that process to finish before continuing.

The Shell as a Process

When you log in to a Unix or Linux system, the system starts a shell for you. That shell is not just a place where commands appear. It is a running program, and therefore it is a process.

Common shell programs include sh, bash, zsh, and ksh. When one of these programs is running, it becomes a shell process. The shell process reads your commands, interprets shell syntax, starts other programs, manages foreground and background jobs, and records command exit status.

This resolves the common confusion between the words program and process. The file /bin/sh is a program. When the operating system runs /bin/sh for your login session or terminal session, it becomes a process. The same distinction applies to other shells such as Bash or Zsh.

You can display the PID of your current shell with:

echo $$

The variable $$ expands to the PID of the current shell process. This is useful when learning how the shell participates in process creation.

Parent and Child Processes

Processes usually have relationships. When one process starts another process, the first process is called the parent process and the new process is called the child process. In interactive shell work, your shell is often the parent process, and the commands you run become child processes.

For example, when you type:

ls

the shell starts a child process to execute the ls program. When ls finishes, control returns to the shell and the prompt appears again.

Shell scripts also rely on this idea. When you run a shell script, the system may start a new shell process to interpret that script. Commands inside the script may start additional child processes. This parent-child structure is one reason process control is so important in shell programming.

On many Unix/Linux systems, you can display expanded process information with:

ps -f

The detailed output may include a parent process ID, often labeled PPID. This helps you see which process started another process.

Foreground and Background Processes

A foreground process is attached to your terminal and usually occupies the shell until it finishes. While a foreground command is running, the shell prompt does not normally return. The command may display output, read input, or run until completion.

A background process runs without occupying the terminal in the same way. You can start a command in the background by placing an ampersand after it:

sleep 60 &

After starting a background process, the shell prompt returns quickly, allowing you to continue typing other commands. Background processing is useful for long-running tasks, but it also requires care. A background command still consumes resources and may still write output to the terminal unless redirected.

Job-control commands such as jobs, fg, bg, and wait help manage foreground and background activity. This lesson introduces the concept; later shell programming work can build on it.

Exit Status and Shell Programming

When a process terminates, it returns an exit status. Shell scripts use exit status values to decide what to do next. By convention, an exit status of 0 usually means success, while a nonzero value usually indicates failure or another condition.

After running a command, you can display the exit status of the most recent foreground command with:

echo $?

This is one of the reasons processes matter so much in shell programming. A script can run a command, check whether the command succeeded, and then choose the next action. Conditional execution, error handling, and automation all depend on understanding that commands run as processes and return results.

Viewing Processes with ps

The ps command displays information about running processes. In its simplest form, it shows processes associated with your current terminal session.

ps

A typical output may include columns such as PID, TTY, TIME, and CMD.

1. PID: the process ID.
2. TTY: the terminal associated with the process.
3. TIME: the CPU time used by the process.
4. CMD: the command or program name.

ps -f
ps -ef

In the sample output, the command name sh shows that the Bourne shell is running. That shell has a PID, is associated with a terminal, and is consuming system resources while it waits for commands. This is why the shell is correctly described as a process.

The exact output depends on the Unix or Linux system, but these forms usually provide more detailed information. Expanded output may show user names, parent process IDs, start times, and full command lines.

Why Processes Matter in Shell Programming

Shell programming is process-oriented. A shell script usually runs commands, checks their results, sends output from one command to another, starts background work, and waits for commands to finish. Each of these actions involves process behavior.

For example, a script may run a command that succeeds, then continue. It may run another command that fails, then print an error message. It may start a long-running task in the background and later wait for it. It may use a PID to terminate a process or check whether a service-related command is still running.

Understanding processes makes these behaviors predictable. Instead of viewing shell programming as a list of unrelated commands, you can see it as a way of controlling program execution through the operating system’s process model.

Summary

A Unix process is a running instance of a program. A program is static; a process is active. When the shell runs a command, the operating system creates a process for that command. Each process receives a PID, exists for a limited lifetime, and may return an exit status when it terminates.

The shell itself is also a process because it is a running program. It reads commands, starts child processes, manages foreground and background execution, and reports command results. The ps command allows you to inspect running processes and observe this model directly.

The next lesson builds on this foundation by describing how to start a new interactive shell. That topic will make more sense now that you understand that each shell session is itself a process with its own PID and execution context.