emmyakine/codecrafters-shell-csharp

1. This repository is a C#/.NET implementation of a POSIX-like shell for the CodeCrafters “Build Your Own Shell” challenge. The runtime entry point is src/main.cs, and the app is packaged as codecrafters-shell.csproj / codecrafters-shell.sln.

2. The core runtime boundary is the interactive shell loop in src/Shell.cs. It is responsible for reading user input, handing it off for parsing/dispatch, and coordinating execution results back to the terminal.

3. Input parsing is isolated in src/Tokenizer.cs and src/Token.cs. This layer turns raw command text into shell tokens, which is the main front door for handling quoting, separators, arguments, and other command-line syntax before execution.

4. After tokenization, src/CommandDispatcher.cs appears to be the orchestration layer that decides what kind of command is being run. It likely routes between builtin commands, external programs, pipelines, redirections, and special shell behaviors.

5. Built-in shell behavior is separated into src/BuiltinCommands.cs. This is where shell-native commands like cd, pwd, echo, or similar challenge-required commands are handled without spawning a child process.

6. External program execution is encapsulated in src/ExternalCommand.cs. This forms the boundary to the host operating system: resolving an executable, launching it, and capturing its exit behavior/output as needed by the shell.

7. Path and command lookup are handled by src/PathResolver.cs. This is the subsystem that maps command names to executable locations using the environment/search path semantics expected from a shell.

8. Multi-command execution is handled separately in src/PipelineRunner.cs. This is the execution graph for connecting commands together, likely managing stdin/stdout chaining so one command’s output becomes the next command’s input.

9. Input/output redirection is modeled explicitly via src/RedirectSpec.cs. That suggests redirection is parsed into a distinct execution descriptor instead of being handled inline, which keeps command execution and file I/O concerns separated.

10. Background jobs and shell job tracking are split across src/Jobs.cs and src/JobTable.cs. These classes form the stateful subsystem for job control, storing running processes and enabling status/reporting behavior typical of shells.

11. src/AutoCompletionHandler.cs is a separate user-experience layer for interactive completion. It likely depends on the current shell state, known commands, and filesystem/path context rather than being part of command execution itself.

12. src/ICommand.cs is the abstraction that ties the execution model together. It suggests the shell treats builtins, external commands, and possibly pipeline elements through a common command interface, which makes the dispatcher simpler and keeps execution polymorphic.

13. The repository also includes CodeCrafters-specific tooling: .codecrafters/compile.sh, .codecrafters/run.sh, codecrafters.yml, and your_program.sh. These are the challenge harness and launch scripts, not core shell logic, and they mainly define how the solution is built and executed in the grading environment.

14. Overall data flow: terminal input enters Shell, gets tokenized, interpreted by the dispatcher, then executed through one of several execution paths—builtin handler, external process runner, pipeline executor, or job control. That separation is the key architecture boundary for diagramming this repo.