我经常编写脚本,这也可以通过图形用户界面来完成。做一次,很容易使用 gui。要经常这样做,使用脚本要快得多。
(几乎)所有 gui 应用程序都使用底层 cli 应用程序。例如,切换桌面分辨率很可能会发出 xrandr 调用。
或者一个 gui 点击只是改变了一些底层配置文件,这同样有趣。
阅读 cli 文档并找出相同的结果需要时间。可以改进吗?
我的意思是,我可以记录 Linux 上任何 GUI 点击的底层 CLI 调用吗?
我经常编写脚本,这也可以通过图形用户界面来完成。做一次,很容易使用 gui。要经常这样做,使用脚本要快得多。
(几乎)所有 gui 应用程序都使用底层 cli 应用程序。例如,切换桌面分辨率很可能会发出 xrandr 调用。
或者一个 gui 点击只是改变了一些底层配置文件,这同样有趣。
阅读 cli 文档并找出相同的结果需要时间。可以改进吗?
我的意思是,我可以记录 Linux 上任何 GUI 点击的底层 CLI 调用吗?
(几乎)所有 gui 应用程序都使用底层 cli 应用程序。
这是不真实的。大多数应用程序在自己的代码或其他库中使用对函数的调用。在 Nautilus 中删除文件不会运行rm(1)
,它会调用unlink(2)
(参见 参考资料man 2 unlink
)。使用 xrandr 函数的程序应该使用Xrandr(3)
而不是xrandr(1)
. 产生另一个进程来处理这些任务是缓慢、浪费和丑陋的。
尽管如此,您仍然可以使用auditd捕获相关详细信息。
一个非常有价值的工具是 strace。这使您可以在给它适当的标志时查看哪些文件正在更改以及正在写入的内容。
见: http: //www.hokstad.com/5-simple-ways-to-troubleshoot-using-strace.html
如果 GUI 只是按照其他答案的建议调用程序,您会看到它。如果您正在寻找 dbus 和应用程序之间的网络交互,您也会看到这一点。还将看到对套接字文件的访问。
最好使用 netstat -nlp 来找出各个守护进程正在使用的端口,以便您可以轻松地跟踪交互。
如果您感兴趣的是网络流量,那么 tcpdump 当然是答案。
你是从一个不完全正确的层面来看待这个问题。您所谓的“CLI 应用程序”实际上是任何使用标准 i/o 流而没有 GUI 的软件。CLI 应用程序,作为基于 GUI 的应用程序或 Web 服务器是具有一些执行库和内核调用的逻辑的前端。您可能有一个使用 xrandr 更改分辨率的应用程序。相反,您可能有一个应用程序通过使用一些围绕 X 协议的库来执行此操作,或者使用 X 协议执行此操作的应用程序,甚至是一个使用内核调用来更改分辨率的应用程序(这里我主要指的是较旧的内核) !
正如以前的海报所回答的那样,您可能能够以某种方式拦截到 CLI 应用程序的消息,但我怀疑这就是您所指的。除了使用库拦截您想要测试的软件底层库的工作之外,您无法跟踪每个操作 - 然后您将获得库调用列表,而不是带有参数的 CLI 应用程序。
我不确定这是否是您所要求的,但有时我会使用此技巧来了解幕后发生的事情。首先,我开始捕获ps afxu
循环中的输出:
counter=0 ; while (true) ; do ps afxu > ps-afxu-capture-step-$counter ; echo "Capturing step $counter..." ; sleep 0.01 ; counter=$((counter + 1)); done
然后我diff
捕获了“帧”,看看发生了什么变化:
for i in `seq 1 100` ; do diff ps-afxu-capture-step-$i ps-afxu-capture-step-$((i+1)) ; done > ps-afxu-capture-diff.txt
我昨天才使用这个技巧来试图了解mk4ht
正在做的事情。
呃,最好在/tmp
.
这是我曾经用来深入了解传递给 CLI 命令的参数的一个廉价技巧:
在特定位置(如)创建一个可执行~/bin
脚本,打印出命令行参数:
#!/bin/sh
echo $@
exit 0
将其命名为与您要模仿的 CLI 可执行文件相同。现在因为可能有两个同名的可执行文件,bash 将按照 PATH 环境变量中指定的顺序执行它找到的第一个可执行文件。
也就是说,暂时更改您的 PATH 以包含~/bin
在任何其他路径之前:
export PATH="$HOME/bin:$PATH"
现在使用更改的 PATH在终端中运行 GUI 应用程序,将调用您的脚本而不是原始 CLI 可执行文件。您的脚本将打印出任何传递的参数。