Confirmation dialog in dom0 from bash

Does anyone know how I can make a confirmation dialog pop up from bash (with the result then used in the bash script)?

I tried zenity and xdialog and gdialog but none of them are present in dom0 and I don’t want to install any additional software in dom0 just for this…somehow dialogs do work since they will pop up for qrexec stuff…but in my use case I don’t need to have a VM request this, I’m just triggering a script with a key combination in dom0 and I want the dialog to have a custom title and text.

Why don’t you want to install zenity in dom0? It would be perfect.

You can trust programs installed from the official repositories, especially a slow moving and old program like zenity or xdialog.

S/he shouldn’t have to install zenity; clearly there’s some other, already-installed way to produce a dialog. So a reasonable question to ask is: “what is it?”

1 Like

the notification software in dom0 is notify-send.
see man notify-send or the internet to do what you want.

2 Likes

You can use whiptail --yesno --title "Dialog" "Hello World!" 25 80 but you would need to open a terminal window when you run the script.

2 Likes

Thank you for your answers!

Unfortunately, notify-send does not yet support the “-A” option in its version in Fedora 32 (dom0 of Qubes 4.1). In Fedora 38 it does, and I hope in Fedora 37 (dom0 of Qubes 4.2) as well, so I could implement this with notify-send if that is the case but I’m not yet ready to upgrade.

Whiptail is also interesting, but doesn’t work in my use case.

If anyone has any other ideas or knows how qrexec does it, let me know…if there are no more answers and if I find, once I upgrade to Q4.2, that actions in notify-send work there, I will mark that as the correct answer.

Works for me from dom0

echo "hello world" | qvm-run --pass-io YOUR_VM 'cat > /tmp/msg.txt ; notify-send "$(cat /tmp/msg.txt)" ; rm /tmp/msg.txt'
1 Like

I should have been more precise: I’m looking to use a confirmation dialog in the sense that I want to not only display some info, but also give (as the human looking at the info) a response (yes/no) and then use that response in the further workings of the script.

With notify-send this could work, but only if actions (option -A) are available, which is not the case with the version in Fedora 32.

This works because notify-send is used from an AppVM

[solene@dom0 ~]$ echo hello | qvm-run --pass-io YOUR_VM 'cat > /tmp/msg.txt ; notify-send -A "FOOBAR=yes" --wait "$(cat /tmp/msg.txt)"'
FOOBAR
2 Likes

Ashes on my head, I didn’t realize what you did there!

Very good idea and it works! I’ll have to think about the security implications of passing io back to dom0, but it’s a possible workaround until I upgrade, thank you!

Should anyone have another solution that can be executed only in dom0 of Q4.1 without making use of another VM, feel free to post!

As you said, in fedora 32 you cannot use notify-send because the lack of the action option.
Instead you can directly use the dbus Notification.

Some documentations:

Here, a working example:

[user@dom0 ~]$ cat x.sh 
#!/usr/bin/bash

gdbus call --session \
    --dest=org.freedesktop.Notifications \
    --object-path=/org/freedesktop/Notifications \
    --method=org.freedesktop.Notifications.Notify \
    "" 0 "" 'Hello world' 'This is an example!' \
    "['foo', 'yes', 'bar', 'no']" "{'urgency': <2>}" 0 > /dev/null

kill_monitor ()
{
    pkill -f 'dbus-monitor'
}

result=$(dbus-monitor "type='signal',
    sender='org.freedesktop.Notifications',
    interface='org.freedesktop.Notifications'" \
    | while read -r line
    do
        case "$line" in
            *foo*)
                echo foo
                kill_monitor
                break;;
            *bar*)
                echo bar
                kill_monitor
                break;;
            *NotificationClosed*)
                echo closed
                kill_monitor
                break;;
        esac
    done)

echo "> $result <"
[user@dom0 ~]$ ./x.sh 
> closed <
[user@dom0 ~]$ ./x.sh 
> foo <
[user@dom0 ~]$ ./x.sh 
> bar <

On fedora 37 dom0, the hint "{'urgency': <2>}" was not necessary as the notification doesn’t disappear.
But in a standalone fedora 32, the notification disappear after some seconds (without signal emitted).
The notification also disappear if you mouse hover the notif and mouse out of the notification (still without signal emitted).

I guess the expire_timeout of 0 is not honored by the server.
Setting the urgency to critical solved this problem, the notification will not disappear until you click on an action (ActionInvoked signal) or on the notification itself (NotificationClosed signal).

Its working fine on the standalone fedora 32 and on dom0 fedora 37.
Notice than my standalone fedora 32 is not updated, it could work better on dom0 f32.

3 Likes

Very cool and it works on Qubes 4.1!

As that fulfills all requirements, I’ll mark it as the solution.

1 Like