141、【OS】【Nuttx】【周边】效果呈现方案解析：strace 日志解析（七）

【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除

背景

之前 blog
【OS】【Nuttx】【周边】效果呈现方案解析：strace 日志解析（一）
【OS】【Nuttx】【周边】效果呈现方案解析：strace 日志解析（二）
【OS】【Nuttx】【周边】效果呈现方案解析：strace 日志解析（三）
【OS】【Nuttx】【周边】效果呈现方案解析：strace 日志解析（四）
【OS】【Nuttx】【周边】效果呈现方案解析：strace 日志解析（五）
【OS】【Nuttx】【周边】效果呈现方案解析：strace 日志解析（六）
分析了下 strace 的追踪日志以及里面 open 命令和 openat 命令的区别，还有里面涉及的相关宏定义，以及 D-Bus 与 GNOME 的概念，并分析了 dbus-send 命令与 D-Bus 的关系，分析了日志中不是 GNOME 和 XFCE 的描述，xprop 命令的用法，还分析了根窗口和 _DT_SAVE_MODE 的概念，下面继续来看下

strace 日志解析

回到这张图

前面 blog 分析了 22 行和 24 行日志中命令执行的含义，然后中间 23 ~ 58 行加载了一系列依赖库，紧接着 59，61 行命令执行返回了 1（失败），相当于 xprop 命令既没有从根窗口中找到 _DT_SAVE_MODE 属性，既然没找到该属性，就更不可能从这个属性的值中匹配到 xfce4 内容了，所以这里两处都返回了失败

下面继续看后面的日志

可以看到 65 行这里又是执行了 xprop -root 命令去查看根窗口信息，注意，这里并没有指定是根窗口的哪个属性，直接用 xprop -root 命令，不接具体属性名的话，将输出所有根窗口属性

因为 _DT_SAVE_MODE 属性不是标准属性，可能是历史或私有实现，随着版本的演进，这个属性可能过时，早期 XFCE 有这种行为，但现代版本不依赖此机制，所以单靠 _DT_SAVE_MODE 属性不足以判断出这事 XFCE，可能会漏掉现在较新的版本，所以 65 行这里又尝试另一种方式来检查是否有 XFCE 相关的根窗口属性

65 行输出所有根窗口属性后，66 行紧接着 grep -i 命令来筛选是否有 XFCE 相关的属性，终端输入

man grep

可以看到 -i 选项表示忽略大小写

相当于在所有根窗口属性中寻找 xfce_desktop_window 的属性，如果找到，说明当前桌面环境很可能是 XFCE，因为 XFCE 桌面环境会在 X Window 根窗口上设置一些特有的原子属性，比如 XFCE_DESKTOP_WINDOW，XFCE_PANEL_WINDOW，_DT_SAVE_MODE（前面提到的），这些属性相当于是 XFCE 特有的指纹，其他桌面环境（比如 GNOME）不会设置，通过检查这些属性是否存在，可以判断当前是不是在 XFCE 下运行

ok，可以看到 97 行和 99 行，这两个步骤都执行失败了（注意对比 PID），这里 xprop -root 命令都执行失败，说明根窗口属性都打印不出来，grep 命令就更不必说，肯定找不到对应属性名

如果直接在终端输入

xprop -root

可以看到也是报错退出，因为 xprop 命令无法打开显示设备，无法连接到 X Window 图形服务器

一般来说，如果在纯终端或 SSH 会话中，且未启用 X11 转发时，会出现这种现象，此时环境变量 DISPLAY 为空或未设置，并且 xprop 等 X Window 工具无法正常工作

接着在终端输入

echo $DISPLAY

可以看到输出为空，说明 X Window 图形服务器确实没运行起来

接着在终端输入

echo $XDG_SESSION_TYPE

可以看到当前处于一个 纯文本终端（TTY）环境，没有任何图形界面（因为是通过 VSCode SSH 远程连接）

在这种环境下，没有 X Window 图形服务器，也没有桌面环境（比如 GNOME，XFCE 等），也没有窗口管理器，只有基本的 Shell 和命令行工具，xprop 命令失效，所以会返回失败

ok，先分析到这里，下篇 blog 继续