stderr

dbus的是一个低延迟，低开销，高可用性的IPC机制。通过dbus的daemon，可以实现进程间通信和函数调用。Windows下，dbus的开发库可以去这里（ http://code.google.com/p/dbus-windows-installer/downloads/list ）下载，在VS设置头文件和lib库的路径即可。若是要编写其Hello World，自然包含客户端和服务端两部分。下面的Hello World代码包含了发送消息和函数调用两部分，分别描述之。 1) 信号 假设客户端发送消息，服务端接收。客户端发送消息的流程如下： 1.创建于dbus daemon的会话连接。 2.创建消息，若有消息参数，附加之（这个一般都有） 3.通过连接发送消息。 1: int main ( int argc, char *argv[]) 2: { 3: DBusError dberr; 4: DBusConnection *dbconn; 5: DBusMessage *dbmsg; 6: char *text; 7: 8: // 初始话错误信息的结构体 9: dbus_error_init (&dberr); 10: 11: // 创建会话连接 12: dbconn = dbus_bus_get (DBUS_BUS_SESSION, &dberr); 13: if (dbus

3个月了，终于把这个问题搞定了，前后学习加动手可能花了1个半月在这个系统搭建上面。我怀着复杂的心情写这篇文章，对很多懂这方面的专家我无话可说，对自己我更不知道该爱还是该恨。 6月中的时候我来到新的公司，接到的第一个任务就是交叉编译dbus，并在目标机上跑起来。我工作快3年了，一直搞的嵌入式开发，说实话在FSK很失败，以前开发环境都是搭好了，我们只是做一些应用程序的开发而已，我自认为最有成就的就是写了LCD和LED驱动。新公司真的有很多牛人，软硬件都懂，自己开始有点自卑。对第一个任务我甚至不知道怎么搭建嵌入式交叉编译环境，指定一个交叉编译工具链都花了我半天的时间，更不要说交叉编译dbus这么复杂的东西了，依赖的库太多，遇到的编译错误也让我摸不着头脑。幸好，这些东西做过就会了，在师傅的带领下我花了10天的时间把dbus交叉编译搞定。编译过程如下： http://blog.chinaunix.net/u3/99283/showart.php?id=1971652 其中有一个隐患在里面。 好了，该运行测试程序，运行的时候发现一些错误一个个解决掉，发现通信有问题。(其实就是交叉编译里面的一个隐患造成的) http://blog.chinaunix.net/u3/99283/showart.php?id=1976658 接下来的1个月被师傅叫去接别的任务，说这个问题可以先缓一下以后解决

1.dbus概念 网上有一篇叫“D-Bus Tutorial”的文章，流传较广。 D-Bus是针对桌面环境优化的IPC（interprocess communication ）机制，用于进程间的通信或进程与内核的通信。最基本的D-Bus协议是一对一的通信协议。但在很多情况下，通信的一方是消息总线。消息总线是一个特殊的应用，它同时与多个应用通信，并在应用之间传递消息。下面我们会在实例中观察消息总线的作用。消息总线的角色有点类似与X系统中的窗口管理器，窗口管理器既是X客户，又负责管理窗口。 支持dbus的系统都有两个标准的消息总线：系统总线和会话总线。系统总线用于系统与应用的通信。会话总线用于应用之间的通信。网上有一个叫d-feet的python程序，我们可以用它来观察系统中的dbus世界。 图1、由d-feet观察到的D-Bus世界 dbus还提供了两个命令行工具用于dbus测试，dbus-send和dbus-monitor，前一个命令用于测试信号的发送，后一个命令用于监控dbus的数据流。 2.dbus概念 有关dbus的基础知识不在本文的范围内，具体的参见dbus的文档。下面给出dbus常用的流程。 2.1建立服务的流程 dbus_bus_get()，建立一个dbus连接； dbus_bus_request_name()，为这个dbus连接(DbusConnection)起名

