Closed catfact closed 7 years ago
dc0601ba9926ac55b6356d9d580c1e550a9a86ad
does this work over ssh?
we'll also log in via uart, so 'screen' as well
On Wed, Mar 8, 2017 at 2:30 AM ezra buchla notifications@github.com wrote:
... obviously, but some questions:
readline+ncurses combo has some wrinkles re:SIGWINCH handling, &c:
http://stackoverflow.com/questions/691652/using-gnu-readline-how-can-i-add-ncurses-in-the-same-program https://github.com/ulfalizer/readline-and-ncurses
an interesting reference for both design and implementation is actually gdb: http://sourceware.org/git/?p=gdb.git;a=blob;f=gdb/tui/tui-io.c
- how does readline work over an ssh connection? my guess is that arrow keys are probably fine, function keys almost certainly fine, but ctl and meta might be complicated by client terminal / ssh server.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/catfact/norns/issues/15, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPEcJkPJG5fG9M5IkDke25iRHHlXvwgks5rjlkXgaJpZM4MWdUC .
yes
wonderful!
On Thu, Mar 9, 2017 at 7:25 PM, ezra buchla notifications@github.com wrote:
yes
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/catfact/norns/issues/15#issuecomment-285531002, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPEcPOrufQa9Y8MtbN_uNkNFwHNPAycks5rkJhcgaJpZM4MWdUC .
a more detailed answer:
in this technique, we use ncurses
for all terminal IO. it passes input to readline
on a per-character basis, lets readline
do its editing stuff, and pulls readline
's buffer for display. at the same time it can also handle output from child processes and put it in a separate window. we need this.
"does ncurses work over ssh?"
yes. ssh as a network protocol is designed to pass shell signals as well as character data. the question is, will ncurses
be well behaved with a given ssh server configuration, host shell configuration, and client shell? of course it depends, but in general i think that using this standard unix stack (ncurses uses terminfo
and so on) is the most robust approach - it works for nano
and all the other standard unix tools.
that said, there are two general issues:
getting non-ascii characters across a socket (secure or otherwise), especially the meta/alt key, and combos like ctl-left
, which the client terminal will often capture for its own use. that's why emacs and nano allow ESC as an alternate meta key, and stuff. this could be exacerbated on a serial connection, because not only the client shell but also the terminal emulator may be capturing or pre-processing keystrokes.
the safe thing is to not use those key combinations, and stick to ASCII and function keys. some of readline's more advanced editing features may not work but basic things should be pretty robust.
readline
is actually highly configurable. its bindings and escape sequences are determined by ~/.inputrc
and /etc/inputrc
, and can be overridden by environment variables. excrutiating detail available with man readline
.
so in the worst case maybe we won't get resize events. i should make sure the default sizes are usable (80x24 characters or something,) but this is not a big deal.
... obviously, but some questions:
an interesting reference for both design and implementation is actually gdb: http://sourceware.org/git/?p=gdb.git;a=blob;f=gdb/tui/tui-io.c