0

I have some understanding of how the stdout and stderr file descriptors work. But sometimes they don’t catch all the output and I trying to understand why. For example, cloning into a git repo gives the following output:

$ git clone [email protected]:Alex23rodriguez/MyRepo
Cloning into 'MyRepo'...
remote: Enumerating objects: 438, done.
remote: Counting objects: 100% (438/438), done.
remote: Compressing objects: 100% (319/319), done.
remote: Total 438 (delta 96), reused 410 (delta 68), pack-reused 0
Receiving objects: 100% (438/438), 13.09 MiB | 1.73 MiB/s, done.
Resolving deltas: 100% (96/96), done.

but redirecting both stdout and stderr to a file gives unexpected results

$ git clone [email protected]:Alex23rodriguez/MyRepo &> log
(no output)
$ cat log
Cloning into 'MyRepo'...

My question is, what happened to the rest of the printed lines?

1
  • From here: You should use git clone --progress to be able to get the full output. Also it seems you can use unbuffer git clone https://.... Commented Dec 22, 2022 at 22:06

1 Answer 1

4

They were simply never printed: git probably simply checks whether the stdout and stderr file descriptors are ttys, and if not, it omits the pretty print verbose status updates.

3
  • thanks! I didn't know programs could check if they were being piped. My question wasn't specifically about git clone but now it makes sense. Commented Dec 22, 2022 at 22:45
  • 1
    @alex23ro Even ls uses this trick, in respect of number of columns, and of colourising. Try ls versus ls | cat. Commented Dec 23, 2022 at 9:26
  • Hey @ilkkachu! Thanks for the (saving me) edit :) I'll going to revert one single word, for pedantism reasons, hope you'll not be sad :) Commented Dec 23, 2022 at 9:59

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.