4

我正在尝试使用我的命令行 git 客户端和 Python 的 I/O 重定向来自动化许多 git repos 上的一些常见操作。(是的,这是 hack-ish。我以后可能会回去使用 Python 库来执行此操作,但现在它似乎工作正常 :))

我希望能够捕获调用 git 的输出。隐藏输出看起来会更好,捕获它会让我记录它以防万一它有用。

我的问题是,当我运行“git clone”命令时,我只能得到第一行的输出。奇怪的是,带有“git status”的相同代码似乎工作得很好。

我在 Windows 7 上运行 Python 2.7,并且正在使用 cmd.exe 命令解释器。

到目前为止我的调查:

  1. 当我用“git clone”调用 subprocess.call() 时,它运行良好,我在控制台上看到了输出(这证实了 git 正在产生输出,即使我没有捕获它)。这段代码:

    dir = "E:\\Work\\etc\\etc"
    os.chdir(dir)
    git_cmd = "git clone git@192.168.56.101:Mike_VonP/bit142_assign_2.git"
    
    #print "SUBPROCESS.CALL" + "="*20
    #ret = subprocess.call(git_cmd.split(), shell=True) 
    

    将在控制台上生成此输出:

    SUBPROCESS.CALL====================
    Cloning into 'bit142_assign_2'...
    remote: Counting objects: 9, done.
    remote: Compressing objects: 100% (4/4), done.
    remote: Total 9 (delta 0), reused 0 (delta 0)
    Receiving objects: 100% (9/9), done.
    Checking connectivity... done.
    
  2. 如果我直接用 POpen 做同样的事情,我会在控制台上看到相同的输出(也没有被捕获)。这段代码:

    # (the dir = , os.chdir, and git_cmd= lines are still executed here)
    print "SUBPROCESS.POPEN" + "="*20
    p=subprocess.Popen(git_cmd.split(), shell=True)
    p.wait()
    

    将产生这个(实际上相同的)输出:

    SUBPROCESS.POPEN====================
    Cloning into 'bit142_assign_2'...
    remote: Counting objects: 9, done.
    remote: Compressing objects: 100% (4/4), done.
    remote: Total 9 (delta 0), reused 0 (delta 0)
    Receiving objects: 100% (9/9), done.
    Checking connectivity... done.
    

    (显然我在运行之间删除了克隆的 repo,否则我会收到“一切都是最新的”消息)

  3. 如果我使用communicate() 方法,我期望得到一个包含我在上面看到的所有输出的字符串。相反,我只看到这条线 Cloning into 'bit142_assign_2'...
    这段代码:

    print "SUBPROCESS.POPEN, COMMUNICATE" + "="*20
    p=subprocess.Popen(git_cmd.split(), shell=True,\
                bufsize = 1,\
                stderr=subprocess.PIPE,\
                stdout=subprocess.PIPE)
    tuple = p.communicate()
    p.wait()
    print "StdOut:\n" + tuple[0]
    print "StdErr:\n" + tuple[1]
    

    将产生这个输出:

    SUBPROCESS.POPEN, COMMUNICATE====================
    StdOut:
    
    StdErr:
    Cloning into 'bit142_assign_2'...
    

    一方面,我重定向了输出(正如您从它不在输出中的事实中看到的那样),但我也只捕获了第一行。

我已经尝试了很多很多东西(调用check_output而不是popen,使用带有subprocess.call的管道,使用带有subprocess.popen的管道,以及可能我忘记的其他东西)但没有任何效果 - 我只捕获第一行的输出。

有趣的是,完全相同的代码确实可以与 'git status' 一起正常工作。一旦 repo 被克隆,调用 git status 会产生三行输出(统称为“一切都是最新的”),第三个示例(POpen+communicate 代码)确实捕获了所有三行输出。

如果有人对我做错了什么有任何想法,或者对我可以尝试的任何事情有任何想法,以便更好地诊断这个问题,我将不胜感激。

4

2 回答 2

3

这里有两个感兴趣的部分,一个是特定于 Python 的,一个是特定于 Git 的。

Python

使用该subprocess模块时,您可以选择控制所运行程序的最多三个 I/O 通道:stdin、stdout 和 stderr。subprocess.callsubprocess.check_call以及都是如此subprocess.Popen,但两者都call立即check_call调用新进程对象的方法,因此出于各种原因,为 stdout 和/或 stderr 提供这两个操作wait是不明智的。1subprocess.PIPE

除此之外, usingsubprocess.call等同于 using subprocess.Popen。实际上,代码call是单行的:

def call(*popenargs, **kwargs):
    return Popen(*popenargs, **kwargs).wait()

