Conversation
When kak is started from a background process, open("/dev/tty") fails.
TerminalUI::check_resize then bailed out early, leaving the terminal
dimensions at {0,0}: the whole screen stayed blank and window-relative
goto commands (gb) computed a negative buffer line, which Buffer::clamp
happily used to index m_lines out of bounds (SIGSEGV, the release build
compiles the guarding kak_assert away).
- check_resize now falls back to querying stdout, which we already
require to be a terminal.
- Buffer::clamp clamps negative coordinates instead of relying on
callers, and the gb computation no longer goes below the first line.
- Opening /dev/tty to restore stdin is now checked: on failure use
/dev/null rather than leaving fd 0 pointing at the piped input that is
already being consumed as the *stdin* fifo.
|
Why would you want to use Kakoune without a controlling terminal? If you want to execute Kakoune's command language, you can use I guess Kakoune probably shouldn't crash, just exit with a non-zero exit code. |
The case here is using Kakoune as $EDITOR within applications that are running in alternate-screen terminal. I checked bunch of other TUI/CLI editor (nano, neovim, vim, helix) and only Kakoune failed to launch in this environment. Discovered by accident when I was trying to start Kakoune from within Claude Code running in full TUI mode. |
| { | ||
| int tty = open("/dev/tty", O_RDONLY); | ||
| if (tty < 0) | ||
| tty = open("/dev/null", O_RDONLY); |
There was a problem hiding this comment.
So we cannot get any keyboard input in that case ? From what I understand we would just end-up with Kakoune showing up but no ability to directly interact with it except through kak -p. Am I missing something ?
There was a problem hiding this comment.
Correct, no keys in that case, but this branch only runs when stdin is piped (not a tty), so there was never a key source without /dev/tty. The old code left fd 0 racing against the *stdin* fifo reader on the same pipe. /dev/null turns that into a clean EOF/hangup instead.
There was a problem hiding this comment.
Then we should probably error out in this case, which I would expect to happen due to the tty check in TerminalUI constructor (terminal_ui.cc:457). How come this does not fire ? Are we in a situation where stdout is a tty but /dev/tty does not exist ?
Do you have a use case for the half-failing behaviour being proposed ? (where Kakoune quits gracefully but does not provide any interactivity)
There was a problem hiding this comment.
I don't have a use case, just a thought that it might be better than erroring out. Should I change that?
This fixes issue when trying to run kakoune without controlling terminal (e.g. trying to run from within Claude Code in full-terminal mode).
Without the fix following crash happens:
Fix resolves the issue, all tests are green.
Reproduction
Run Claude Code, run any prompt, press Left Arrow (that backgrounds the process and shows the list or thread), select the thread and press Ctrl-g (open Editor).