Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Rules" that terminal programs follow

jvns.ca

Post reply on HN
Print view View original

61–70 of 153 posts

Re: "Rules" that terminal programs follow

#61

Post by saint_yossarian »

jeffrallen wrote: post #39
chriswarbo wrote: post #35

Ctrl-D for REPLs always bites me with GHCi. My usual approach to quitting GHCi is: - Press Ctrl-D, like normal - Get confused when nothing happens - Remember that it doesn't work in GHCi, so run `:q` instead - Get an error message about "lexical error at character '\EOT'", due to Ctrl-D inserting an invisible char at the start of the input - Try `:q` again, without any invisible prefix - GHCi successfully quits

You think that's hard, try getting out of vi when you're on a keyboard from an unfamiliar country.

There's also the `ZZ` / `ZQ` alternatives, so you just have to find those letters :)

Re: "Rules" that terminal programs follow

#63

Post by emmelaich »

saghm wrote: post #20
Sesse__ wrote: post #14

“rule 5.1: Ctrl-W should delete the last word […] I can’t think of any exceptions to this other than text editors but if there are I’d love to hear about them!” mysql(1) only links to editline instead of readline, where Ctrl-W by default deletes everything to the start of the line, not just the last word. It drove me mad in the period where I had to use it; you just see your entire nice query disappear. :-)

It could be worse! Back in college, I had the misfortune to decide to try to use sqlplus, Oracle's CLI to try to connect to their database. Not only did terminal shortcuts like Ctrl-W not work at all, but you couldn't even move the cursor earlier in the line, and there was no history navigation to get to the previous command, so any typo forced you to retype the entire thing from scratch. Entering a single forward sl…

Pretty sure Oracle's SQLplus supported the `e` command for a long time. Which invokes $EDITOR on last command.

On Unixes of course, don't know what VMS/MVS/.... did.

Re: "Rules" that terminal programs follow

#64

Post by tomsmeding »

chriswarbo wrote: post #35

Ctrl-D for REPLs always bites me with GHCi. My usual approach to quitting GHCi is: - Press Ctrl-D, like normal - Get confused when nothing happens - Remember that it doesn't work in GHCi, so run `:q` instead - Get an error message about "lexical error at character '\EOT'", due to Ctrl-D inserting an invisible char at the start of the input - Try `:q` again, without any invisible prefix - GHCi successfully quits

Are you on Windows?

Re: "Rules" that terminal programs follow

#65

Post by cpif »

I can use Ctrl-A, Ctrl-E, and Ctrl-U in text fields in the lynx browser, but not Ctrl-W.

I just checked to see if Ctrl-F and Ctrl-B work, and found that the former kills one word forward and the latter acts like Ctrl-W ought to?

Re: "Rules" that terminal programs follow

#66

Post by hatthew »

neilv wrote: post #42

Additional suggestions: * Respect the user's default foreground and background color. Don't change them without good reason. * If you use colors, make them legible regardless of what the default background and foreground colors are, and regardless of the terminal's color map. * Don't use color as the only indication of something. The user's terminal might not display it, and it probably won't be preserved in copy&pas…

As the article explicitly stated, these are descriptive not prescriptive rules. They're things that you can generally assume all terminal programs already follow.

Re: "Rules" that terminal programs follow

#67

Post by jrockway »

One that's missing is treating ~ as the home directory. This appears to be a shell thing and not a POSIX API thing. For example, this doesn't work:

  func main() {
        if _, err := os.ReadFile("~/.bashrc"); err != nil {
                log.Fatal(err)
        }
        fmt.Println("ok")
  }
Meanwhile over in shell land:

  $ echo ~/~/~
  /home/jrockway/~/~
The behavior is actually kind of amazing.

I mention it because while "yourprogram ~/path/to/file" always works, having a repl that asks for a filename might not work. I've seen a lot of software where this DOES work, so I think it counts as a "most TUI programs do this" thing.

Re: "Rules" that terminal programs follow

#68

Post by throwaway127482 »

felixhummel wrote: post #9

I'd add "long-running processes should reload their configuration on SIGHUP". :)

This behavior seems difficult to actually implement in practice, no? Your application has to be careful not to accidentally cache any configuration state, as well as any state derived from the configuration, otherwise it will go out of sync. Maybe easy for trivial apps but most apps requiring configuration files are non trivial.

Re: "Rules" that terminal programs follow

#69

Post by emmelaich »

ucarion wrote: post #45

What does "cooked" mode mean in the context of this article?

Do stty -a and have a look at the output. Do `man stty` for the whole gory story.

Raw means send characters immediately, literally. Cooked imply some some of the flags are on, specifically (from memory) icanon, echo, among the `lflags`. Plus others.

Further down among `cchars` you'll see werase = ^w and kill = ^u. Here kill means kill (erase) the line, not send a signal.

Re: "Rules" that terminal programs follow

#70

Post by abbeyj »

felixhummel wrote: post #9

I'd add "long-running processes should reload their configuration on SIGHUP". :)

This is probably technically out of scope for this article. Long-running processes that respond to SIGHUP will usually be running detached (with no controlling TTY). Thus it is a bit of stretch to call them "terminal programs".
Post reply on HN