Processes

02Numbers have scope and a lifetime

sleep 60 waits for about 60 seconds. Putting & after it starts that wait in the background. jobs -l displays this shell's jobs with associated process IDs; -l requests the longer information. Compare the list before and after creation to identify only your new wait.

A jobspec is local to the shell that created the job. Another terminal has a different job table. A PID is an operating-system identifier, but that number can later be reused after its process ends. Neither an old worksheet number nor an old observation is a safe current signal target.

A signal requests an action from a process. kill normally sends SIGTERM, the usual termination request. It does not delete the program's stored file. Some programs can handle or delay the request, so sending it and confirming completion are different steps.

wait asks this shell to wait for the named job. A termination can give a nonzero status, and a completed job may already have left the job table. Record what actually happened. Waiting for this harmless sleep to finish naturally is always an alternative to signaling it.

sleep 60 &

background sleep: may be running; PID unknown; job number unknown

not observed

03Try a single owned wait

Keep the complete activity in one Bash terminal in the owned environment. It creates no files and requests no privileged access. If you cannot identify your new job with confidence, let it complete naturally rather than guessing a target.

For the paper route, use the worksheet's complete timeline: no new wait, then a newly listed wait, then completion or termination, then no running activity wait. Label the PID and job number as changing runtime details. Explain which event ends the process and which merely reports it.

Identify only the running job you created

A process is a running program instance. Its PID is an operating-system
identifier; a jobspec belongs to one shell. Compare jobs -l before and
after creating your harmless wait. The example %1 is usable only if
that new job is currently job 1. Otherwise use its current identifier,
or let the wait complete naturally. Never paste this sheet as a script.

The timeline is a prediction, not a running job.
Run in one Bash terminal in owned guest; sleep is harmless waiting.
sleep 60 &
jobs -l
Identify only that sleep job; use its current jobspec, e.g. %1 if it
is actually job 1. Example numbers are not a real target.
kill %1
wait %1
jobs -l
kill normally requests termination, not deletion of a stored file.
wait may return a nonzero termination status; jobs may already be empty.
If sleep finished naturally, do not reuse a stale PID or jobspec.
Fallback timeline: created sleep job -> listed -> terminated or completed.
Question fixed row: PID 731, command sleep; file suffix .txt is separate.
Which identifies this running instance for PID-directed kill? PID/extension

1. Run jobs -l first and note any pre-existing jobs privately; leave them alone. Start exactly one new sleep 60 & and immediately run jobs -l again.
2. Identify the newly created sleep job and its current jobspec/PID from your observation. Expected: a new waiting instance if it has not already completed. Do not use the worksheet's fictional numbers.
3. To end only this job while it is still listed, use kill with its actual jobspec, e.g. kill %1 only if the created job is currently job 1. Replace the example number with the observed job number. Alternatively wait for its 60-second natural completion.
4. Use wait with that same valid jobspec if still present, then jobs -l. A termination-related nonzero status or an already-removed job entry can occur; record actual messages rather than inventing a fixed output. Expected: the owned wait ends; other jobs remain unaffected.
5. Before closing, confirm your created wait is finished. If unsure which job is yours, wait naturally and do not signal a guess. There are no activity files to delete and no system process to restart.

04Optional challenge

Allow about ten extra minutes. A note records yesterday's PID, while a current jobs listing uses %2. Explain why the old number cannot identify a current process safely and why %2 also needs the correct shell context. No additional signals are needed.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Terminal A, before: job 1, PID 2410, sleep 300, already running in background.
Action in terminal A: start exactly one new sleep 60 &.
Terminal A, immediately after:
  job 1, PID 2410, sleep 300, running
  job 2, PID 2448, sleep 60, running
Separate terminal B: job 2, PID 2519, sleep 60, already running before this activity.
The new activity wait has not finished. These are paper identities, not live targets.

Case F: in an otherwise idle shell, sleep 25 starts without & and is still running.
Case B: in another otherwise idle shell, sleep 25 & starts and is still running.
No job is stopped and no other command or event changes either shell.
Independent Case E: a background sleep has ended naturally; the shell observed completion.

Saved file: sleep, the program instructions. No file is deleted or modified.
Running before: PID 2804 sleep; PID 2809 sleep; PID 2831 editor.
An authorized SIGTERM request targets only PID 2804.
A later observation confirms PID 2804 ended. No other process ends.
This card supplies confirmation, rather than assuming every signal ends a process immediately.

The owned activity sleep is job 3, PID 3184 in terminal C.
You then switch to terminal D. Its job 3 is PID 3201, unrelated work.
No current observation from terminal C has been made since the switch.
The task remains ending or waiting for only the activity wait.

06Explain a bounded process action

Optional self-check: describe the evidence needed before and after requesting termination of one owned wait.

Check your explanation: compare creation-time and current same-shell job evidence; distinguish shell-local jobspecs from PIDs; allow natural completion; distinguish sending SIGTERM from confirming an end; account for unrelated instances and stored files.