我在运行Linux的计算机上运行的服务会创建一个 命名管道 字符设备专用文件，我想编写一个Python3程序，该程序通过编写文本命令和读取文本答复来与服务进行通信 管设备。我没有该服务的源代码。

我可以使用os.open(named_pipe_pathname, os.O_RDWR)，也可以使用os.read(...)和os.write(...)来读写它，但这很痛苦，因为我必须编写自己的代码才能在字节和字符串之间进行转换，还必须编写自己的readline(...)函数，等等。

我宁愿使用Python3 io对象来读写管 设备，但是我能想到的每种方式都会返回相同的错误：

io.UnsupportedOperation: File or stream is not seekable.

例如，如果我尝试该消息，则open(pathname, "r+")得到该消息；如果我尝试fd=os.open(...)之后，则得到该消息os.fdopen(fd, "r+", ...)。

问：Python3程序在与 命名管道 角色设备？

编辑：

糟糕！我以为我正在处理命名管道，因为该服务的文档将其描述为“管道”，并且因为直到用户模式服务运行，该管道才出现在文件系统中。但是，Linux file实用程序说它实际上是一个字符设备专用文件。

解决方案

发生问题是因为尝试io.open在读写模式下使用时会隐式尝试将基础文件io.BufferedRandom打包（io.TextIOWrapper如果在文本模式下，则将其打包），这假定基础文件不仅是读/写的，而且是随机访问的，而且基于此获得自由（隐式寻求）。有一个单独的类，io.BufferedRWPair旨在与读/写管道一起使用（文档字符串特别提到了它用于套接字和双向管道）。

您可以io.open通过手动逐层包装以产生相同的最终结果来模仿效果。具体来说，对于文本模式包装器，您将执行以下操作：

rawf = io.FileIO(named_pipe_pathname, mode="rb+")
with io.TextIOWrapper(io.BufferedRWPair(rawf, rawf), encoding='utf-8', write_through=True) as txtf:
    del rawf   # Remove separate reference to rawf; txtf manages lifetime now
    # Example use that works (but is terrible form, since communicating with
    # oneself without threading, select module, etc., is highly likely to deadlock)
    # It works for this super-simple case; presumably you have some parallel real code
    txtf.write("abcé\n")
    txtf.flush()
    print(txtf.readline(), flush=True)

我相信关闭rawf时会关闭两次txtf，但是幸运的是，双重关闭在这里是无害的（第二次close不执行任何操作，意识到它已经关闭了）。