Invoke child tools with bounded checked commands
See this course’s project requirements
A local Python release script that validates source, runs tests, packages only allowlisted files, writes checksums and stops on a failing stage.
Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.
What to include
- Create an ordered stage/gate map with explicit failure branches.
- Document the exact child command, working directory, timeout, and failure interpretation.
- Create and inspect an actual archive whose member list exactly matches the release allowlist.
- Recompute the delivered archive digest and explain integrity versus correctness/provenance.
- Demonstrate failed-test stop and byte-preserving overwrite refusal in isolated copies.
- Deliver one declared local release with stage, package, checksum, failure, and operational-limit evidence.
Review and revise
Use these criteria to check your work and choose what to improve.
- The implementation or declared simulation follows the supplied contract and retains inspectable original inputs.
- Normal, boundary and rejected cases are recorded with expected versus observed results.
- The changed case has a correct explanation and does not rely on hidden state.
- The project includes source, outputs, instructions and honest tool, privacy and verification limits.
Want more background?
The idea in everyday life
Original local greeting project: greeting.py, test-greeting.py, usage.txt, release.py and test-pipeline.py. Its release archive may contain only greeting.py and usage.txt. No external CI account, deployment, or package installation is required.
An argument list avoids shell string interpretation. A timeout bounds a child run, while a nonzero status and captured output must remain visible in failure evidence.
Invoke child tools with bounded checked commands — original worked practice
An argument list avoids shell string interpretation. A timeout bounds a child run, while a nonzero status and captured output must remain visible in failure evidence.
Original local greeting project: greeting.py, test-greeting.py, usage.txt, release.py and test-pipeline.py. Its release archive may contain only greeting.py and usage.txt. No external CI account, deployment, or package installation is required.
1. Step 1
Inspect subprocess.run([sys.executable,"test-greeting.py"],cwd=root,check=True,timeout=10,...).
You should see: The command uses the current interpreter and a separate argument list.
An argument list avoids shell string interpretation. A timeout bounds a child run, while a nonzero status and captured output must remain visible in failure evidence.
2. Step 2
Run python3 test-greeting.py directly and retain its two-method result.
You should see: The underlying test command can be repeated outside the pipeline.
An argument list avoids shell string interpretation. A timeout bounds a child run, while a nonzero status and captured output must remain visible in failure evidence.
3. Step 3
Read the pipeline failure report and note captured-output limitations: detailed child output is available in the subprocess exception, not a complete production log system.
You should see: Failure status is not silently converted to success.
An argument list avoids shell string interpretation. A timeout bounds a child run, while a nonzero status and captured output must remain visible in failure evidence.
4. Step 4
Record executable, working directory, timeout, and exit-code rule.
You should see: A repeatable bounded-command specification.
An argument list avoids shell string interpretation. A timeout bounds a child run, while a nonzero status and captured output must remain visible in failure evidence.
What to finish
Document the exact child command, working directory, timeout, and failure interpretation.
Watch for this
Using an unchecked shell string or treating timeout interruption as a completed test.
How can I tell I understand it?
Demonstrate the rule: An argument list avoids shell string interpretation. A timeout bounds a child run, while a nonzero status and captured output must remain visible in failure evidence. Use the supplied variant to distinguish a changed result from a broken implementation.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
Pass the check. We’ll save the progress.
Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.
Go to the knowledge checkTools, templates, and lesson sources
Tools and templates
Tools open in a new tab so you can keep your place here.
Sources and further reading
Explore the references behind this lesson.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.