On Wed, May 30, 2012 at 04:16:47PM -0500, Travis P wrote:
> 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
--
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