Shell脚本弹出GUI通知：notify-send完整实践与踩坑指南

故小里·2026-09-01·阅读 25 GEO检测（免费）

notify-sendShell脚本GUI通知

|难度：普通|阅读约 44 分钟

让Linux脚本学会"开口说话"：从Shell脚本弹出GUI通知的完整实践

作为一个常年跟Linux服务器和桌面环境打交道的人，我有个特别深刻的体会：脚本最让人头疼的不是写不出来，而是跑完没动静。2019年的时候，我写了一个每天凌晨三点执行的全量备份脚本，rsync带压缩、带校验，跑完自动把日志写到文件里。前两个月一切正常，直到某天早上我发现备份目录的大小明显不对——一查日志才知道，脚本第三天就已经开始报错了，错误信息静静躺在日志文件第47行，而我一直没去看。

这件事之后我给自己定了个规矩：凡是需要后台执行、定时执行或者可能跑很久的脚本，必须在关键节点给桌面上弹一条GUI通知。今天这篇就以"Showing a GUI Notification From a Shell Script in Linux"这个主题为主线，把我在Linux下从Shell脚本里弹GUI通知的完整经验整理出来——包括工具选型、核心参数、可以直接抄的脚本案例，以及排查那些"明明写了notify-send却不弹通知"的坑。相信能帮同样被"无声脚本"坑过的朋友少走一段弯路。

1. 为什么脚本需要GUI通知：从一次备份事故说起

1.1 脚本的"无声失败"比失败本身更可怕

先说说那次的教训。我的备份脚本结构并不复杂：先检查磁盘空间，够则执行rsync，再把日志写到 /var/log/backup.log。脚本逻辑上是没错的，问题在于它"太安静"了——整个执行周期大约40分钟，期间没有任何输出，成功后也只是在日志里追加一行记录。

第三天磁盘空间告警，rsync直接以退出码11（非零状态）中断，脚本继续往下执行，因为我没有在rsync后检查 $?。结果就是：备份目录里躺着半套不完整的文件，日志里有一行错误提示，而这一切没有任何人到现场看一眼。

如果你也写过类似的长任务脚本，一定明白这种"无人值守却无人通知"的尴尬。传统解决办法是配邮件告警或系统日志，但对于个人工作站或办公桌面，在屏幕上直接弹一条GUI通知，是最直观、门槛最低的反馈方式。它不需要你打开终端、不需要记得去查日志，桌面右上角淡入一条消息，看见了，问题就解决了。

1.2 哪些脚本场景最适合加GUI通知

根据我自己的使用情况，这些场景几乎是无脑适合加通知的：

耗时任务的完成提醒：打包、上传、编译、同步数据，跑完弹一条"成功"或"失败"，完全解放眼睛。
定时脚本的状态广播：备份、清理临时文件、更新软件仓库索引，这类脚本在后台按计划执行，用户并不会一直盯终端。
监控类脚本的告警：CPU温度过高、磁盘使用率超限、外接设备断开，这些信息如果不主动推送到桌面，基本等于白监控。
交互式脚本的上下文切换：你在浏览器里查资料，终端里一个编译任务跑完了，弹个通知让你切回去，比反复看终端窗口高效得多。

1.3 一个反直觉的事实：桌面Linux上这个能力"免费"

做Web开发的朋友可能觉得"GUI通知"是个复杂事情：得有个服务端推送通道，得有前端API，还得处理权限。但Linux桌面环境不是这样——大多数Linux桌面发行版（GNOME、KDE、Xfce等）默认就实现了freedesktop.org的Desktop Notifications Specification，也就是通过D-Bus提供一套标准化的通知接口。任何程序都可以往这个接口上发消息，桌面环境负责把它渲染成你在屏幕右上角看到的那种气泡。

这就意味着，你不需要自己写GUI程序，不需要装QT或GTK的开发库，只要Shell环境里有一条能调用D-Bus通知接口的命令就够用了。而这条命令，正是大多数发行版默认已经装好的 notify-send。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 选型对比：notify-send、zenity、kdialog，谁才是最佳选择