原文地址：http://www.cnblogs.com/liyiwen/archive/2012/12/02/2798876.html 转载请注明出处。 作者： 唐风 最近在学 Dbus，不过总是不得其门而入。 大部分资料都讲了很多东西却最终没有让我搞清楚怎么用 DBus，不就是一个 IPC 通信的工具么？就没有一点实用些的资料么？看了很多资料之后还是觉得只见树木不见森林。仔细整理下思路，觉得还是应该从最基本的方面入门，先从 DBus 的 C API 入手学习，有了这些知识，就算麻烦，也可以先在完成一个基本功能的例子程序的同时大概的知道 DBus 的运行机制。 在网上找到这么一篇文章： http://www.matthew.ath.cx/misc/dbus ， 正合我意，下面的内容基本是对这篇文章的翻译和扩充。 注意： 翻译没有得到原文作者同意，原文也很简单易懂，最好去读原文。如果收到投诉，我会立即撤掉本文的。 本文不是一篇好的 DBus 入门，有很多基本的东西不在记述之内。 一般情况下不会直接使用 C API 进行 DBus 的编程，而是使用某种 DBus-binding，但我觉得理解 DBus 的 C API 对完整地理解 DBus 是非常重要的。 虽然 DBus 是用 C 写的，而且本文写的是 C API，但是 DBus 设计中充满的面向对象的思想，请注意。 一

　　我们继续学习D-Bus，参考 http://dbus.freedesktop.org/doc/dbus/libdbus-tutorial.html ，相关的API接口reference参考 http://dbus.freedesktop.org/doc/dbus/api/html/modules.html 。从底层，即libdbus学习如何发送Method以及如何等待应答，在 上上次学习中，给出了同步的方式 ，这是更为高层的处理方式，建议使用。监听method和监听signal的方式非常相似。在给出例子之前，我希望和上次学习一样给出一个示意图，更好地了解D-Bus的各个概念。 监听Method call消息，并返回Method reply消息 　　Method的监听和signal的监听的处理时一样，但是信号是不需要答复，而Method需要。在下面的例子中，我们将学习如何在消息中加入多个参数（在D-Bus学习（四）中，我们加入了一个参数）的情况。 #include <stdio.h> #include <stdlib.h> #include <string.h> #include <dbus/dbus-glib.h> #include <dbus/dbus.h> #include <unistd.h> /*读取消息的参数，并且返回两个参数，一个是bool值stat

I have a C++ program that uses boost log, and I load a user-provided dynamic link library. I'd like to redirect stderr to the boost log, so that anytime the user's library does: std::cerr << "Some stuff"; It produces the same result** as: BOOST_LOG_SEV(log,info) << "Some stuff"; Is this possible, and if so then how do I do it? (Also, I'm not sure what to do about the severity... since cerr << doesn't privide severity information. I'm open to suggestions on that as well...) ** By "same result" I mean that it gets logged to the same log file as the rest of the log messages, and the same log

写在前面：本人水平有限，很多地方都是自己的理解，如有误导，欢迎指正 # 终端模拟器指的是在linux桌面环境下运行的仿真终端（如下图） # 终端模拟器为啥叫模拟器呢? 因为真正的终端是全屏显示的黑乎乎的不带窗口的那种，这里带了窗口，是基于linux的X窗口系统上模拟出来的终端设备，在终端上同样可以运行shell，和真的终端功能基本无差别 # 伪终端是啥？伪终端是linux内核模拟出来的假的终端设备对（通过系统调用可以动态创建这种假的终端设备），所谓假的是指这种设备不和真正的硬件设备相关联，只是操作接口和数据解析协议是按照终端设备规范来的 # 通过系统调用创建的伪终端设备对分为主从两个设备，主设备名为/dev/ptmx ，从设备名为/dev/pts0、/dev/pts1.../dev/ptsN等，内核允许动态创建无限制个设备对（所以可以同时打开许许多多个shell窗口） # 从主设备之间的读写就像管道，外部进程（模拟器进程）写主设备的时候，数据可以从从设备中读取出来（shell从stdin读取命令）；进程输出的数据会写入从设备（shell写stdout、stderr），从设备的数据又会写入到主设备，模拟器进程可以通过读主设备来得到进程的输出（读取进程的stdout，stderr） # 通常一个进程默认打开的stdin stdout stderr文件就是对应打开的伪终端从设备（pts）

I wan to create a pipe between 3 commands: cat = subprocess.Popen("cat /etc/passwd", stdout=subprocess.PIPE) grep = subprocess.Popen("grep '<usernamr>'", stdin=cat.stdout, stdout=subprocess.PIPE) cut = subprocess.Popen("cut -f 3 -d ':'", stdin=grep.stdout, stdout=subprocess.PIPE) for line in cut.stdout: # process each line here But python documentation says: Use communicate() rather than .stdin.write , .stdout.read or .stderr.read to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process. then how should I use cut.stdout ? Can someone explain