So I finished the “Run a program“ stage by using Linux’s sh shell. var psi = new ProcessStartInfo { FileName = "/bin/sh", Arguments = $"-c \"exec -a {split[0]} {resl.ExecutablePath}{args}\"", UseShellExecute = false };
It works but… Isn’t this a bit like cheating? I tried this stage using Process.Start(ExcecutablePath, Args) at first, which works just fine. But it returns the whole executable path during the test instead of just the command name, which caused the test to fail. It does work with something like Figlet or something. Or am I overthinking this?
Well, yes, you are implementing your shell by having another shell do it for you. Lots of interacting factors that make this work, such as inheriting of I/O handles, fact that the shell used (Bash-like) is also the target of the challenge. Someone people have gotten quite far into the challenge using the system C-function call which does similar, but eventually proper argument handling, redirection, pipelines, etc, becomes difficult if one hasn’t made the proper fundamentals inside their shell.
So “cheating”? Well no proctors here will arrest you for doing this, but does seem against the spirit to implement a shell by having another shell do the job.
yeah totally, but I don’t really get how are we supposed to follow without having the theory and concepts behind building a shell. How can we build those proper fundamentals ?
I’ve helped quite a bit for people trying the Shell Challenge and I agree with you. Some kind of high-level overview early on of the general operation of a shell would be very useful and at least prevent people from going down a wrong path.
Maybe try the interpreter challenge first since that one is based on an existing book that you can refer to. After all, a bash shell is basically an interpreter, just set up in REPL mode (read-evaluate-print-loop).
That being said, there are additional challenges to implementing a shell, such as autocompletions (whereas the interpreter challenge only needs to parse complete statements).