2.1 notify-send：轻量、标准、默认就有

notify-send 是 libnotify 工具集里提供的一个命令行小工具，作用就是把通知请求转发给桌面环境的通知守护进程（notification daemon）。为什么说它是首选？理由有三个：

一是轻量。它本体只是一个很小的二进制，依赖极少，不会像某些GUI库那样把几百MB的依赖拖进你的系统。

二是符合标准。它直接对接freedesktop规范，无论你用的是GNOME（通过gnome-shell的通知中心）、KDE Plasma（通过plasma-workspace）还是Xfce（通过xfce4-notifyd），只要你的桌面环境实现了规范，notify-send就能正常工作。

三是默认可用性极高。绝大多数主流发行版在图形桌面上已经预装了libnotify-bin（Debian/Ubuntu）或libnotify（Fedora/openSUSE），即便没装，一条命令也就装好了：

bash复制# Debian/Ubuntu
sudo apt install libnotify-bin

# Fedora
sudo dnf install libnotify

# Arch Linux
sudo pacman -S libnotify

安装完直接在终端里敲：

bash复制notify-send "Hello" "World"

如果桌面上弹出了"Hello World"气泡，那就说明整个链路已经通了。

2.2 zenity：通知只是它最不起眼的功能

zenity是GNOME项目提供的GTK对话框工具，它远远不止弹通知这么简单：文件选择框、日历选择、进度条、表单输入、警告对话框，都是它的强项。用它来发通知，形式上是这样的：

bash复制zenity --notification --text="备份完成"

相比于notify-send，zenity的一个优势是——如果你需要在通知之外再叠加一个"用户必须点确定才能继续"的交互弹窗，它可以直接接管，不用写两套东西。但反过来，zenity的体积明显更大，依赖GTK库，对纯通知场景多少有点"杀鸡用牛刀"。

2.3 kdialog：KDE生态下更顺手的选项

kdialog是KDE阵营的对应工具，用法和zenity类似，但它默认依赖KDE运行库。如果你的机器跑的是KDE Plasma桌面，用kdialog发通知、弹确认框都很自然。但如果你用的是GNOME或Xfce，特意为了发个通知去装一套KDE库，就不太明智了。

2.4 三者的选型建议

工具	适用场景	依赖体积	通知能力	交互能力
notify-send	纯通知、脚本内轻量调用	极小	强（支持图标、动作、持久化）	弱（只能点通知触发动作）
zenity	需要弹窗交互的复杂脚本	较大（GTK）	中（notification模式简单）	强（表单、文件选择、消息框）
kdialog	KDE Plasma桌面环境	中（KDE库）	中	强

一个比较实际的选型逻辑是：如果你的脚本只是要在完成或异常时让用户"看一眼"，无脑选notify-send；如果你的脚本还需要用户做选择、填参数、选文件那种程度的交互，再考虑引入zenity或kdialog。两者不是互斥的，完全可以混用——通知部分用notify-send，交互部分用zenity。

3. notify-send核心参数拆解：命令虽短，几十个参数各有脾气

3.1 基础调用：标题、正文与超时时间

notify-send的基础用法非常直白：

bash复制notify-send "标题" "正文内容"

第一个参数是标题，第二个参数是正文。如果只传一个参数，它会被当作标题显示，正文为空。

控制通知显示时长，靠的是 -t 参数，单位是毫秒：

bash复制# 显示3秒后自动消失
notify-send -t 3000 "提示" "这条通知只显示3秒"

这里有个细节很容易被忽略：** -t 参数的实际生效情况取决于桌面环境的通知守护进程实现**。GNOME的某些版本会忽略超时时间，强制按它自己的策略显示；而KDE的守护进程则基本尊重你的设置。所以别把超时当成精确控制的手段，它更多是一个"期望值"。

