The error is at echo command followed by stderr redirection to a file. It works fine locally, but remote tester throws an error.
remote: [your-program] $ echo 'David file cannot be found' 2> /tmp/qux/foo.md
remote: [tester::#VZ4] Failed to read file ("/tmp/qux/foo.md"): open /tmp/qux/foo.md: no such file or directory
remote: [your-program] David file cannot be found
remote: [your-program] $
remote: [tester::#VZ4] Assertion failed.
I believe that 2nd line (Failed to read…) comes from your tester that for some reason expects this file to exist. Please note, I ran all previous tests and they all pass.
This exact problem was reported earlier in the forums, but there was no definite answer.
That is actually the expected behaviour of a shell.
If we have a command CMD > FILE, then even before the execution of CMD, the shell would always open a stream to FILE (and that requires creating the file if it doesn’t exist). Only after the stream is established successfully, would the command CMD be executed.
The reasoning behind the same is simple: the shell doesn’t know whether CMD would be writing to STDOUT, STDERR, both of them, or even none. Thus it always first creates the required files, sets up these redirection streams, and then executes the command.
Your implementation is not creating the required (empty) file, and thus the tester is failing.
@andy1li Do you think it would be worthwhile calling out this behaviour explicitly in the test description?
Thanks for the quick and thorough answer. That makes total sense and I can see bash does that too (not sure how I missed it).
Despite my wrong reasoning, looking at my code again I believe I do create that file with the call to open with a proper flag. I tested it works locally, but only for files that are in an existing directory (same as in bash).
I do wonder, if the /tmp/qux folder from your tests exists? That would maybe explain the failure. Well, I should definitely add checks to my open call too, regardless.
It seems the bug was elsewhere when detecting the stderr redirection But your answer helped me understand the details and lead me to run the debugger again and look for the problem earlier in the code. Thanks!
But your answer helped me understand the details and lead me to run the debugger again and look for the problem earlier in the code. Thanks!