Strange case of not seeing list of entries when combined with j4-dmenu-desktop

[roomcays]

So this issue involves j4-dmenu-desktop, very fast .desktop files finder written in C++.

Some background store first.
I used to use it in combination with rofi's dmenu mode instead of simply using rofi -show drun, because I have used j4-dmenu-desktop before with original dmenu.
Then I wanted to have j4-dmenu-desktop appear as a custom modi in rofi, i.e. not standalone dmenu mode, eventually combining it with other modis in combi-mode.

But j4-dmenu-desktop was unable to produce list of entries to STDOUT, so I have created an issue in it's github's bug tracker. It's author, enkore kindly provided me a solution how to make j4-dmenu-desktop print results to STDOUT using some (magical) shell extensions involving readlink and output/input redirection, as you can see in this comment.

Now the issue I'm reporting might, but might not, be related with rofi. Solution enkore provided works fine when using it in in terminal/console, i.e. it prints what is expected to STDOUT, nicely one entry per line. But rofi does not see this as a proper input for modi...

I thought it might be interesting. I am ready to provide any more details if required. I love both programs, use them daily and appreciate solid work of their authors.

[DaveDavenport]

yeah, that won't work.
j4desktop.sh is the script posted in link:
Some simple tests:

 rofi -show j4 -modi "j4:./j4desktop.sh"
/bin/bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
/bin/bash: /proc/15050/fd/pipe:[10094307]: No such file or directory
./gmpc.desktop: malformed file, ignoring

./j4desktop.sh | tee
/bin/bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
/bin/bash: /proc/15006/fd/pipe:[10098997]: No such file or directory
./gmpc.desktop: malformed file, ignoring

This suggest this trick does not realy like the output to be redirected, something rofi needs to do for reading.

also rofi expect it to return a list and wheen you select an item, it calls the script again with the selected item as argument.

what is wrong with drun?

[enkore]

Here's a version that should have no issues with bent output FDs:

#!/bin/sh -e
PIPE=$(mktemp -u)
mkfifo -m 600 $PIPE
trap "rm $PIPE" EXIT
cat $PIPE &
j4-dmenu-desktop --dmenu="(cat > $PIPE) | (cat << EOF)" &> /dev/null

[DaveDavenport]

that is even more broken for me. Again even it it output correctly and rofi could read it, it won't do what you expect it to do.

Repeat of my question, What is wrong with drun mode?

[DaveDavenport]

To be clear, if I need to fix the script mode, I am perfectly happy to do this. I am all for improving rofi. But I seem to be missing the point.

This is currently how script mode works:

rofi: Call script with no arguments read return values (newline separatored) until the program returns. (uses g_spawn_async_With pipes).

rofi: present user with option. If user selects entry:
rofi: Call script with selected entry as first argument.
repeat until script returns no data.

[DaveDavenport]

Example: https://github.com/DaveDavenport/rofi/blob/master/Examples/rofi-file-browser.sh

[enkore]

(I'm not a rofi user, so I don't quite grasp it's concepts or the "why would someone want to do this" questions)

The following script seems to work as a rofi 'modi' (tested with rofi -modi "j4dd:./j4-d-d-rofi.sh" -show j4dd). It needs at (and a running atd). An alternative can be i3-msg and it's exec capability ; both get you a process that is a child process of a different long-running process, avoiding the various issues of using background processes and similar constructs in a setting like this. I don't have i3 on this machine, but at, so that's what I used here.

#!/bin/sh -e
if [ $# -gt 0 ]
then
    at now <<EOF
        DISPLAY=$DISPLAY j4-dmenu-desktop --dmenu="(cat &> /dev/null) | (echo '$@')"
EOF
    #exit 0  # a question of wanted behaviour?
fi

PIPE=$(mktemp -u)
mkfifo -m 600 $PIPE
trap "rm $PIPE" EXIT
cat $PIPE &
j4-dmenu-desktop --dmenu="(cat > $PIPE) | (cat << EOF)" &> /dev/null

[DaveDavenport]

thanks for the help.

[roomcays]

Hey there again!
@DaveDavenport : I have not meant to point "wrongness" of drun, but I thought that this case is about some bug, and fixing it will improve rofi (so then other scripts/programs, not available in rofi's internal modi will fully cooperate).

[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.