PMunch
commented
1 year ago Good catch! Another way around this (if a long timeout isn't a good enough solution) would be to simply chain a little echo "" before the output of your program. The empty line will simply be ignored, but should be enough for xlunch to realise that the input should be stdin. I tested this on my setup (which generates a recent.dsv file to keep the most recently used entry on the top of the list) with this command:
cat <(echo "" && sleep 1 && cat .config/xlunch/recent.dsv) | xlunchWithout the echo I get the error you mention, with it I get an empty xlunch window, then after a second my entries pop in. Xlunch will continuously read from stdin in this mode, so you could stream your entries in as fast or slow as you like, and a blank newline will delete all entries. Combine this with the --dontquit and --outputonly switch and you can even read the output and update the menu options in the same instance of xlunch.
That said, I still like this feature.
GlowingScrewdriver
This change allows the user to specify how long xlunch will wait for data on stdin before deciding that it is invalid. This might be useful when a program is generating output by processing data on-the-fly, and does not begin writing the data stream within 10 milliseconds (which is the timeout xlunch uses prior to this change. It will also benefit older systems, especially those with hard drives. The default value used is 10 milliseconds, which is what xlunch has been using.
This helps on my system (which is a 2nd-gen Core i3 with a HDD). As an app menu, I have a program that reads the desktop entries for all apps on the system on-the-fly and generates output which is piped to xlunch. However, on occasion xlunch complains saying
Error getting entries from stdin., even though I can confirm the output of my program to be sound. This turns out to be the issue.