3.2 紧急程度：用 -u 让通知"分贝不同"

通知不都是同一个"音量"的。notify-send通过 -u 参数设置紧急程度（urgency），取值有三个：

low：低优先级，通常用于纯信息型消息，不包含音效提醒。
normal：普通优先级，默认值，适合大多数场景。
critical：高优先级，一般会持续显示直到用户操作，而且通常带警示音。

我自己的习惯是：任务正常完成用normal，任务出问题用critical。比如备份成功弹normal，备份失败弹critical，一眼扫过去就知道脚本状态，根本不用读文字。

bash复制notify-send -u critical "备份失败" "rsync退出码为11，请检查磁盘空间"

不过注意，critical通知可能会被桌面环境置顶或强制弹窗，如果脚本频繁误报，用户体验会非常糟糕。所以只在真正需要用户立即干预的情况下才用critical。

3.3 按钮能力：让通知不只是"看一眼"

如果想要通知上带一个图标，用 -i 参数指定图标名或图片路径。你可以传主题里的标准图标名，也可以传一个图片文件的绝对路径：

bash复制# 使用系统图标名
notify-send -i dialog-warning "磁盘空间不足" "根分区剩余空间不足10%"

# 使用自定义图片
notify-send -i /home/user/icons/backup-done.png "备份完成" "已同步到远程服务器"

要拿到当前桌面环境支持的图标名列表，可以这样查：

bash复制ls /usr/share/icons/Papirus/48x48/status/   # 举例：Papirus图标主题的状态图标目录

不同图标主题的图标名会有差异，但有一批freedesktop标准图标名在各主题下基本都有，比如 dialog-warning、dialog-error、dialog-information、face-smile、system-software-update 等。这些写进脚本里兼容性最好。

3.4 动作（Action）：通知上直接安排操作按钮

这是notify-send容易被忽略但极其强大的能力——给通知添加动作按钮，用户点击按钮时，触发一条D-Bus信号。配合后台脚本监听这条信号，就能实现直接通过通知对事件做出响应。

添加动作的格式是：

bash复制notify-send -A default="打开" -A ignore="忽略" "备份完成" "是否查看日志？"

-A 参数可以重复使用。用户点击"打开"按钮时，通知守护进程会发出一条ActionInvoked信号，其中会带上参数里指定的动作ID（这里就是default或ignore）。你可以在脚本里用一个D-Bus监听进程来响应这条信号，不过这需要一点DBus开发知识，属于进阶玩法，第6章我会展开讲。

3.5 持久化位置与替换旧通知：控制"通知栈"的秩序

如果你的脚本可能连续弹多条通知（比如一个循环里每处理一个文件弹一条），不想让屏幕上堆满气泡，可以用 -r 参数指定一个"替换ID"。用同一个ID发出的新通知会替换掉同ID的旧通知：

bash复制# 循环里连续更新同一条通知
for f in *.log; do
    notify-send -r 777 -t 2000 "处理中" "正在处理：$f"
    process "$f"
done
notify-send -r 777 "完成" "全部日志处理完毕"

同理， -c 参数可以用来指定通知类型（category），比如"transfer"、"device"、"memory"之类。部分桌面环境会按类别对通知分组显示，也方便你自己后续做过滤。类型名没有强制的规范，但参考freedesktop规范推荐的那一串（device、email、im、presence、transfer等）能让兼容性更好。

4. 实战代码：三个拿来就能用的通知脚本案例

4.1 长任务完成提醒（rsync备份场景）

这个脚本解决的就是我在开头说的那个问题——备份跑完必须给用户一个明确的状态反馈。核心逻辑是在rsync执行前后检查退出码，用不同紧急程度发送通知：

bash复制#!/bin/bash

# backup_with_notify.sh
# 用法：./backup_with_notify.sh /源目录 /目标目录

SRC="$1"
DEST="$2"
LOG_FILE="/var/log/backup.log"

