Mismatch between expected and received in JV1

[akhi3030]

I’m stuck on Stage #JV1

I believe I have implemented the solution correctly and I see the correct output when I run the test locally. However, I see a different out put when running codecrafters test and I cannot explain the difference.

When I run codecrafters test, I get:

remote: [tester::#JV1] Running tests for Stage #JV1 (Redirection - Redirect stdout)
remote: [tester::#JV1] Running ./your_program.sh
remote: [tester::#JV1] Writing file "/tmp/foo/apple" with content "apple"
remote: [tester::#JV1] Writing file "/tmp/foo/grape" with content "grape"
remote: [tester::#JV1] Writing file "/tmp/foo/orange" with content "orange"
remote: [your-program] $ ls /tmp/foo > /tmp/quz/baz.md
remote: [your-program] $ cat /tmp/quz/baz.md
remote: [your-program] apple
remote: [your-program] grape
remote: [your-program] orange
remote: [tester::#JV1] ✓ Received redirected file content
remote: [your-program] $ echo 'Hello Emily' 1> /tmp/quz/qux.md
remote: [your-program] $ cat /tmp/quz/qux.md
remote: [your-program] Hello Emily
remote: [tester::#JV1] ✓ Received redirected file content
remote: [your-program] $ cat /tmp/foo/grape nonexistent 1> /tmp/quz/quz.md
remote: [your-program] /usr/bin/cat: nonexistent: No such file or directory
remote: [tester::#JV1] Output does not match expected value.
remote: [tester::#JV1] Expected: "cat: nonexistent: No such file or directory"
remote: [tester::#JV1] Received: "/usr/bin/cat: nonexistent: No such file or directory"
remote: [your-program] $
remote: [tester::#JV1] Assertion failed.
remote: [tester::#JV1] Test failed (try setting 'debug: true' in your codecrafters.yml to see more details)

Note the problem is that the difference between the expected and the received output is that in the expected output, the name of the program is cat and in the received output, the name of the output is /usr/bin/cat.

When I run the test locally, I cannot reproduce the same issue, e.g.:

➜  codecrafters-shell-rust git:(master) ./your_program.sh
    Finished `release` profile [optimized] target(s) in 0.00s
$ mkdir /tmp/foo
$ echo grape > /tmp/foo/grape
$ cat /tmp/foo/grape
grape
$ cat /tmp/foo/grape nonexistent 1> /tmp/a
cat: nonexistent: No such file or directory

And here’s a snippet of my code:

fn handle_other_command(
    mut stdout: Box<dyn io::Write>,
    mut stderr: Box<dyn io::Write>,
    path: &[String],
    argv0: String,
    argv: &[String],
) {
    match look_in_path(path, &argv0) {
        Some(argv0) => {
            let res = Command::new(argv0).args(argv).output().unwrap();
            let out = String::from_utf8_lossy(&res.stdout);
            let err = String::from_utf8_lossy(&res.stderr);
            write!(stdout, "{}", out).unwrap();
            write!(stderr, "{}", err).unwrap();
        }
        None => writeln!(stdout, "{}: command not found", argv0).unwrap(),
    }
}

I am wondering if somehow there is an unexpected difference between the test machine and my local setup and that is causing the problem.

[akhi3030]

Published my code in GitHub - akhi3030/codecrafters-shell-rust.

[andy1li]

Hi @akhi3030, looks like you’ve got past this stage — do you happen to remember what was wrong? Would love to see if we can improve the tester / instructions.

[akhi3030]

Sadly, I couldn’t figure out what the actual problem was and I hacked my way around it. I added the following line to my code:

            let err = match err.strip_prefix("/usr/bin/") {
                None => err.to_string(),
                Some(res) => res.to_string(),
            };

Essentially, if I see the unnecessary /usr/bin/ in the output, I remove it just to pass the test.

[andy1li]

Thanks for sharing the details! We’ll look into the issue and keep you updated on any progress.

[akhi3030]

Great, thanks for looking into it. If it helps, I am running locally on a mac and haven’t tried running my code on a linux machine.

[andy1li]

Hi @akhi3030, the issue can be avoided if you run the command directly without using the full path:

[akhi3030]

Hi @andy1li. Thanks for getting back to me. I suppose it is down to some system differences why look_in_path is returning different results. But this makes sense.