3 ms·

I've never seen dash dump escape sequences instead of acting on arrow keys. Probably, it's due to a missing or wrong TERM value? Nowadays, programs should be h

I've never seen dash dump escape sequences instead of acting on arrow keys. Probably, it's due to a missing or wrong TERM value? Nowadays, programs should be hard-coded to accept ANSI sequences and ignore TERM (unless they need to make some fine-grained distinction like do we have 256 color xterm compatibility). Those programs will never have that problem of not understanding arrow keys.

kragen 2y ago
it's more likely because she's running a version of dash compiled without readline support, probably debian's version (which is compiled that way because it's not intended as an interactive shell, but rather the lightest-weight posix-compliant shell they could build) i agree about ansi sequences. even that doesn't go far enough, though: we should probably be moving past character-cell terminals to something better so we can have things like proportional fonts, multiple font sizes, properly spaced borders, and rounded corners
- kazinator 2y ago
  Looks like I'm wrong. If I fire up an interactive dash on Ubuntu or Debian, no arrow keys. /bin/sh is dash, but that's only for hash bang scripts. Not just no arrow keys, but nothing. No Ctrl-P to recall previous line. No editing beyond the POSIX TTY line discipline stuff: Ctrl-W word erase, Ctrl-U line erase, backspace.
  - kragen 2y ago
    also i'm wrong; it doesn't have an option to compile with readline, just libedit (which indeed is not included in the debian package configuration). the incantation was as follows: : Downloads; apt-get source dash : Downloads; cd dash-0.5.12/ : dash-0.5.12; sudo apt install libedit-dev : dash-0.5.12; ./configure --with-libedit : dash-0.5.12; make : dash-0.5.12; src/dash -E libedit supports ^r but not ^o on the other hand my dash process with libedit is 1.3 megs rss while my bash process is 7 megs rss. and the dash executable is only 130k. still, bash is only about 20% slower to start up

kragen 2y ago

it's more likely because she's running a version of dash compiled without readline support, probably debian's version (which is compiled that way because it's not intended as an interactive shell, but rather the lightest-weight posix-compliant shell they could build) i agree about ansi sequences. even that doesn't go far enough, though: we should probably be moving past character-cell terminals to something better so we can have things like proportional fonts, multiple font sizes, properly spaced borders, and rounded corners

kazinator 2y ago
Looks like I'm wrong. If I fire up an interactive dash on Ubuntu or Debian, no arrow keys. /bin/sh is dash, but that's only for hash bang scripts. Not just no arrow keys, but nothing. No Ctrl-P to recall previous line. No editing beyond the POSIX TTY line discipline stuff: Ctrl-W word erase, Ctrl-U line erase, backspace.
- kragen 2y ago
  also i'm wrong; it doesn't have an option to compile with readline, just libedit (which indeed is not included in the debian package configuration). the incantation was as follows: : Downloads; apt-get source dash : Downloads; cd dash-0.5.12/ : dash-0.5.12; sudo apt install libedit-dev : dash-0.5.12; ./configure --with-libedit : dash-0.5.12; make : dash-0.5.12; src/dash -E libedit supports ^r but not ^o on the other hand my dash process with libedit is 1.3 megs rss while my bash process is 7 megs rss. and the dash executable is only 130k. still, bash is only about 20% slower to start up