# rsync的退出码含义：0成功，1语法错误，11资源不可用（如磁盘满）
rsync -avz --delete "$SRC" "$DEST" >> "$LOG_FILE" 2>&1
EXIT_CODE=$?

if [ $EXIT_CODE -eq 0 ]; then
    notify-send -i emblem-default -u normal -t 5000 "备份完成" "已同步：$SRC -> $DEST"
else
    notify-send -i dialog-error -u critical "备份失败" "rsync退出码：$EXIT_CODE，详情见 $LOG_FILE"
fi

一个小建议：不要偷懒用 2>/dev/null 把标准错误丢掉。rsync的提示信息往往是排查问题的第一手线索，把它写进日志，配合通知里的"详情见日志"指引，能让收到通知的人直接去定位问题，而不是抓瞎。

4.2 桌面休息提醒（Tomato Timer变体）

我写过一个简易的番茄钟脚本：每25分钟弹一次通知提醒休息，休息5分钟后再弹一次提醒继续工作。它不需要任何额外依赖，一个无限循环加sleep就完事了：

bash复制#!/bin/bash

# pomodoro_notify.sh
WORK_MINUTES=25
REST_MINUTES=5

while true; do
    notify-send -i face-smile -u normal -t 8000 "专注时间" "开始工作 $WORK_MINUTES 分钟"
    sleep "${WORK_MINUTES}m"
    notify-send -i face-cool -u critical -t 10000 "休息时间" "起来活动一下，眺望远处5分钟"
    sleep "${REST_MINUTES}m"
done

如果你在公司里不方便一直开着终端跑循环，可以把它注册成一个systemd用户服务来管理，下面专门有一节讲systemd和通知配合的问题。这个脚本虽然简单，但和系统自带提醒相比有个天然优势：提醒消息的文案、图标、优先级完全由你控制，想塞什么内容就塞什么内容。

4.3 系统资源告警脚本（磁盘空间/内存）

对于桌面用户来说，定期检查磁盘空间并只在有风险时弹通知，是一个既实用又低调的做法。脚本里最核心的其实是"判断阈值"，通知只是最后一步：

bash复制#!/bin/bash

# disk_check.sh
THRESHOLD=85

USAGE=$(df / | awk 'NR==2 {print $5}' | tr -d '%')

if [ "$USAGE" -gt "$THRESHOLD" ]; then
    notify-send -i dialog-warning -u critical "磁盘告警" "根分区使用率达 ${USAGE}%，请及时清理"
else
    # 可选的：正常时静默不打扰，或记录日志
    logger -t disk_check "根分区使用率 ${USAGE}%，在安全范围内"
fi

这里有个值得称道的细节：只在异常时打扰用户，正常时保持安静。脚本监控类工具最忌讳的就是"每条正常状态也弹通知"，用不了三天用户就会把通知权限关掉。所以我在正常分支里只是用logger写了个系统日志，供事后回溯，而不打扰正在工作的人。

4.4 与systemd timer结合：定时脚本的完美搭档

systemd timer是cron的现代替代方案，它对用户服务的支持做得非常好。把上面那个磁盘检查脚本做成一个systemd用户服务，可以让它在后台定时运行，而且天然解决了后面要讲的"环境变量"问题——前提是你用正确的方式启动它。

先创建服务文件 ~/.config/systemd/user/disk-check.service：

code复制[Unit]
Description=Check disk usage and notify desktop

[Service]
Type=oneshot
ExecStart=/home/user/bin/disk_check.sh

再创建同名timer文件 ~/.config/systemd/user/disk-check.timer：

code复制[Unit]
Description=Runs disk check every hour

[Timer]
OnCalendar=*-*-* *:00:00
Persistent=true

[Install]
WantedBy=timers.target

然后启用它：

bash复制systemctl --user daemon-reload
systemctl --user enable --now disk-check.timer

这套方案的优势是：脚本不需要自己维护循环，定时触发完全交给systemd；同时因为使用了 --user 级别的systemd实例，服务在用户登录图形会话期间运行，通知能正常显示。

