On 26.11.2021 13:02, Junio C Hamano wrote:
Fabian Stelzer <fs@xxxxxxxxxxxx> writes:
In any case, the comment in front of the block of exec wants to
become a bit more detailed than just "# Set up additional fds", with
an explanation about which FD is used for what.
How about:
# Set up additional fds to allow i/o with the surrounding test
# harness when redirecting individual test i/o in test_eval_
This does not quite say how "setting up additional fds" helpss the
test harness, though. And this ...
# fd 5 -> stdout
# fd 6 <- stdin
# fd 7 -> stderr
... is literal translation of what is written below, without adding
any new information.
exec 5>&1
exec 6<&0
exec 7>&2
I was expecting something along the lines of ...
# What is written by tests to their FD #1 and #2 are sent to
# different places depending on the test mode (e.g. /dev/null in
# non-verbose mode, piped to tee with --tee option, etc.) Original
# FD #1 and #2 are saved away to #5 and #7, so that test framework
# can use them to send the output to these low FDs before the
# mode-specific redirection.
... but this only talks about the output side. The final version
needs to mention the input side, too.
I like to use the term stdin/err/out since that is what i would grep for
when trying to find out more about the test i/o behaviour.
I understand that you would like to give exaxples what the fd aliases
are used for and I think thats a good idea. But I'm having a bit of a
hard time understanding the use of the stdin alias. I did not find a
single use in the test suite - but my grep might not have been complete.
Or if it's just there for the sake of completeness.
As far as i understand the test framework runs the individual tests in
test_eval_ redirecting its stdout/err to fd #3 & #4 (with some xtracefd
logic for -x) and passing /dev/null as stdin to the test. What would FD
#6 actually be used for then? A test lib function being called from
within a test that expects user input?