The current task descriptions seem to push people toward designs that don’t really match how actual shells work. A maintainable shell is usually grammar-driven and built around a lexer/parser, but the challenge never mentions these ideas. Moreover, it suggests handling tilde expansion inside the cd command, while real shells do expansion in a separate stage that applies to any command. Because of that, it’s easy to finish the challenge without ever seeing how shell grammar, parsing, and evaluation actually work, or ever running into the practical details that matter in real implementations. I get that challenges are feature-driven and try not to prescribe specific approaches, but skipping industry-standard concepts makes the learning outcome feel pretty limited. It would really help if the “Concepts” tab included more insight into these fundamentals. The current entries (like the PATH variable explanation) don’t really guide people toward building something closer to a real shell or understanding the architecture behind it.
3 Likes
Yep this is something we should correct. This is my fault, wasn’t aware that tilde was a generic expansion when we worked on the initial stage breakdown. Whenever we do an extension for expansion we’ll correct this.
As for grammar – yep that’s valid too. We can update our instructions to mention this. I think the long-term approach here is to have great code examples that showcase valid approaches, and maybe also share links to how popular shells implement it. Prescribing an approach might not always work since there are often multiple valid approaches. We tried doing code walkthroughs with Redis back in the day, maybe more of those would help.
2 Likes