git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/3] t: teach 'test_must_fail' to save the command's stderr to a file

From
Jeff King <peff@peff.net>
Date
Feb 9, 2018, 14:21 UTC
Message-ID
<20180209142131.GA18701@sigill.intra.peff.net>
In-Reply-To
<20180209024235.3431-3-szeder.dev@gmail.com>
On Fri, Feb 09, 2018 at 03:42:34AM +0100, SZEDER Gábor wrote:
Show 19 quoted lines
> To check that a git command fails and to inspect its error message we
> usually execute a command like this throughout our test suite:
> 
>   test_must_fail git command --option 2>output.err
> 
> Note that this command doesn't limit the redirection to the git
> command, but it redirects the standard error of the 'test_must_fail'
> helper function as well.  This is wrong for several reasons:
> 
>   - If that git command were to succeed or die for an unexpected
>     reason e.g. signal, then 'test_must_fail's helpful error message
>     would end up in the given file instead of on the terminal or in
>     't/test-results/$T.out', when the test is run with '-v' or
>     '--verbose-log', respectively.
> 
>   - If the test is run with '-x', the trace of executed commands in
>     'test_must_fail' will go to stderr as well (except for more recent
>     Bash versions supporting $BASH_XTRACEFD), and then in turn will
>     end up in the given file.

I have to admit that I'm slightly negative on this approach, just because:

  1. It requires every caller to do something special, rather than just
     using normal redirection. And the feature isn't as powerful as
     redirection. E.g., some callers do:
       test_must_fail foo >output 2>&1
     But:
       test_must_fail stderr=output foo >output
     is not quite right (stdout and stderr outputs may clobber each
     other, because they have independent position pointers).
  2. The "-x" problems aren't specific to test_must_fail at all. They're
     a general issue with shell functions.

I'm not entirely happy with saying "if you want to use -x, please use bash". But given that it actually solves the problems everywhere with no further effort, is it really that bad a solution?

For the error messages from test_must_fail, could we go in the same direction, and send them to descriptor 4 rather than 2? We've already staked out descriptor 4 as something magical that must be left alone (see 9be795fb). If we can rely on that, then it becomes a convenient way for functions to make sure their output is going to the script's stderr.

-Peff
Previous: Eric SunshineNext: Junio C Hamano
Message 5 of 13 in “Teach 'test_must_fail' to save the command's stderr to a file”
  1. 0/3 Teach 'test_must_fail' to save the command's stderr to a fileSZEDER Gábor, Feb 9, 2018
  2. 1/3 t: document 'test_must_fail ok=<signal-name>'SZEDER Gábor, Feb 9, 2018
  3. 2/3 t: teach 'test_must_fail' to save the command's stderr to a fileSZEDER Gábor, Feb 9, 2018
  4. Eric SunshineFeb 9, 2018
  5. Jeff KingFeb 9, 2018
  6. Junio C HamanoFeb 9, 2018
  7. Jeff KingFeb 9, 2018
  8. Jeff KingFeb 9, 2018
  9. SZEDER GáborFeb 23, 2018
  10. 3/3 t1404: use 'test_must_fail stderr=<file>'SZEDER Gábor, Feb 9, 2018
  11. Eric SunshineFeb 9, 2018
  12. SZEDER GáborFeb 9, 2018
  13. Junio C HamanoFeb 9, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.