从皮查姆（Pycharm）启动时，办公室的管道通信不起作用

Question

我正在尝试在Pycharm中开发Libreoffice Calc python宏。我想在皮查姆内部进行测试。当在Pycharm外部启动libreoffice时，测试工作正常，但是当我尝试直接从Pycharm内部启动它时失败。

我尝试了两种不同的方法来启动libreoffice。

从我的Ubuntu终端

/opt/libreoffice6.4/program/soffice --calc --accept="pipe,name=lopipe;urp;StarOffice.ServiceManager" --nologo&
具有python函数：

args = ["/opt/libreoffice6.4/program/soffice", "--calc",
        "--accept=\"pipe,name=lopipe;urp;StarOffice.ServiceManager\""]
subprocess.Popen(args, universal_newlines=True)
以下代码为我提供了活动工作表。

def current_active_sheet():
    localContext = uno.getComponentContext()
    resolver = localContext.ServiceManager.createInstanceWithContext(
        "com.sun.star.bridge.UnoUrlResolver", localContext)
    ctx = resolver.resolve("uno:pipe,name=lopipe;urp;StarOffice.ComponentContext")
    desktop = ctx.ServiceManager.createInstanceWithContext("com.sun.star.frame.Desktop", ctx)
    model = desktop.getCurrentComponent()
    return model.CurrentController.ActiveSheet

当从ubuntu终端启动Libreoffice时，current_active_sheet函数在Pycharm内部运行良好，例如从测试模块调用。但是，当使用python subprocess.Popen从Pycharm启动Libreoffice时，尽管libreoffice正确运行，该函数仍会引发连接异常。

我已经尝试过为uno bridge使用套接字和管道选项，并获得相同的行为。

lsof跟踪给出了一些奇怪的东西，好像pycharm没有将管道名传递给系统。

这里是从ubuntu终端启动libreoffice时lsof结果的摘录，有对lopipe的引用

soffice.b 13506 13517             yves    7u     unix 0x0000000000000000       0t0     336561 /tmp/OSL_PIPE_1000_SingleOfficeIPC_6e6e1dcdf8a8f89eb21d8fe15230aa95 type=STREAM
soffice.b 13506 13517             yves   54u     unix 0x0000000000000000       0t0     310587 /tmp/OSL_PIPE_1000_lopipe type=STREAM
与从[subprocess.Popen]从皮查姆（Pycharm）启动Libreoffice时的提取相同。根本没有lo ...

soffice.b 13407 13418             yves    7u     unix 0x0000000000000000       0t0     307196 /tmp/OSL_PIPE_1000_SingleOfficeIPC_6e6e1dcdf8a8f89eb21d8fe15230aa95 type=STREAM
soffice.b 13407 13419             yves    7u     unix 0x0000000000000000       0t0     307196 /tmp/OSL_PIPE_1000_SingleOfficeIPC_6e6e1dcdf8a8f89eb21d8fe15230aa95 type=STREAM

我正在尝试在Pycharm中开发Libreoffice Calc python宏。我想在皮查姆内部进行测试。当在Pycharm外部启动libreoffice时，测试工作正常，但是当我尝试启动它时失败了...

Answer 1

[如果在子进程中启动，请包含一个时间延迟，例如time.sleep()，以便LO在执行API代码之前有几秒钟的启动时间。从终端启动时不需要此操作，因为顺序启动允许LO有时间启动。通常，我建议从终端启动LO，尽管应该可以通过子进程启动LO。