Skip to content

Replace exit 0 with just exit #173

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 21, 2025
Merged

Replace exit 0 with just exit #173

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c168913
Refine exit command documentation to remove optional exit status deta…
andy1li Nov 20, 2025
4b8f7cf
Update command completion and exit behavior documentation for clarity
andy1li Nov 20, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 3 additions & 15 deletions stage_descriptions/base-04-pn5.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,7 @@ In this stage, you'll implement the `exit` builtin.

The [`exit`](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#exit) builtin is a special command that terminates the shell.

It takes an optional numeric argument as the shell's [exit status](https://en.wikipedia.org/wiki/Exit_status):
```bash
$ exit 0 # Exit with status 0 (success)
$ exit 1 # Exit with status 1 (error)
```

When your shell receives the `exit` command, it should terminate immediately with the specified exit code.
When your shell receives the `exit` command, it should terminate immediately.

### Tests

Expand All @@ -25,13 +19,7 @@ It will then send an invalid command to your shell, followed by the `exit` comma
```bash
$ invalid_command_1
invalid_command_1: command not found
$ exit 0
$ exit
```

The tester will verify that:
- Your shell terminates after receiving the `exit` command
- Your shell exits with status code `0`

### Notes

- The tester will always pass in `0` as the argument to the `exit` command.
The tester will verify that your shell terminates after receiving the `exit` command.
15 changes: 8 additions & 7 deletions stage_descriptions/completions-02-gm9.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
In this stage, you'll extend your shell's tab completion to handle commands with arguments.

Check warning on line 1 in stage_descriptions/completions-02-gm9.md

View workflow job for this annotation

GitHub Actions / LLM Doc Lint

explanation_sections_after_hook (stage_descriptions/completions-02-gm9.md) failed 

tools/llm-linter/reports/junit.xml
Raw output 
The document goes straight to "### Tests" after the hook and contains no titled explanation section (### <Title>) before the tests, which the rule requires.

Suggested fixes:
  - type: "insert"
  - position: "{"path":"/home/runner/work/build-your-own-shell/build-your-own-shell/courses/build-your-own-shell/stage_descriptions/completions-02-gm9.md","line":2}"
  - content: "### Handling Argument Completion\n\n"

Check warning on line 1 in stage_descriptions/completions-02-gm9.md

View workflow job for this annotation

GitHub Actions / LLM Doc Lint

explanations_sections_order (stage_descriptions/completions-02-gm9.md) failed 

tools/llm-linter/reports/junit.xml
Raw output 
The document goes from the hook directly to ### Tests without any titled explanation section. The required order is Hook -> one or more titled explanation sections -> ### Tests.

Suggested fixes:
  - action: "insert_heading"
  - location: "after the first paragraph (hook) and before '### Tests'"
  - heading_text: "### Handling Argument Completions"

Check warning on line 1 in stage_descriptions/completions-02-gm9.md

View workflow job for this annotation

GitHub Actions / LLM Doc Lint

hook_one_sentence (stage_descriptions/completions-02-gm9.md) failed 

tools/llm-linter/reports/junit.xml
Raw output 
There are four sentences before the first heading; the hook must be exactly one sentence.

Suggested fixes:
  - description: "Keep a single-sentence hook and move the remaining pre-heading sentences under an 'Explanation' heading."
  - replacement: "In this stage, you'll extend your shell's tab completion to handle commands with arguments.\n\n### Explanation\n\nYour shell should now not only complete the command itself but also correctly handle the subsequent arguments that the user types.\nThis means that after completing the command with `<TAB>`, it should allow the user to continue typing arguments, and those arguments should also be interpreted correctly.\nYou'll need to ensure commands like `echo` autocomplete and still function correctly with arguments.\n\n### Tests\n\nThe tester will execute your program like this:\n\n```bash\n./your_program.sh\n```\n\nThe tests will simulate user input with tab presses and will execute builtin commands, similar to the previous stage, with added arguments:\n\n1.  **Input:** `ech<TAB>` `hello<ENTER>`\n\n    - The tester expects the shell to first complete the `ech` to `echo` after `<TAB>`, then accept the `hello` argument, and after the `<ENTER>` key press, execute `echo hello`.\n    - The shell should output `hello`.\n\n2.  **Input:** `ech<TAB>` `foo bar<ENTER>`\n    - The tester expects the shell to first complete `ech` to `echo` after `<TAB>`, then accept the `foo bar` arguments, and after the `<ENTER>` key press, execute `echo foo bar`.\n    - The shell should output `foo bar`.\n\nThe tester will verify that your shell properly completes the commands and executes the commands with the given arguments.\n"
  - path: "/home/runner/work/build-your-own-shell/build-your-own-shell/courses/build-your-own-shell/stage_descriptions/completions-02-gm9.md"

Your shell should now not only complete the command itself but also correctly handle the subsequent arguments that the user types.
This means that after completing the command with `<TAB>`, it should allow the user to continue typing arguments, and those arguments should also be interpreted correctly.
You'll need to ensure commands like `echo ` and `type` autocomplete and still function correctly with arguments.
You'll need to ensure commands like `echo` autocomplete and still function correctly with arguments.

### Tests

Expand All @@ -12,14 +12,15 @@
./your_program.sh
```

The tests will simulate user input with tab presses and will execute builtin commands, similar to the previous stage, with added arguments:

Check warning on line 15 in stage_descriptions/completions-02-gm9.md

View workflow job for this annotation

GitHub Actions / LLM Doc Lint

stage_references_plural (stage_descriptions/completions-02-gm9.md) failed 

tools/llm-linter/reports/junit.xml
Raw output 
Found 1 invalid singular reference to other stages: 'the previous stage' (line 15). The rule requires plural phrasing such as 'earlier stages' or 'previous stages'.

Suggested fixes:
  - line: 15
  - original: "The tests will simulate user input with tab presses and will execute builtin commands, similar to the previous stage, with added arguments:"
  - replacement: "The tests will simulate user input with tab presses and will execute builtin commands, similar to earlier stages, with added arguments:"

1. **Input:** `ech<TAB>` `hello<ENTER>`
* The tester expects the shell to first complete the `ech` to `echo` after `<TAB>`, then accept the `hello` argument, and after the `<ENTER>` key press, execute `echo hello`.
* The shell should output `hello`.

2. **Input:** `exi<TAB>` `0<ENTER>`
* The tester expects the shell to first complete `exi` to `exit` after `<TAB>`, then accept the `0` argument, and after the `<ENTER>` key press, execute `exit 0`.
* The shell should exit with status code 0.
- The tester expects the shell to first complete the `ech` to `echo` after `<TAB>`, then accept the `hello` argument, and after the `<ENTER>` key press, execute `echo hello`.
- The shell should output `hello`.

The tester will verify that your shell properly completes the commands and executes the commands with the given arguments.
2. **Input:** `ech<TAB>` `foo bar<ENTER>`
- The tester expects the shell to first complete `ech` to `echo` after `<TAB>`, then accept the `foo bar` arguments, and after the `<ENTER>` key press, execute `echo foo bar`.
- The shell should output `foo bar`.

The tester will verify that your shell properly completes the commands and executes the commands with the given arguments.
6 changes: 3 additions & 3 deletions stage_descriptions/history-persistence-05-kz7.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
In this stage, you'll add support for writing the in-memory history to the history file when exiting.

Check warning on line 1 in stage_descriptions/history-persistence-05-kz7.md

View workflow job for this annotation

GitHub Actions / LLM Doc Lint

document_style (stage_descriptions/history-persistence-05-kz7.md) failed 

tools/llm-linter/reports/junit.xml
Raw output 
The document is instructional and conversational (“you’ll”, “your program”), but it lacks explanatory background about what the history file is and why writing on exit is needed; it focuses only on test steps.

Suggested fixes:
  - target: "after_intro"
  - type: "add_explanatory_context"
  - content: "Shells maintain a command history so you can recall commands across sessions. The history file persists this history to disk; writing it when the shell exits ensures the current session’s commands are saved for the next run."

Check warning on line 1 in stage_descriptions/history-persistence-05-kz7.md

View workflow job for this annotation

GitHub Actions / LLM Doc Lint

explanations_sections_order (stage_descriptions/history-persistence-05-kz7.md) failed 

tools/llm-linter/reports/junit.xml
Raw output 
The document places ### Tests immediately after the hook and contains no titled explanation section(s). The required order is Hook, one or more Explanation section(s), then ### Tests, and optional ### Notes.

Suggested fixes:
  - action: "insert_section"
  - location: "before ### Tests"
  - section_title: "### Explanation"
  - content: "..."

### Tests

Check warning on line 3 in stage_descriptions/history-persistence-05-kz7.md

View workflow job for this annotation

GitHub Actions / LLM Doc Lint

explanation_sections_after_hook (stage_descriptions/history-persistence-05-kz7.md) failed 

tools/llm-linter/reports/junit.xml
Raw output 
After the initial hook, the document jumps directly to "### Tests" with 0 titled explanation sections. The rule requires at least 1 explanation section before Tests.

Suggested fixes:
  - line: 3
  - description: "Insert at least one titled explanation section before the Tests section."
  - action: "insert_before_line"
  - content: "### History Persistence Overview\nDescribe the expected behavior when exiting: write all in-memory history entries to the file specified by HISTFILE in the same order, include the exit command, and end with a trailing newline so the file has an empty last line.\n"

Expand All @@ -15,14 +15,14 @@
hello
$ echo world
world
$ exit 0
$ exit
```

The tester will then expect the history file's contents to look like:

```txt
echo hello
echo world
exit 0
exit
<|EMPTY LINE|>
```
```
6 changes: 3 additions & 3 deletions stage_descriptions/history-persistence-06-jv2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
In this stage, you'll add support for appending the in-memory history to the history file when exiting.

Check warning on line 1 in stage_descriptions/history-persistence-06-jv2.md

View workflow job for this annotation

GitHub Actions / LLM Doc Lint

explanation_sections_after_hook (stage_descriptions/history-persistence-06-jv2.md) failed 

tools/llm-linter/reports/junit.xml
Raw output 
Document goes straight from the initial hook paragraph to "### Tests" with zero titled explanation sections. The rule requires at least one "### <Title>" explanation section after the hook and before Tests.

Suggested fixes:
  - action: "insert_section_before"
  - anchor_heading: "### Tests"
  - content: "### History Persistence Overview\nExplain what it means to append the in-memory history to the history file on exit: how HISTFILE determines the path, that existing lines are preserved and new in-memory entries (including the exit command) are appended, and that the file should end with a trailing newline. Clarify behavior for empty in-memory history and how duplicates should be handled if applicable."

Check warning on line 1 in stage_descriptions/history-persistence-06-jv2.md

View workflow job for this annotation

GitHub Actions / LLM Doc Lint

explanations_sections_order (stage_descriptions/history-persistence-06-jv2.md) failed 

tools/llm-linter/reports/junit.xml
Raw output 
The document has a Hook followed directly by the ### Tests section with no titled explanation section before it. The rule requires one or more titled explanation sections between the Hook and ### Tests.

Suggested fixes:
  - action: "insert_section"
  - position: "before"
  - relative_to_heading: "### Tests"
  - content: "### Understanding History Persistence\nDescribe how and when to append in-memory history to the history file on shell exit, how HISTFILE is used, and which commands should be written.\n"

### Tests

Expand All @@ -21,7 +21,7 @@
```bash
$ echo new_command
new_command
$ exit 0
$ exit
```

The tester will then expect the history file's contents to look like:
Expand All @@ -30,6 +30,6 @@
echo initial_command_1
echo initial_command_2
echo new_command
exit 0
exit
<|EMPTY LINE|>
```
```
Loading