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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 30, 2012, at 11:22 PM, Junio C Hamano wrote:
> 
> A more likely failure case is when fd 0, 1 and 2 are _closed_.
> 
> I vaguely recall we once saw a failure report for that particular
> case, and then audited the code several years ago, but I do not
> offhand know if we have regressed over time.

Thanks all for your suggestions about where to look.  I've been doing
some more experiments, and I see that Junio's comment is very relevant.

Here's what I learned this morning: it appears to work when I don't
close STDIN.

    #close $_ for *STDIN, *STDOUT, *STDERR; # What I was doing. Fails.
    close $_ for *STDOUT, *STDERR;  # Tried this, it works.
    *STDOUT = $log_fh;
    *STDERR = $log_fh;

Jeff King wrote:
> Could it be not related to a terminal at all, but that
> there is a problem writing to the original stdout?

Writing to stdout, stderr are both fine.  I've been doing
  print STDOUT "Stdout test.\n";
  print STDERR "Stderr test.\n";
right before the git commands to ensure that STDOUT, STDERR are hooked
up fine to the log file.

But, you gave me a hint that led to an error message.

In a test rig where I've been looking at this just now, I was using
backticks and losing
a message to stderr:
 'cd /local/test_web; git pull --ff-only | cat'   rc=0 out={{}}
 'cd /local/test_web; git pull --ff-only 2>&1 | cat'   rc=0 out={{fatal:
 The remote end hung up unexpectedly
 
Note however:  despite the "fatal", I am seeing rc=0 and I was observing
my working
copy update as expected, so I wasn't looking for error output.

> 1. We check isatty(2) to enable progress reporting by default. You can
> use --no-progress to disable this.

I don't see "--no-progress" making any difference.

>  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.

Ahh, this could be it:  when the pull does receive an output and I'm
running
the command in the shell, I get output with a "+-" where the plus is
green
and the minus red.  So, I think that git may be trying to check whether
color
 (and columns?) is supported to output.  However, it appears that this
 check
is sensitive to stdin being connected (based on test mentioned earlier
here),
which is surprising.

Is the code that calls isatty, calling it on all 3 descriptors, even
when
STDIN is not relevant?

>  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.

Yes, I tried the env switch just to be sure, and this doesn't appear
relevant.

-Travis

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]