git/list[1] front-page[2] threads[3] people[4] search[5] about
 

CR codes from git commands

From
Brent Goodrick <bgoodr@gmail.com>
Date
Jan 20, 2009, 16:26 UTC
Message-ID
<18805.64312.289059.660023@hungover.brentg.com>
Hi,

I am considering converting from CVS over to using git. I'm currently using git version 1.5.6.5 on Debian Linux "testing". One of the first things I ran into was having to set PAGER to "cat" to avoid the problems when running git from anything other than a terminal. The second thing is that "git pull" (and possibly other commands) are emitting ^M (octal 013) codes on output, possibly caused by the same assumption as causes the problem that is fixed by setting PAGER to "cat". This is not a big deal on small repos, but on larger ones I actually do want to see status line output (or be given some option to see them), so that I can then run "tail -1lf" on the log file that is written during a long "git pull" operation.

Is there some configuration option or some environment variable I can set that tells git to stop treating every invocation as if it is coming from a terminal?

You can reproduce this on Linux with the following script (look for the CR codes on the final git pull at the end of the script):

-- cut below this line --- #!/bin/sh

# I could have simply used "set -x" here but then I wouldn't see the
# redirection syntax like ">file1", so instead use a PrintRun
# function:
PrintRun ()
{
    echo "COMMAND: $*"
    eval "$*; exitcode=\$?"
    if [ $exitcode != 0 ]
    then
        echo "ERROR: Command failed: $*"
        exit 1
    fi
}

# Failed attempt at hacking around git insisting on using ^M codes on stderr: # cat >/tmp/git_pager <<EOF # sed 's%^% >> %g' # # This doesn't work either since the output I want to filter is on stderr # # tr '\013' '\012' # EOF # chmod a+x /tmp/git_pager # GIT_PAGER=/tmp/git_pager; export GIT_PAGER

# Clear out the scratch areas: PrintRun rm -rf /tmp/git_area1 PrintRun rm -rf /tmp/git_area2 # Populate the initial area: PrintRun mkdir -p /tmp/git_area1 PrintRun cd /tmp/git_area1 PrintRun git init PrintRun "echo a new file 1 >file1" PrintRun "echo a new file 2 >file2" PrintRun git add file1 PrintRun git add file2 PrintRun git status PrintRun "git commit -m \"first commit in git_area1\"" PrintRun find . # Clone from the first area into a second area and add a file there: PrintRun rm -rf /tmp/git_area2 PrintRun cd /tmp PrintRun git clone /tmp/git_area1 git_area2 PrintRun cd /tmp/git_area2 PrintRun find . PrintRun "echo a new file 3 >file3" PrintRun git add file3 PrintRun git status PrintRun "git commit -m \"second commit but in git_area2\"" PrintRun "git status; true" # true means don't fail inside PrintRun PrintRun "git status; true" # true means don't fail inside PrintRun # Now attempt to somehow refresh (what is the "git" word for "cvs update"?) into the first area: PrintRun cd /tmp/git_area1 PrintRun "git status; true" # true means don't fail inside PrintRun PrintRun "git diff; true" # true means don't fail inside PrintRun # PrintRun "git pull /tmp/git_area2 master 2>&1" # PrintRun "git pull /tmp/git_area2 master 2>&1 | tr '\013' '\012'" PrintRun git pull /tmp/git_area2 master -- cut above this line ---

Attempts at hacking around the problem: Redirecting stderr output from git and then manually translating CR codes into LF codes yeilds the following output (but I can't do this in practice and, no, I can't use aliases in Bourne scripts (Bash/KSH yes, Bourne no)):

git> COMMAND: git pull /tmp/git_area2 master 2>&1 git> remote: Counting objects: 4, done. git> remote: Compressing objects: 50% (1/2) git> --> remote: Compressing objects: 100% (2/2) git> --> remote: Compressing objects: 100% (2/2 )Unpacking objects: 33% (1/3) git> --> Unpacking objects: 66% (2/3) git> --> Unpacking objects: 100% (3/3) git> --> Unpacking objects: 100% (3/3), done. git> remote: , done. git> remote: Total 3 (delta 0), reused 0 (delta 0) git> From /tmp/git_area2 git> * branch master -> FETCH_HEAD git> Updating b2f942d..4f9ba90 git> Fast forward git> file3 | 1 + git> 1 files changed, 1 insertions(+), 0 deletions(-) git> create mode 100644 file3

Trying to automatically filter this with redirection and use of tr fails to show the progress output completely which is a non-option either:

git> COMMAND: git pull /tmp/git_area2 master 2>&1 | tr '\013' '\012' git> From /tmp/git_area2 git> * branch master -> FETCH_HEAD git> Updating 49b1897..bb5f57c git> Fast forward git> file3 | 1 + git> 1 files changed, 1 insertions(+), 0 deletions(-) git> create mode 100644 file3

Thanks, bgoodr

Next: Johannes Schindelin
Message 1 of 24 in “CR codes from git commands”
  1. Brent GoodrickJan 20, 2009
  2. Johannes SchindelinJan 20, 2009
  3. Daniel BarkalowJan 22, 2009
  4. Brent GoodrickJan 22, 2009
  5. Daniel BarkalowJan 22, 2009
  6. Junio C HamanoJan 22, 2009
  7. Mike RalphsonJan 22, 2009
  8. Brent GoodrickJan 22, 2009
  9. Mike RalphsonJan 22, 2009
  10. Johannes SchindelinJan 22, 2009
  11. Daniel BarkalowJan 22, 2009
  12. Johannes SchindelinJan 22, 2009
  13. Brent GoodrickJan 23, 2009
  14. Junio C HamanoJan 23, 2009
  15. Johannes SchindelinJan 23, 2009
  16. Brent GoodrickJan 24, 2009
  17. Johannes SchindelinJan 24, 2009
  18. Boyd Stephen Smith Jr.Jan 25, 2009
  19. Brent GoodrickJan 25, 2009
  20. Brent GoodrickFeb 2, 2009
  21. The lifecycle of a patch and the maintainer involvementJunio C Hamano, Jan 25, 2009
  22. Brent GoodrickJan 21, 2009
  23. Johannes SchindelinJan 21, 2009
  24. Brent GoodrickJan 22, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.