threads / discuss / 56081

Troubles redirecting git output

Subject: Troubles redirecting git output

## tl;dr

3 messages between Jul 9, 2021 and Jul 9, 2021.

replies: 2people: 2as markdown or json

Baptiste Chocot· Jul 9, 2021, 11:59 UTC · lore
Hello guys, hope you're doing great.

I'm reaching out today because I cannot find a fix for my issue. I'm using git 2.25.1 from the debian repo. I'm having difficulties to redirect git stderr, here is an example:

--- $ git init Initialized empty lol/.git/ $ git branch >&2 2>/dev/null fatal: your current branch 'master' does not have any commits yet ---

Is this an expected behavior? I find it weird not to be able to silent git. Are you aware of a workaround? I've been browsing a bit but did not find an answer yet.

Thanks for your time!
Baptiste
Marc Branchaud· Jul 9, 2021, 13:40 UTC · re: Baptiste Chocot · lore

Re: Troubles redirecting git output

On 2021-07-09 7:59 a.m., Baptiste Chocot wrote:
Show 10 quoted lines
> Hello guys, hope you're doing great.
> 
> I'm reaching out today because I cannot find a fix for my issue. I'm 
> using git 2.25.1 from the debian repo. I'm having difficulties to 
> redirect git stderr, here is an example:
> 
> ---
> $ git init
> Initialized empty lol/.git/
> $ git branch >&2 2>/dev/null
Try swapping the two redirections:
	git branch 2>/dev/null >&2
I believe that standard shell behaviour is to apply a redirection 
immediately when it appears while parsing the command.  I believe that 
although the man pages say "redirect" internally the code just 
*replaces* the old file descriptor, e.g. basically something equivalent to
	stdout = 2
So when you say
	git branch >&2 2>/dev/null
The shell sees
">&2" -- The shell redirects stdout to file descriptor 2.

"2>/dev/null" -- The shell opens /dev/null (as descriptor 3) and *replaces* descriptor 2 with the new descriptor. But at this point, stdout is still being sent to the original descriptor 2.

When I redirect, I'm in the habit of setting stdout first, then set 
stderr to stdout. The numerical ordering helps me avoid this mistake:
	git branch >/dev/null 2>&1
		M.
Show 11 quoted lines
> fatal: your current branch 'master' does not have any commits yet
> ---
> 
> Is this an expected behavior? I find it weird not to be able to silent 
> git. Are you aware of a workaround? I've been browsing a bit but did not 
> find an answer yet.
> 
> Thanks for your time!
> 
> Baptiste
> 
Baptiste Chocot· Jul 9, 2021, 19:20 UTC · re: Marc Branchaud · lore

Re: Troubles redirecting git output

Marc,

Thanks for your help... :facepalm: I look like a noob but at least I've learnt something useful.

Have a good day!
On 7/9/21 9:40 AM, Marc Branchaud wrote:
Show 52 quoted lines
> On 2021-07-09 7:59 a.m., Baptiste Chocot wrote:
>> Hello guys, hope you're doing great.
>>
>> I'm reaching out today because I cannot find a fix for my issue. I'm 
>> using git 2.25.1 from the debian repo. I'm having difficulties to 
>> redirect git stderr, here is an example:
>>
>> ---
>> $ git init
>> Initialized empty lol/.git/
>> $ git branch >&2 2>/dev/null
>
> Try swapping the two redirections:
>     git branch 2>/dev/null >&2
>
> I believe that standard shell behaviour is to apply a redirection 
> immediately when it appears while parsing the command.  I believe that 
> although the man pages say "redirect" internally the code just 
> *replaces* the old file descriptor, e.g. basically something 
> equivalent to
>     stdout = 2
>
> So when you say
>
>     git branch >&2 2>/dev/null
>
> The shell sees
>
> ">&2" -- The shell redirects stdout to file descriptor 2.
>
> "2>/dev/null" -- The shell opens /dev/null (as descriptor 3) and 
> *replaces* descriptor 2 with the new descriptor.  But at this point, 
> stdout is still being sent to the original descriptor 2.
>
> When I redirect, I'm in the habit of setting stdout first, then set 
> stderr to stdout. The numerical ordering helps me avoid this mistake:
>     git branch >/dev/null 2>&1
>
>         M.
>
>
>> fatal: your current branch 'master' does not have any commits yet
>> ---
>>
>> Is this an expected behavior? I find it weird not to be able to 
>> silent git. Are you aware of a workaround? I've been browsing a bit 
>> but did not find an answer yet.
>>
>> Thanks for your time!
>>
>> Baptiste
>>

← back to recent threads