Murex gets stuck in loop due to EAGAIN

[tiymat]

Describe the bug:
Not sure if this is properly a murex or readline bug, but I'm leaning Murex, so I'll open it here.

When I use Murex on Linux to run a command which sets stdin to non-blocking and doesn't set it back, the line read /dev/stdin: resource temporarily unavailable repeatedly spams my terminal so fast I can't even kill Murex with Ctrl+C. I have to close my terminal emulator.

Expected behaviour:
At least one of murex and readline should handle this more gracefully.

Screenshots:
N/A

Platform (please complete the following information):

• OS, output from uname -a if supported: 6.17.5-arch1-1
• Terminal Emulator: kitty 0.43.1 (also reproduced in foot 1.25.0)
• Murex version, output from version --no-app-name: 7.1.4143 (unknown)

Additional context
I encountered this by running the Curl test suite with make test from the curl source directory, but I was able to get an LLM to generate a one-liner that reproduces the issue: python3 -c "import fcntl,os,sys; fcntl.fcntl(0,fcntl.F_SETFL,fcntl.fcntl(0,fcntl.F_GETFL)|os.O_NONBLOCK); print('stdin now non-blocking')"
The issue doesn't occur when I run the above python command in bash and fish.

[lmorg]

I did run into this issue before and I think it's to do with how I don't follow POSIX strictly because of hooking in additional features (eg job control functions, coloured stderr, etc).

I'll have a play. The python code you've shared is very useful!

[tiymat]

Maybe this is hacky, but would it be an option to just put something in execFork after the cmd.Wait() call that sets the stdin to blocking?

[lmorg]

funny enough my of my early attempts to get Helix to work with job control was doing just that. But I ran into a plethora of annoying edge cases where behavior would differ subtly between Linux and macOS. This made me nervous about hard-to-test bugs on other UNIX platforms, so I scrapped the code.

However might be a way I can reintroduce this behind a feature flag.