HighLine#ask crashes on suspend

[jeg2]

HighLine#ask crashes on suspend

[JEG2]

Thanks for reporting this. I'll try to look into it when I have some time.

[mickeyreiss]

No problem. If you have a sense of what type of bug this or maybe have a chance to confirm it is a real issue, is be happy to dig into the code a bit.

On Oct 30, 2013, at 19:55, James Edward Gray II [email protected] wrote:

Thanks for reporting this. I'll try to look into it when I have some time.

—
Reply to this email directly or view it on GitHub.

[abinoam]

I couldn't reproduce the crash. But in a macosx 10.9.4 and bash 4.3 Ctrl-Z in the middle of the input has unpredictable consequences on what #ask returns. Need futher investigation.

[abinoam]

Just taking note of this gist. Perhaps relevant.
https://gist.github.com/zdennis/3a0b685047ac086725b0

[zdennis]

@abinoam, thanks for looping me in here. This may very well be related. When you say:

Ctrl-Z in the middle of the input has unpredictable consequences on what #ask returns

Can you describe what you're seeing? Is it that one or more characters may be often be missing?

[abinoam]

Hi @zdennis

I have tried again with HighLine 1.7.1
A simple #ask as in:

#!/usr/bin/env ruby

require 'highline/import'

anything = ask("Anything?  ")
puts "You told #{anything}"

If you type something, then CTRL-Z, do something, and then fg, then you type another thing and then type enter.
HighLine just "drop" the first 'typing' and then shows you the last one (the one that you typed after the fg).

Well, but there's the "readline" mode, the noecho mode and etc. that I didn't tested.

So, IMHO, we shouldn't put too much (I mean any) effort in fixing this now.
HighLine will soon be under a major refactor.
So, with a cleaner code base I think it would be easy for you to hunt this bug (in case it persists).

[abinoam]

I've just tested for this behavior again with Ruby 3.2 and ubuntu 22.04.

The problem happens with "pure" gets

Try

ruby -e "p gets"

First type "first"
Then hit ctrl-Z
Then type "second" and hit <enter>
The returned string will be only "second"

I think suspending the process is flushing the input buffer.
If it affects Kernel#gets it's probably the intended behavior to flush the input buffer when suspending, but I'm not sure.

[abinoam]

I've just tried with bash and the behavior is the same

#!/bin/bash

printf "Type: "

read astring

echo $astring

I'm closing this as a "non bug" meanwhile, but feel free to comment or reopen it @mickeyreiss if you want to discuss it any further.
Sorry for taking so long to answer this issue. I'm taking some time now to clean up them all these days.