这里有一个非常关键的机制值得注意：D-Bus会话总线和systemd --user之间天然能联动，因为用户实例本身就运行在同一个dbus会话中。这也是为什么用systemd --user定时调notify-send时不需要额外处理DISPLAY变量就能弹通知，而用传统cron调就经常出问题。这点在第5章会细讲。

5. 踩坑排查全过程：脚本不弹通知，到底哪里断了链

5.1 症状一：手动运行正常，cron里不弹——问题出在环境变量

这是所有人遇到的第一个坑。脚本在终端里手动跑，通知"啪"一下就出来了；放进crontab里，到点执行了，日志也写了，就是没有弹窗。你甚至会在系统日志里看到脚本执行成功的记录，但GUI上什么都没有。

根因是cron运行时的最小化环境里没有DISPLAY和DBUS_SESSION_BUS_ADDRESS这两个环境变量。notify-send本质上是通过D-Bus把消息发给通知守护进程，而D-Bus需要知道会话总线在哪里，这靠DBUS_SESSION_BUS_ADDRESS环境变量来指定。cron默认不携带这些变量，notify-send找不到总线，直接报错退出（如果你把stderr重定向到某个文件，能看到类似"Error calling StartServiceByName for org.freedesktop.Notifications"的报错）。

解决办法有两种。一种是过时但常见的"硬编码环境变量"：

bash复制export DISPLAY=:0
export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$(id -u)/bus"
notify-send "你好" "来自cron的通知"

这在老系统上能用，但有一个致命前提：你猜的DISPLAY编号不对的话（比如登录了两个会话，DISPLAY是:1甚至:2），通知还是弹不出来。

另一种更靠谱的方案是用systemd --user替代cron，如4.4节所示。因为用户systemd服务运行在登录会话里，环境变量天然就是对的。这也是我强烈建议长期定时任务优先走systemd --user的原因。

5.2 症状二：SSH进入桌面机，脚本"好像"不弹——可能是你连错了会话

有时候问题不在环境变量，而在会话本身。比如你用SSH从笔记本连到一台已登录用户的Linux桌面机，然后手动执行notify-send。如果没有额外配置X11 forwarding，SSH会话里根本没有DISPLAY变量，通知自然发不到那台机器的桌面上。GNOME Wayland时代则更严格，不同会话之间不允许随意互相访问D-Bus总线。

如果你确实需要在远程连接时向本机桌面发通知，有两个思路：一是对需要转发的会话用 export DISPLAY=:0（前提是你能确定它的编号），二是更推荐的方式——先SSH到机器上执行 systemctl --user 相关的启动操作，这会把通知放到正确的用户会话里：

bash复制ssh user@desktop "systemctl --user start my-notify.service"

其中 my-notify.service 内部会调用notify-send。因为systemd --user实例运行在目标桌面机的用户会话里，它知道正确的D-Bus路径，通知就能弹出来了。

5.3 症状三：通知能弹出但图标是"问号"或空白

这看起来是个小问题，但特别让人抓狂。原因通常不是路径不对，而是你用的图标名在当前的图标主题里不存在。notify-send不会因为图标名无效就报错，它会请求一个不存在的图标，守护进程渲染时就显示成一个空白或占位符。

排查方法是先用 gtk-query-settings 或直接看当前主题的图标目录：

bash复制# 查看当前GTK图标主题名
gsettings get org.gnome.desktop.interface icon-theme

# 在该主题里搜索你打算用的图标名
ls /usr/share/icons/<主题名>/ | grep dialog-warning

如果找不到，换一个freedesktop标准图标名，比如从 dialog-warning 换成 dialog-information，同样能表达"注意"但兼容性更好。

5.4 症状四：通知一闪而过，根本没看清内容——超时时间失效