如果您选择不重定向任何 I/O 通道,读取输入的程序会从 Python 的同一个地方获取它,将输出写入 stdout 的程序将其写入您自己的 Python 代码的同一个地方,2和写入的程序输出到 stderr 将其写入 Python 的相同位置。

当然,您可以将 stdout 和/或 stderr 重定向到实际文件以及subprocess.PIPEs. 文件和管道不是交互式“终端”或“tty”设备(即,不被视为直接连接到人类)。这将我们引向 Git。

吉特

Git 程序通常可以从标准输入读取和/或写入标准输出和/或标准错误。Git 也可能调用其他程序,这些程序可能会做同样的事情,或者可能会绕过这些标准 I/O 通道。

特别git clone是,正如您所观察到的,主要写入其标准错误。此外,正如mhawke 回答的那样,您必须添加--progress以使 Git 将进度消息写入 stderr Git 不与交互式 tty 设备交谈。

https如果通过或克隆时 Git 需要密码或其他身份验证ssh,Git 将运行辅助程序来获取此信息。在大多数情况下,这些程序完全绕过标准输入(通过/dev/tty在 POSIX 系统上打开,或在 Windows 上打开),以便与用户交互。在您的自动化环境中,这将如何运作,或者它是否会运作是一个很好的问题(但又超出了此答案的范围)。但这确实让我们回到了 Python,因为......

Python

除了subprocess模块之外,还有一些外部库sh和,以及一些通过模块pexpect内置到 Python 本身中的工具,它们可以打开伪 tty:一个交互式 tty 设备,它不是直接连接到人,而是连接到你的程序。pty

使用 ptys 时,您可以让 Git 的行为与它直接与人交谈时的行为相同——事实上,今天“与人交谈”实际上是使用 ptys(或等效项)完成的,因为有运行各种窗口系统的程序. 此外,要求人类输入密码的程序现在可能3与您自己的 Python 代码交互。这可能是好是坏(甚至两者兼而有之),因此请考虑您是否希望这种情况发生。


1具体来说,该communicate方法的重点是管理最多三个流之间的 I/O 流量,如果它们中的任何一个或全部是PIPE,则无需子进程楔。想象一下,如果你愿意,一个子进程将 64K 文本打印到 stdout,然后将 64K 文本打印到 stderr,然后再将 64K 文本打印到 stdout,然后从 stdin 读取。如果您尝试以任何特定顺序读取或写入其中任何一个,子进程将“卡住”,等待您清除其他内容,而您将卡住等待子进程完成您选择先完成的任何一个。相反,communicate使用线程或特定于操作系统的非阻塞 I/O 方法来提供子进程输入,同时读取其 stdout 和 stderr,所有这些都同时进行。

换句话说,它处理了多路复用。因此,如果您没有为三个 I/O 通道subprocess.PIPE中的至少两个提供电源,则绕过该communicate方法是安全的。如果,则不是(除非您实现自己的多路复用)。

这里有一个有点奇怪的边缘案例:如果您提供subprocess.STDOUTstderr 输出,这会告诉 Python 将子进程的两个输出定向到单个通信通道。这仅算作一个管道,因此如果您将子进程的 stdout 和 stderr 组合在一起,并且不提供任何输入,则可以绕过该communicate方法。

2事实上,子进程继承了进程的 stdin、stdout 和 stderr,它们可能与 Python 的sys.stdin,不匹配sys.stdoutsys.stderr如果你覆盖了这些。这进入细节可能最好在这里忽略。:-)

3我说“可能”而不是“将”,因为/dev/tty访问控制终端,并不是所有的 pty 都是控制终端。这也变得复杂且特定于操作系统,并且也超出了此答案的范围。

于 2016-09-19T03:56:36.897 回答
2

尝试将--progress选项添加到您的 git 命令。即使 git 进程未连接到终端,这也会强制 git 将进度状态发送到 stderr - 通过subprocess函数运行 git 时就是这种情况。

git_cmd = "git clone --progress git@192.168.56.101:Mike_VonP/bit142_assign_2.git"

print "SUBPROCESS.POPEN, COMMUNICATE" + "="*20
p = subprocess.Popen(git_cmd.split(), stderr=subprocess.PIPE, stdout=subprocess.PIPE)
tuple = p.communicate()
p.wait()
print "StdOut:\n" + tuple[0]
print "StdErr:\n" + tuple[1]

注意我无法在 Windows 上测试它,但它在 Linux 上有效。

此外,不需要指定shell=True,这可能是一个安全问题,因此最好避免。

于 2016-09-19T02:28:43.650 回答