Occasionally refuses input, reprompts, puts terminal in unrecoverable state

[dontlaugh]

Bug Description

This is the rlwrap pattern that occasionally causes this behavior for me.

patchfile=$(rlwrap -S "enter patch file: " -c -H $histfile -o cat)

My prompt looks like this:

0 % ./run patch
enter patch file: 

If I type input here, and hit enter, the input is cleared and I am presented with the same prompt. No scrolling in the terminal happens, just the same prompt:

0 % ./run patch
enter patch file: 

After sending ctrl-C, my zsh prompt indicates exit code 130

130 % 

Whenever this happens, it seems to put the terminal into a state where every subsequent invocation of this rlwrap + cat pattern exhibits this same behavior. The only solution (it seems) is to spawn a new terminal session.

This behavior is infrequent, but regular enough that I was finally motivated to report this bug.

It only happens with cat. I can use this alternative pattern with socat + a fifo to capture input.

mkfifo $FIFO
rlwrap -S 'task >>> ' -p'3;31' -- socat -u - PIPE:$FIFO

That's never failed me.

---

Environment

A little bit about my environment: Terminal emulator: kitty 0.23.1 operating system: Pop!_OS 21.10 (an Ubuntu variant)

I have no readline customizations, no ~/.inputrc file

I built rlwrap from this commit, but I have observed this behavior for a while now using older versions from package managers.

commit 5aa2609a7e4c76f37c721110bcec312d3efa7e2d (HEAD -> master, tag: v0.45.1, origin/master, origin/HEAD)
Author: Hans Lub <hanslub42@gmail.com>
Date:   Wed May 19 08:11:33 2021 +0200

    rlwrap would always open /tmp/rlwrap.debug after forking child command

---

Let me know if there are any debugging techniques I can try for the next time I see this.

PS: thanks for rlwrap. It's really cool.

[hanslub42]

I tried to reproduce this, but was unable. Could you try putting

$if cat
     set enable-bracketed-paste off
$endif

in your .inputrc and see whether that makes any difference?

[hanslub42]

@dontlaugh: did this solve the problem? If so, this issue is a duplicate of bugs #108 and #113, which were fixed in the newest rlwrap release.

[dontlaugh]

I have not used my scripts that incorporate rlwrap since opening this issue, so I haven't been able to check on this.

This issue has always been random and difficult to reproduce for me, so I don't know when I'll be able to provide feedback.

That said, I will remove my edits to .inputrc, and install a newer release. If the problem persists on a newer release WITHOUT the updated .inputrc, I will let you know.

[hanslub42]

OK, thanks! Closing this until the problem resurfaces.

[dontlaugh]

This bug hasn't resurfaced for me after several months of use. Thanks for the fix!

[dontlaugh]

After a long time, I caught this again. Version: rlwrap 0.45

I run rlwrap from a script like this

name=$(rlwrap -pRed -S 'pick a name for the vm: ' -o cat)

echo "chosen: $name"

I took the opportunity to capture strace output while my terminal was still broken. I trace rlwrap directly.

name=$(strace --output=strace_log --follow-forks --output-separately rlwrap -pRed -S 'pick a name for the vm: ' -o cat)

echo "chosen: $name"

and I captured another strace session, changing the script to Yellow just for fun.

name=$(strace --output=strace_log2 --follow-forks --output-separately rlwrap -pYellow -S 'pick a name for the vm: ' -o cat)

echo "chosen: $name"

With --follow-forks and --output-separately, strace will drop a file for each child process (I assume cat in this case).

The sessions are named "strace_log" and "strace_log2". There are two files for each session. The numbered suffix is their PID at the time of execution.

Session 1 strace_log.155603.txt strace_log.155604.txt

Session 2 strace_log2.161560.txt strace_log2.161561.txt

What I did in each session was identitcal.

1. run my bash script
2. hit the rlwrap prompt "pick a name for the vm: "
3. type "flux"
4. hit enter; After hitting enter, the prompt re-appears.
5. I type "flux" and hit enter 3 more times (total of four times hitting enter)

I'm at work right now, so I haven't looked at these logs yet. But I am capturing them for posterity.