Keep keystrokes working in the picker after login - #267
Merged
Conversation
On Windows, arrow keys did nothing in the context picker shown after login: the background watcher that listens for ^D during the auth wait could not be stopped there, so it stayed parked on the terminal and swallowed the keys the picker was waiting for. It now steps aside on terminals it cannot watch safely. Fixes #263 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
@scotwells Tested on Win 11 Intel. Works as expected. |
bmertens-datum
approved these changes
Aug 5, 2026
bmertens-datum
left a comment
Contributor
There was a problem hiding this comment.
works for me. Thanks!
ecv
approved these changes
Aug 5, 2026
Contributor
Author
|
@bmertens-datum this is fixed in v0.18.1. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #263.
On Windows, arrow keys do nothing in the context picker that appears after
datumctl login. The list renders, but the selection won't move. Passing--project/--organizationor the env vars works, because those skip the picker.Cause
The auth wait starts a background watcher so ^D can cancel it. The watcher polls stdin using read deadlines; when a stream doesn't support them it falls back to a plain blocking read that nothing can interrupt — not even the stop function called when login finishes. Windows console handles never support deadlines, so on Windows that read always parks on the terminal and stays there. The picker starts, and the two readers compete for one console: the stray one is still holding the terminal in line-input mode, so arrow keys get eaten by the console's own line editor before the picker ever sees them.
The watcher now probes deadline support before it starts, and declines to watch at all when it's unsupported. On those terminals the login wait is cancelled by ^C only — ^D never worked there anyway, since it isn't an end-of-input convention on a Windows console.
Unix is unaffected: a terminal is pollable there, so deadlines work and the watcher behaves exactly as before.
Verification
The bug reproduces off-Windows, because a regular file reports the same "deadlines unsupported" error a console handle does. Against the unfixed watcher,
"hello\n"typed during the wait reaches the next reader as"ello\n"— the stolen keystroke, in miniature. Both new tests fail before the change and pass after, and they're platform-neutral so CI catches a reintroduction.Still worth confirming on real hardware: the final step — a cooked-mode read swallowing arrow keys — is reasoned from the Windows console API, not observed, as none of us have a Windows machine. Everything upstream of it is verified from source.
@bmertens-datum, two things would help confirm this is the whole story:
datumctl ctxwith no arguments, in a fresh terminal with no login first, have working arrow keys? It should.