有朋友反馈：我明明设了 -t 10000（10秒），通知还是瞬间就消失了。问题不在你的设置，在于桌面环境的通知策略。GNOME默认会对normal优先级的通知显示一个较短时间段，即使你指定了超时时间；某些GNOME版本甚至直接忽略应用传来的超时值，统一按GNOME自己的规则来。

想让它停留久一点，可以把 -u 调成critical。critical通知通常不受短超时约束，会一直显示到用户操作或长时间才消失。但别滥用。

bash复制notify-send -u critical -t 0 "关键提醒" "这条通知不会自动消失，直到你点掉它"

注意 -t 0 在部分桌面环境里被解释为"永不过期"，在另一些环境里被忽略，行为并不统一。所以最稳妥的做法是：重要通知直接加 -u critical，并明确写清楚你想让用户怎么操作，不要把期望寄托在超时参数上。

5.5 建立一个可复用的排错清单

踩坑踩多了，我总结了一套排查notify-send不发通知的"三步定位法"：

先确认命令本身能跑通：在桌面的图形终端里执行 notify-send "test" "test"。
- 如果弹了，说明工具和守护进程正常，问题大概率在环境变量或运行上下文。
- 如果没弹，先检查是否安装了libnotify，再检查桌面环境的通知守护进程是否运行（比如GNOME下查gnome-shell，KDE下查plasma-workspace）。
再确认环境变量是否齐全：在目标运行环境（cron、systemd、SSH）里执行 env | grep -E 'DISPLAY|DBUS_SESSION_BUS_ADDRESS'。
- 这两个变量至少得有一个指向正确的值。缺失时参考5.1的方法补齐。
最后看stderr输出：把notify-send的stderr重定向到日志文件，里面往往直接写着失败原因。

bash复制notify-send "test" "test" 2>> /tmp/notify_err.log

这三步能解决我在99%的"不弹通知"问题。剩下1%是桌面环境通知服务崩溃之类的极端情况，重启桌面会话一般能解决。

6. 进阶玩法：让通知从"能看"变成"能用"

6.1 通知按钮 + D-Bus信号：从"提醒"到"执行"

前面3.4提到了 -A 动作参数。它的进阶用法是：用户点击通知上的按钮后，脚本可以实时收到响应并执行相应操作。这本质上是一个基于D-Bus信号的交互机制，实现起来并不难，但要借助Python或其他能监听D-Bus信号的语言。

用一个简化的例子来理解思路：通知里带"查看日志"和"忽略"两个按钮，点击"查看日志"时自动打开日志文件。

python复制#!/usr/bin/env python3
# monitor_dbus_action.py
import gi
gi.require_version('Notify', '0.7')
from gi.repository import Notify, GLib
import subprocess

Notify.init("backup-notify")
notification = Notify.Notification.new(
    "备份完成", 
    "已同步到远程服务器", 
    "dialog-information"
)

def on_action(notification, action_name, user_data=None):
    if action_name == "view_log":
        subprocess.Popen(["gedit", "/var/log/backup.log"])
    elif action_name == "ignore":
        print("用户选择忽略")

notification.add_action("view_log", "查看日志", on_action, None)
notification.add_action("ignore", "忽略", on_action, None)
notification.show()

GLib.MainLoop().run()

这个脚本的逻辑不复杂，但效果很直观：通知不再只是一条单向的消息推送，而是一个带操作入口的小交互面板。你完全可以根据自己的需求扩展动作：比如备份完成后让用户选择"打开备份目录"还是"重新备份"，或者下载完成后让用户选择"打开文件"还是"移到归档文件夹"。

6.2 把通知接入到OpenBox/i3等极简桌面

如果你用的是i3、OpenBox、bspwm这类不含完整通知守护进程的极简窗口管理器，notify-send默认不生效——因为根本没有人把通知渲染到屏幕上。解决办法是装一个独立的通知守护进程，常见的有dunst和xfce4-notifyd：

bash复制# Debian/Ubuntu 安装dunst
sudo apt install dunst

然后启动它：

bash复制dunst &

