Re: How to handle terminal detection in a daemon calling git?

From: Jeff King <peff@peff.net>
Date: May 31, 2012, 01:29 UTC
Message-ID: <20120531012908.GD5488@sigill.intra.peff.net>
In-Reply-To: <1338412607.9452.140661082904349.02F677C3@webmail.messagingengine.com>

On Wed, May 30, 2012 at 04:16:47PM -0500, Travis P wrote:

Show 15 quoted lines

> I've got a script that runs in the background without a terminal.
> It actually does have STDOUT and STDERR set to a rotating log file.
> 
> When it runs:
>   /bin/sh -c 'cd /to/my/wc; git pull --ff-only'
> the git command fails (rc 32768).
> 
> When it runs
>  /bin/sh -c 'cd /to/my/wc; git pull --ff-only > /to/a/file 2>&1'
> 
> or even
>  /bin/sh -c 'cd /to/my/wc; git pull --ff-only | cat'
> 
> then all is well.  The command succeeds (rc 0, and I see the expected
> results).

If your stdout and stderr are not a terminal in the first place (you say they go to a rotating log file), then that should not be making a difference. Are they connected by a pty or something odd?

Can you describe the failure in the first case more? Does git produce any output?

> Piping through 'cat' is okay, but I'd rather avoid the 'trick'.  Is
> there some way to communicate to git that it should operate just as if
> output were redirected?

Git cares about terminals in only a few cases:

  1. We check isatty(2) to enable progress reporting by default. You can
     use --no-progress to disable this. However, in your final example
     you only redirect stdout, which makes me think that stderr is not
     relevant.

  2. We check isatty(1) for starting a pager, auto-selecting color, and
     in recent versions of git, for column support. But none of those
     things should be in use by git-pull anyway.

  3. Merge was changed recently to open an editor when we have a
     terminal. That can be changed by setting GIT_MERGE_AUTOEDIT=no in
     the environment. However, since you pass --ff-only, we shouldn't be
     running merge at all.

So I'm confused. Could it be not related to a terminal at all, but that there is a problem writing to the original stdout? Something that might give git a SIGPIPE? Can you describe the original stdout destination more?

-Peff