[REQUEST] Optionally exit immediately on empty script output

[jluttine]

Before creating a feature request:

• First check the next branch, to see if the feature has already been
  implemented.
• Check existing reports, see if it is already requested.

Describe the feature

Currently, if rofi is opened in script mode, it'll always show up even if the script output is empty and there are no choices to choose from. For instance:

$ cat script
#!/bin/sh
exit 0

$ rofi -show script -modi script:./script

This will open rofi without any choices.

First, I want to emphasize that this behavior is the desired behavior in many cases and by default, as we discussed in IRC. It's good for the user to get some feedback from the UI. And seeing an empty list is information by itself (for instance, no WIFI networks found).

However, there are some usecases when this behavior feels counter-intuitive and even wrong. Simply put: if the rule is that rofi shows the output of the script as choices as long as the script outputs something, it'd feel consistent if rofi then exited even after the first script call if the output was empty. One might think what is the use for this, but let me try to explain.

Examples

Let's consider an example. You've written a simple file browser script for rofi. The script works so that you give some path to it as an argument and then a) if it's a directory, it lists the contents of the directory, but b) if it's a file, rofi opens the file with xdg-open. Now, if you open this file browser so that the starting path is already a file, it'd be nice if rofi then doesn't show up at all, and the file is just opened. So, if you wrap this kind file browser mode script as follows:

open:

#!/bin/sh
rofi -show filebrowser -modi "filebrowser:./filebrowser $@"

You'll have a really nice file opener which either opens the file or shows the directory content when called from the command line as open /path/to/some/file`` or open /path/to/some/directory`.

A bit more abstract example: You use rofi to explore some tree structure. When you reach a node, rofi either a) if the node has children, rofi lists the child nodes or b) if the node is a leaf, the script does something to with the leaf node (maybe opening something or not).

I understand this isn't a good default behavior, but it would be great to have it as an optional feature. Maybe called -auto-exit or something else.

One question is that what to do when using multiple modi in one rofi call and some other mode than the shown one is empty. Maybe rofi shouldn't exit if some not shown mode is empty? Or maybe the auto exiting works only when one mode is listed in modi? Or maybe auto-exit can happen only at the very first show in startup, so if the empty script output is the one chosen with -show. Not sure.

As a workaround, one can use dmenu mode and the following kind of stand-alone wrapper script for executing rofi:

#!/bin/sh
options=$(./myscript $@)
while [ -n "$options" ]
do
    choice=$(printf "$options" | rofi -dmenu -p "Power menu" -i)
    if [ $? -ne 0 ]
    then
        break
    fi
    options=$(./myscript $@ "$choice")
done

But then one can only use dmenu mode and passing arguments to both the script and rofi is a bit more difficult.

When reporting a feature request include the following information:

$ rofi -v
Version: 1.5.4

[DaveDavenport]

No, this is would be inconsistent behavior. You launch rofi, yet nothing happens because it instantly closed. Did script return empty? did an error occur?
On top of it, what happens suddenly depends if you have other things in your modi list (so depends on global/local config) etc.

IMHO this would be terrible UI design.

[jluttine]

In case someone happens to come on this page looking for a workaround, I wrote a simple script that can be used to run rofi scripts in dmenu mode and it can optionally be configured to exit even on initial empty list: https://github.com/jluttine/rofi-script-to-dmenu

For instance:

ROFI_SCRIPT_TO_DMENU_AUTOEXIT=1 rofi-script-to-dmenu my_cool_rofi_script.sh

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.