fatal output from git-show really wants a terminal

It appears that when outputting a fatal error, git-show will choose stdout over stderr if stdout is a terminal and stderr is not. How do I redirect the error but still allow stdout to be displayed?

~/git$ mkdir test

~/git$ cd test

~/git/test$ git init

~/git/test$ git show 12345

fatal: ambiguous argument '12345': unknown revision or path not in the working tree. Use '--' to separate paths from revisions

~/git/test$ git show 12345 2> /dev/null

fatal: ambiguous argument '12345': unknown revision or path not in the working tree. Use '--' to separate paths from revisions

~/git/test$ git show 12345 > /dev/null

fatal: ambiguous argument '12345': unknown revision or path not in the working tree. Use '--' to separate paths from revisions

~/git/test$ git show 12345 > /dev/null 2> /dev/null

~/git/test$ git show 12345 > /tmp/out 2> /tmp/err

~/git/test$ cat /tmp/out

~/git/test$ cat /tmp/err

fatal: ambiguous argument '12345': unknown revision or path not in the working tree. Use '--' to separate paths from revisions

On Wednesday 2008 December 10 10:01:49 you wrote:

Gah, I think that's really bad behavior. Anyway, something like: git show 12345 2>/dev/null | cat should work. Neither stdout nor stderr will be a terminal, but stdout will be displayed to your terminal.

On Mittwoch, 10. Dezember 2008, Tim Olsen wrote:

This is by design.

$ git show 12345 2> /dev/null | less

You see this through the pager.

And this went through the pager as well.

This went straight to the terminal.

The pattern is that if stdout is a terminal, the pager is thrown up and both stdout and stderr of git show proper are redirected to the pager. If you redirect only stderr, then this redirection is actually ignored.

-- Hannes

Johannes Sixt wrote:

I see.  So I probably want to use --no-pager.

Thanks for the help.

-Tim

On Wednesday 2008 December 10 13:46:50 you wrote:

Then it is poor design. :P j/k

Why not use the pager only if git-show is "interactive", using the same test for interactivity as SUSv3/POSIX shells use? IIRC, a shell is interactive if both stdin and stderr are terminals. That test for interactivity -- a associated difference in behavior -- predates git by a number of years. Is there a reason for being different? Is the porcelain consistent about that behavior?

On Thursday 2008 December 11 03:15:47 you wrote:

Seeing how I'm new, and this message indicated I had screwed up, I starting going through the 'git log' looking for a commit message that either documented this behavior, or indicated the commit had documented this behavior.

Initially, I was looking for 'stdout' or 'stderr', and found many unrelated commits. I then figured it was part of the PAGER support, and began searching for that. I did find an indication of why stdout and stderr are both redirected to the PAGER's stdin -- but that makes sense to me; I wasn't questioning it. At least not too much -- but when the user indicates stderr and stdout should go to different locations, shouldn't they?

I was mainly questioning using a pager AT ALL when the git command is used in a non-interactive environment, and how git detects an interactive invocation. I feel this should be done the same way a (POSIX standard) shell detects interactivity, and that in a non-interactive environment git should not default to using PAGER.

Now, I certainly could have missed the commit message / commit with rationale / documentation. 'git log' output is a long document, and I maybe using the wrong keywords for my search. It also is not all the documentation that is out there. I'm not afraid to RTFM; but I'm not having much luck finding the right parts to R.

Finally, I didn't mean to offend. I was hoping the smiley (":P") and "j/k" would indicate that a was only half serious and know that I don't have the benefit of following the project closely for very long. I'm appreciative of the hard work that goes into git and don't mean to belittle that effort.

On Thu, Dec 11, 2008 at 10:51:15AM -0600, Boyd Stephen Smith Jr. wrote:

Try looking for isatty, which takes the numeric fd. I think the behavior you asked about would be this:

On Thursday 2008 December 11 15:55:55 Jeff King wrote:

Thanks, this will be plenty of context for me to be able to crawl the archives and the actual history thinking about better behavior and considering old discussions.

Good point, I'll try and consider that while I investgate the history of the issue.

I did see a commit message mentioning some unusual settings for PAGER, but in general, pagers are interactive. I'd think the default behavior would be "interactive <-> pager", with a config option to turn the pager always off or always on. From there, I would reason the test for interactivity should be the POSIX test.

It looks like this test have have been attempting to follow the behavior of --color=auto to GNU less and GNU grep (and possibly others). This certainly makes some sense as well, and may be less surprising.

Google should be able to find it. And worst-case, I can tell wget to spider the archives and then run some sort of find/html2txt/grep on them.

I'll go back to "the stacks" and read the discussions and commits. If my well-informed self still thinks the behavior should change, I'll write a patch and open up the discussion again.

On Thu, Dec 11, 2008 at 04:45:05PM -0600, Boyd Stephen Smith Jr. wrote:

Right, but then that leads to the case I mentioned before. I think you want to say "this is interactive _and_ our stdout is going to the interactive spot". Which by your definition would be isatty() on stdin, stderr, and stdout.

And maybe that is a better test, but I think it would be helpful to provide a concrete example where that behavior works and the current behavior doesn't.

Yes. You'll see we use a similar test for git's "auto" color.

I have the complete archive, and I couldn't find anything useful. ;)

Let me know if you want a copy (or you can pull it straight from gmane, but it is somewhat slow IIRC).

-Peff

"Boyd Stephen Smith Jr." <bss03@volumehost.net> writes:

Isn't the issue about 61b8050 (sending errors to stdout under $PAGER, 2008-02-16)? With that commit, we changed things so that when we send the standard output to the $PAGER, we dup stderr to the $PAGER as well, because otherwise any output to stderr will be wiped out by whatever the pager does and the user will not notice the breakage. E.g.

	$ git log

will just show reams of output, and you won't see any errors and warnings even if there were any encountered during the process.

Unfortunately we did it unconditionally. There is no reason to dup stderr to the $PAGER if the command line was:

	$ git log 2>error.log

in which case you would want to view the normal output in your $PAGER and you are keeping the log of the error output in a separate file.

Junio C Hamano <gitster@pobox.com> writes:

I haven't heard anything more about this, but if you were indeed discussing the change made by 61b8050, I think the fix should just be like this.

 pager.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Junio C Hamano <gitster@pobox.com> writes:

By the by, I noticed that the example shown in the commit message of 61b8050 has been broken since 4f3dcc2 (Fix 'git show' on signed tag of signed tag of commit, 2008-07-01).

Here is a fix.

 builtin-log.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

On Mon, Dec 15, 2008 at 12:15:38AM -0800, Junio C Hamano wrote:

I can't speak for the original poster, but I do think this behavior should be less surprising to users who perform the one particular redirection (and in the other 99% of cases, should behave exactly the same). So I think it's a positive change.

-Peff