'abort' doesn't abort all the time

[ngirard]

When running find|sk --bind 'enter:execute(echo {})+abort', skim doesn't always abort.

That is, the selection is printed, then a newline. But the caret stays on an empty line below, skim keeps running, and hitting enter again doesn't get us back to the shell. Typing ctrl-c is needed to end the program.

Tested on Ubuntu 19.04 running konsole, bash 5.0.3 and skim 0.7.0.

[lotabout]

@ngirard Thanks for report! Could you help reproducing on other terminals (say xterm)?
I cannot reproduce on Mac 10.14.6 + iterm2/Terminal + GNU Bash 3.2.57/zsh 5.7.1 + skim 0.7.0.

[ngirard]

Hey, sorry for the late reply.
I was just able to reproduce the same behavior using

• Xterm 330 + bash 5.0.3
• Xterm 330 + zsh 5.5.1
• Alacritty 0.3.3 + bash 5.0.3
• Alacritty 0.3.3 + zsh 5.5.1

Would you like me to try anything else ?

[ngirard]

The problem still occurs using Skim 0.8.0.
Can I be of any help here ? Would you like me to record a screencast of my terminal ?
Cheers

[lotabout]

@ngirard Could you please try

find | RUST_LOG=debug sk --bind 'enter:execute(echo {})+abort' 2> log.txt

After you reproduce the issue, could you please paste the log here? Thanks!

[ngirard]

Unfortunately that didn't help.
I executed find | RUST_LOG=debug sk --bind 'enter:execute(echo {})+abort' 2> log.txt several times.
Sometimes the command ran as expected, i.e. with sk exiting properly ; and sometimes the command ran improperly, i.e. with sk not exiting.
The contents of the log.txt file is the same in both cases, modulo the timestamps (which I verified using diff).

Here's the contents of log.txt when sk exits properly:

2020-03-29 12:18:03,186 - DEBUG - collector: command killer start
2020-03-29 12:18:03,186 - DEBUG - collector: command collector start
2020-03-29 12:18:03,186 - DEBUG - collector: command collector stop
2020-03-29 12:18:03,186 - DEBUG - collector: command killer stop
2020-03-29 12:18:03,187 - DEBUG - got key_action: "enter:execute(echo {})+abort"
2020-03-29 12:18:03,187 - DEBUG - RE: caps: Captures({0: Some("enter:execute(echo {})+abort"), 1: Some("enter"), 2: Some("execute(echo {})+abort")})
2020-03-29 12:18:03,187 - DEBUG - RE_BIND: caps: Captures({0: Some("execute(echo {})+"), 1: Some("execute"), 2: Some("(echo {})")})
2020-03-29 12:18:03,187 - DEBUG - RE_BIND: caps: Captures({0: Some("abort"), 1: Some("abort"), 2: None})
2020-03-29 12:18:03,187 - DEBUG - parsed key_action: "enter": [("execute", Some("echo {}")), ("abort", None)]
2020-03-29 12:18:03,190 - DEBUG - reader: collect_item start
2020-03-29 12:18:03,190 - DEBUG - engine: Noop
2020-03-29 12:18:03,190 - DEBUG - reader: collect_item stop
2020-03-29 12:18:03,195 - DEBUG - engine: Noop
2020-03-29 12:18:05,075 - DEBUG - kill reader, components before: 0

Here's the contents of log.txt when sk doesn't exit properly:

2020-03-29 12:18:14,266 - DEBUG - collector: command killer start
2020-03-29 12:18:14,269 - DEBUG - collector: command collector start
2020-03-29 12:18:14,269 - DEBUG - collector: command collector stop
2020-03-29 12:18:14,269 - DEBUG - collector: command killer stop
2020-03-29 12:18:14,270 - DEBUG - got key_action: "enter:execute(echo {})+abort"
2020-03-29 12:18:14,270 - DEBUG - RE: caps: Captures({0: Some("enter:execute(echo {})+abort"), 1: Some("enter"), 2: Some("execute(echo {})+abort")})
2020-03-29 12:18:14,270 - DEBUG - RE_BIND: caps: Captures({0: Some("execute(echo {})+"), 1: Some("execute"), 2: Some("(echo {})")})
2020-03-29 12:18:14,270 - DEBUG - RE_BIND: caps: Captures({0: Some("abort"), 1: Some("abort"), 2: None})
2020-03-29 12:18:14,270 - DEBUG - parsed key_action: "enter": [("execute", Some("echo {}")), ("abort", None)]
2020-03-29 12:18:14,279 - DEBUG - reader: collect_item start
2020-03-29 12:18:14,289 - DEBUG - engine: Noop
2020-03-29 12:18:14,289 - DEBUG - reader: collect_item stop
2020-03-29 12:18:14,293 - DEBUG - engine: Noop
2020-03-29 12:18:15,921 - DEBUG - kill reader, components before: 0

[ngirard]

This defect is very annoying as it prevents me from using Skim and forces me to resort to using Fzf instead.

I'm actually surprised I'm the only one to have ever reproduced it. @lotabout, could you please try and reproduce it again ?

For instance, using find /tmp |sk --bind 'enter:execute(echo {})+abort' or (for a quiter output) find /tmp 2>/dev/null|sk --bind 'enter:execute(echo {})+abort' ?

Using the last command on my system, Skim exits properly most of the time, but fails to exit at least 20% of the time, so you might need to execute it several times before experiencing the issue.

I've found that the line chosen before hitting return doesn't matter.

I've found the same problem executing other trivial commands, such as execute(ls {}).

Also, since I was suspecting a stdio buffering problem, I tried using stdbuf -i0 or stdbuf -iL (see e.g. "stdio input buffering problems" by Pádraig Brady, GNU coreutils maintainer), but it didn't make any difference.

[ngirard]

Also @lotabout, is there any workaround you could give me, that would allow me to keep using Skim ?

[lotabout]

@ngirard

1. I WILL try to reproduce.
2. What exactly do you want to achieve? So that I could check if there is any workaround.

[lotabout]

@ngirard Oh, which arch do you use? linux-gnu or linux-musl?

[ngirard]

which arch do you use? linux-gnu or linux-musl?

the problem doesn't seem to arise using the linux-gnu build

So sorry about the false flag.
I tested both binaries, and the problem occurs using both.

[lotabout]

@ngirard I finally got an Ubuntu machine and was able to reproduce the issue.
Seems that tuikit wasn't release the lock correctly at sometime. Should be fixed by the corresponding commit.

Was testing on CentOS and could not reproduce the issue. :-(

Will later publish a new release of tuikit.

[ngirard]

Great !!! Thanks you so much, @lotabout !