Re: [PATCH v3 3/3] test-lib: make BAIL_OUT() work in tests and prereq

[Fabian Stelzer <fs@gigacodes.de>]

On 26.11.2021 13:02, Junio C Hamano wrote:
>Fabian Stelzer <fs@gigacodes.de> 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?