I was stuck in #BR6 for a few months and when I came back I decided to rewrite the code project based on a code example, think I fixed the issue.
Now I’m getting error in #UN3 again:
[tester::#UN3] Running tests for Stage #UN3 (Redirection - Append stderr)
[your-program] $ ls -1 nonexistent >> /tmp/dog/cow.md
[your-program] ls: cannot access ‘nonexistent’: No such file or directory
[tester::#UN3] ^ Line does not match expected value.
[tester::#UN3] Expected: “ls: nonexistent: No such file or directory”
[tester::#UN3] Received: “ls: cannot access ‘nonexistent’: No such file or directory”
[your-program] $
[tester::#UN3] Assertion failed.
[tester::#UN3] Test failed
I was never asked to implement a built in ls. I program seems to print the gnu ls error but the test seems to expect the bsd ls error. Is this my mistake or a bug in the test case?
I could implement ls and fix it but I’m genuinely curious. Thanks.
Usually this is due to processing the PATHdirectories in an incorrect order (the correct one is “left-to-right”), or potentially “caching” the possible executables which means at actual runtime the caching is wrong.
Thanks for your response, but could you clarify how getting the wrong error message has anything to do with PATH? The only way I can think is if PATH has two different ls versions with different messages and my shell grabs the wrong one. Otherwise, pretty sure neither of those is happening but could be wrong.
Yeah, don’t think it’s a PATH issue since ls is being executed. We do expect ls to be on the system, and I thought we handle both BSD vs. GNU error messages - @andy1li will check this and come back with a proper answer here!
This version has a fake builtin that just checks if that specific error was found and transforms it into what the test expected. You can just comment it to see what happens without it.
The reason I think it is a PATH issue is that behavior has been seen before. There can, apparently, be different versions of ls and if the order is wrong the error message will not be the one the tester expects: Cd ~ test is flaky - #13 by hypatia-of-sva . Despite the confusion in terms of output, it is a good test.
Of course it might be something else, but in above case you can see how the wrong path gives the cannot access fragment of the error message.
The topic you mentioned, is similar to mine, but in my case, cd works just fine and I check for permissions. I passed that stage even in my old-implementation branch which didn’t even check for permissions, so don’t know what exactly is problematic for sure.
The permission was just a separate issue in that thread. Look at the examples how the cannot access message comes depending on the order the person used. Thought looking at your code it does seem like the order processed is right.
@Souvlaki42 Thanks for confirming! Would you mind triggering the same error again on your end? That should help me locate it in our system, since I wasn’t able to reproduce it by myself.
Random thought: is this the right permissions? 0o111 . I might remember wrong, but I think there was something about write permission not being some of the executable (or that you should check executable, & 0o111 would be non-zero with only read permissions, right)?
When if you can’t see the problem in your side, then I’ll go on without that fake builtin function for now, or I’ll just commented out.
However, I can’t see any reasons not to accept both versions of the error as valid. Can you?
The expression m.permissions().mode() & 0o111 != 0 will be true if it has any of the R, W, or X permission bits, it doesn’t guarantee that it has X, right?
I see you pass off to Rust’s Command:new which picks “OS-defined” resolution anyway so you resolving paths does not actually matter since they are not used.
But yeah, I am out of suggestions, so I wish you luck.
As to not accept both version, either are fine ls commands. The problem is finding the correct one which is not happening in this case. So unless the tester itself is flawed, which I think more people would have this issue, I’ve seen lots of people have not issue when using access(X_OK) and starting the selected path themselves.
