Mismatch between instructions and stage behaviour in #ZA2

[EshaanAgg]

I’m stuck on Stage #ZA2

The test instructions show that after the history command is run, we should first show the commands that were loaded from the history file specified by -r, and then the new commands that have been sent to the shell.

Here are the logs from my test run:

remote: [tester::#ZA2] Running tests for Stage #ZA2 (History Persistence - Read history from file)
remote: [tester::#ZA2] Running ./your_program.sh
remote: [tester::#ZA2] Writing contents to /tmp/strawberry.txt
remote: [tester::#ZA2] [/tmp/strawberry.txt] echo apple strawberry orange
remote: [tester::#ZA2] [/tmp/strawberry.txt] echo orange apple
remote: [tester::#ZA2] [/tmp/strawberry.txt] echo pear grape
remote: [your-program] $ history -r /tmp/strawberry.txt
remote: [your-program] $ history
remote: [your-program]         1 echo apple strawberry orange
remote: [tester::#ZA2] Output does not match expected value.
remote: [tester::#ZA2] Expected: "    1  history -r /tmp/strawberry.txt"
remote: [tester::#ZA2] Received: "        1 echo apple strawberry orange"
remote: [your-program]         2 echo orange apple
remote: [your-program]         3 echo pear grape
remote: [your-program]         4 history -r /tmp/strawberry.txt
remote: [your-program]         5 history
remote: [your-program] $ 
remote: [tester::#ZA2] Assertion failed.
remote: [tester::#ZA2] Test failed

As you can see the tester (Expected: " 1 history -r /tmp/strawberry.txt") expects the first line itself to be the history -r command, and not the previous commands loaded. This deviates from the description of the test provided, or am I missing anything?

[rohitpaulk]

Hmm, interesting… wonder how our tests pass against bash We released this since we were had tests passing against bash and were confident there wouldn’t be any major bugs. The logs you shared do seem pretty clear though, that expectation seems off.

We’re looking into this!

[EshaanAgg]

Also, two general (minor) notes:

1. The output of the commands is not correctly formatted in the sample description (a tab is missing at the start of each line)
   

   

2. If would be nice to add a note to this stage which states that you can assume that this command is always the first command that is issued to the shell, as in other cases, we would then have to specify the intended behaviour: should we override the history currently, or should we append to the in-memory history.

[rohitpaulk]

Ah, okay this is an instructions update – it looks like the loading of history happens after history -r is executed, so history -r will indeed be the first in the list. Logs from bash:

We’ll update this soon. And noted re: the other two points – @andy1li to fix!

[EshaanAgg]

Yess! Just verified the same manually too!

Also another small gotcha, in the sample file content on the website, we should mention having a \n after the last command, otherwise the same would not load.

Like, if the file content is:

echo hello
echo world

with no trailing newline, then the output of the bash shell is:

You can see that the echo world command is skipped altogether.

The tester works correctly and adds a newline always to the end, but explicitly calling it out might help with local testing and debugging!

[andy1li]

Hey @EshaanAgg, I tried loading a history file without a trailing newline, and can also confirm that the last line would be omitted.

[adamadair]

The description of the test is wrong. If the test tests for BASH like output, then move line 3 to line 1.

Make your code work like that and tests pass.

[adamadair]

Also, the test description should show the stupid 4 space indent that it is testing for. If you make the output look like the test description it will fail.

[Arpan-206]

The instructions should better reflect the tester behavior now!
We’ve also updated the tester to check for the new lines.

Thanks for the feedback @EshaanAgg, @adamadair!