我的问题：我想使用我选择的客户端 ( mutt)离线阅读电子邮件，但我希望移动电子邮件等操作与 imap 服务器保持在双向 snc 中。
我的问题：是否有一个简单的方法来做到这一点，同时仍然使用标准工具一样fetchmail，procmail等？
我有一个 Gmail 帐户。出于各种原因——一些机构——我需要能够从邮件客户端读取这封邮件；我希望我的“收件箱”是干净的，就像我将它保留在传统的本地邮件设置中一样，并且对于我“存档”的任何内容都可以进行搜索。如果我将电子邮件移动到 Web 客户端中的文件夹，我希望本地收件箱考虑到这一点。
如果可能，我希望能够从mutt. 之前我使用了 mutt 的原生 imap 功能，但是每次运行 mutt 都必须连接到服务器；当我阅读邮件时，连接经常掉线，并且 mutt 在后台打开；它只保留消息头的缓存，加载新消息需要往返服务器；如果我发送消息，我必须等待它通过 STMP 得到确认，然后才能查看任何其他消息。
有没有办法解决这个问题？我不认为像 Thunderbird 这样的胖客户端是一个解决方案：我需要终端访问，我喜欢能够 grep 我的邮件，我很好地利用了 procmail 的过滤功能，我更喜欢解耦系统。
如上所述，fetchmail,procmail并sendmail让我 几乎到了那里 - 但不能让我的活动在客户端之间保持同步。
我错过了什么吗？我已经查看了 FreeBSD 手册中关于电子邮件的部分和一堆博客文章，但似乎没有什么能以这种方式将它们整合在一起。
顺便说一句，我运行 Arch Linux 和 Debian。
我有三种不同格式的数据；对于每种数据类型，都有一个 Python 脚本将其转换为单一的统一格式。
这个 Python 脚本很慢并且受 CPU 限制（到多核机器上的单核），所以我想运行它的三个实例 - 每个数据类型一个 - 并将它们的输出组合起来将它传递到sort. 基本上，相当于：
{ ./handle_1.py; ./handle_2.py; ./handle_3.py } | sort -n
但是三个脚本并行运行。
我发现了这个问题，其中 GNUsplit被用来在处理流的脚本的 n 个实例之间循环一些标准输出流。
从拆分手册页：
-n, --number=CHUNKS
generate CHUNKS output files. See below
CHUNKS may be:
N split into N files based on size of input
K/N output Kth of N to stdout
l/N split into N files without splitting lines
l/K/N output Kth of N to stdout without splitting lines
r/N …我想让一个进程从一个从多个源接收数据的命名管道中读取：
$ mkfifo /tmp/p
但我不知道如何让它始终如一地工作。
tty1 :
设置两个进程写入我的fifo；这两个都会阻止：
$ echo 'first' > /tmp/p; echo 'second' > /tmp/p
tty2 :
从管道中读取：
$ cat /tmp/p
first
second
如果我以相反的顺序执行上述操作，这仍然有效
当我有两个单独的命令想要从管道中出来时，我的问题就出现了：
第一个.sh
#!/bin/sh
echo 'first' > /tmp/p
第二个.sh
#!/bin/sh
echo 'second' > /tmp/p
tty1
$ sh first.sh; sh second.sh
tty2
$ cat /tmp/p
first
sh second.sh从我的第一个 tty执行将无限期地阻塞，直到从命名管道中读取其他内容。
来自http://linux.die.net/man/7/pipe：
如果所有引用管道写端的文件描述符都已关闭，则尝试从管道读取（2）将看到文件结束（读取（2）将返回 0）
因此，当echo退出 in 时first.sh，执行它的 shell 会关闭 的文件描述符/tmp/p，这意味着cat在我的第二个 …
有时我想在管道中插入一些东西以用于报告或其他一些次要用途。它可能像 一样简单wc -l，或更复杂，awk比如甚至是 python 脚本。运行这样的管道会很好：
zcat my_data_file.gz \
| wc -l > /tmp/linecount
| process_data.py
问题是大多数实用程序不会将数据正确输出到标准输出。tee可以将数据写入临时文件，但是我必须等到一切完成：
zcat my_data_file.gz \
| tee /tmp/f \
| process_data.py && \
wc -l /tmp/f > /tmp/linecount && rm /tmp/f
这不是最佳的：它可能是一个运行时间非常长的管道；我可能希望更快地看到类似物的中间结果wc；我可能不想将所有数据存储在临时文件中。