[[ ${VALUE} ]] means "expand the VALUE variable, splitting on spaces,
and pass those words as arguments to [[…]]". So if VALUE was the string
'-n blah' then that would expand to '[[ -n blah ]]' which is meaningful
but not at all what was intended.
Instead it appears this intented to check for a non-empty string.
This isn't an interactive script. Any relevant environment should
already be inherited from tmux, and sourcing ~/.bash_profile may cause
~/.bashrc to be sourced with unexpected effects.
OSC52 support was implemented before two major refactors in tmux-thubs:
- Decouple tmux-thumbs from tmux
- Removal of rustbox with termion
I'm not sure if is the right decision, but I moved the arguments to
swapper land because it looks like more tmux related. If it makes sense
for other terminals to support this we can move it back.
The question we need to answer here if it makes sense for standalone `thumbs`:
```
cat sample/test1 | ./target/release/thumbs --osc52
```
Currently I can only get the copied content in the tmux copy buffer, not in the
system clipboard. This commit adds an option to print the copied text as a
OSC52 copy escape sequence, which in supported terminals (tested in iTerm) will
be copied to the system clipboard.
The regular expression describing the tmux user options expects to find
quotes around the value. However, in at least tmux 3.0a the
`show-options -g` command doesn't display quotes around the values,
which means the regex fails.
For example, the current regex will fail to find these user options:
$ tmux -V
tmux 3.0a
$ tmux show -g | grep -E "@thumbs"
@thumbs-bg-color default
@thumbs-fg-color green
@thumbs-hint-bg-color default
@thumbs-hint-fg-color blue
@thumbs-select-bg-color default
@thumbs-select-fg-color green
Make the quotes optional so that these options are picked up.
Fixes#33
