Only set `$launcher_exit` if not running rofi-script, and only exit using `$launcher_exit` if it has been set. Otherwise, the last line (now with quoting around the variable) becomes `exit ""`, which causes an error.
This change is related to https://github.com/cdown/clipmenu/issues/57#issuecomment-740123283.
If `clipmenu` "preserves" the exit code from the launcher (exits with the same code as the launcher), the exit code's from Rofi's custom keybindings can be used with `clipmenu`.
For example, I'm using the following script bound to `Super+v`:
```
#!/bin/bash
trap "exit" INT
# Run clipmenu
CM_LAUNCHER=rofi clipmenu -p "Paste" -mesg "Use Shift+Delete to delete an item" \
-kb-delete-entry "" -kb-custom-1 "Shift+Delete" \
-kb-accept-alt "" -kb-custom-2 "Shift+Return"
exit_code=$?
case $exit_code in
0) xdotool key "shift+Insert" ;;
10) clipdel -d ^"$(xsel -b)"$; "$0" ;;
*) exit $exit_code ;;
esac
```
With the above script, I have 3 different options when running `clipmenu`:
- if I press `Return`, the selected item is pasted to where my cursor currently is (a bit hackily with `xdotool`)
- if I press `Shift+Return`, the selected item is sent to the clipboard ("default" `clipmenu` behavior)
- if I press `Shift+Delete`, the selected item is deleted from `clipmenu`, and the script runs itself again (essentially keeps `clipmenu` open)
In order for this to work, the only change needed in `clipmenu` is to preserve the exit codes from the custom keybindings.
This allows you to use clipmenu in desktop scripts. For example you
could pipe the output of your narrowed selection to another command.
Signed-off-by: William Casarin <jb55@jb55.com>
In c7c894a0, a per-selection line-cache was introduced in order to
overcome some of the limitations of clipmenu at the time (for example,
missing duplicate detection). However, now we have all the features we
need to have a single line cache again, and having multiple line caches
has caused more trouble than it is worth.
For example, maintaining CM_MAX_CLIPS globally is extremely cumbersome,
so we don't do it, and CM_MAX_CLIPS is actually acted on per-selection.
We also have had bugs where we perform actions on cache files without
properly consulting other line caches, and while those can be fixed, the
simplest thing to do now is just to go back to having a single line
cache.
If people want to use this, they can just pass `-l <n>` to clipmenu and it will
be passed through to dmenu. I've checked that passing `-l` twice works fine and
accepts the second passed `-l` optarg as the definitive one.