只要dunst在运行，notify-send发出来的通知就能正常显示。dunst的可配置性非常高，位置、颜色、字体、超时策略都可以通过配置文件调整，非常适合极简桌面用户。配置示例在 ~/.config/dunst/dunstrc 里，改完用 killall dunst && dunst & 重启生效。

6.3 与Wayland桌面的兼容性处理

Wayland时代的会话管理比X11严格得多，X11时代的"export DISPLAY=:0"技巧在纯Wayland会话里基本失效。但好消息是，notify-send与Wayland下的GNOME和KDE工作得很好，因为它走的是D-Bus，不依赖X Window系统。需要特别注意的反而是"脚本运行环境与图形会话是否在同一个用户会话"这件事：只要你是普通用户在桌面会话里运行脚本，即使桌面是Wayland，notify-send也能正常弹通知。

真正需要警惕的是混合X11/Wayland的环境（比如某些发行版部分应用通过XWayland运行）。这类环境下，如果脚本里尝试用xdotool之类依赖X11的工具，可能在Wayland会话里无效，但notify-send本身不受影响——它是D-Bus这条路的，和X/Wayland无关。

6.4 跨发行版/跨桌面环境的兼容设计要点

如果你的脚本打算分享给使用不同发行版和桌面环境的朋友，有几个设计原则值得遵守：

优先用freedesktop标准图标名：dialog-warning、dialog-error、dialog-information这类名字几乎每个图标主题都提供，比自定义的图标名兼容性好得多。
不要依赖通知的精确超时：不同的桌面环境对 -t 参数的处理方式不同，重要信息要靠critical优先级保证可见性。
对notify-send是否被安装做一次检测：在脚本里提前检查 command -v notify-send，没有时退化为终端日志输出，避免脚本因缺少命令而中断。
把发送通知封装成一个最小函数：这样你的主脚本逻辑里不需要到处写notify-send，只要调用一个函数即可。统一维护图标、标题和优先级策略，也方便将来统一替换为其他的通知实现（比如改用Zenity）。

bash复制function notify() {
    if command -v notify-send > /dev/null 2>&1; then
        local priority="normal"
        case "$1" in
            ok) priority="normal" ;;
            warn) priority="normal" ;;
            error) priority="critical" ;;
        esac
        notify-send -u "$priority" "脚本通知" "$2"
    else
        echo "[通知] $2" >> /tmp/script_notifications.log
    fi
}

这套封装的好处是：别人没装notify-send时，你的脚本不至于直接中断，而是退化为日志记录，这对分享给团队使用尤其重要。我自己的所有公共脚本里，通知部分都强制走这个函数，既避免了重复代码，也为换工具留下了余地。

7. 一些实测下来的个人体会

我用notify-send做桌面通知已经有几年时间，最大的感受是：这工具的价值不在于技术本身有多难，而在于它帮你把"系统状态"和"人的注意力"对接起来了。一个长任务跑完能及时告诉你结果，一个监控脚本能在问题恶化前提醒你处理，这些看起来很小的功能，长期累积下来能省下很多不必要的焦虑和排查时间。

如果你从现在开始想给脚本加上通知能力，我建议从最简单的场景入手：先给自己常用的那个压缩/同步脚本加一条完成通知，确认通知链路是通的，再慢慢扩展到定时任务和监控告警。另外建议从第一天就养成分发/共享时注意兼容性的习惯，尤其是上面提到的检测notify-send是否存在、优先用标准图标名、用critical表达异常，这些小习惯会在你脚本被更多人使用的时候省掉无数问题。

最后再分享一个小经验：通知文案好好写。别写"任务完成"这种没有信息量的废话，至少要让读者知道"什么东西完成了、结果是什么、下一步要做什么"。比如"备份完成：/home/data 已同步到NAS，耗时34分钟"，比"备份完成"有用得多。一条通知被看到的时间只有几秒钟，把关键信息塞进去，别让用户还要去翻日志，这才是GUI通知真正该有的样子。