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

81–90 of 153 posts

Re: "Rules" that terminal programs follow

#81

Post by rodgerd »

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…

> * Don't use color as the only indication of something. The user's terminal might not display it

The user may be colour-blind (30% of the population). The user may be completely blind and relying on a screen reader.

Re: "Rules" that terminal programs follow

#82

Post by teddyh »

lilyball wrote: post #57
kelnos wrote: post #46

Earlier quoted context omitted.

It means that the keystrokes you type aren't just immediately handled to the application in raw form; something higher up the chain (kernel, terminal emulator, shell) is pre-processing ("cooking") them in some way, possibly taking actions before (or in place of) passing the keystrokes to the application. For example, if an application you're using has left things in cooked mode, and you press ctrl+c, the application…

cooked mode also generally gives input to the program a line at a time and handles things like backspace to delete characters, and it handles program output too, doing things like replacing \n with \r\n.

No, line-by-line vs. character-by-character is a separate mode from “cooked” mode. See “stty extproc”.

Re: "Rules" that terminal programs follow

#84

Post by neilv »

hatthew wrote: post #66
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.

The ones I listed were mostly descriptive, until recent years.

Re: "Rules" that terminal programs follow

#85

Post by saghm »

machinestops wrote: post #40
saghm wrote: post #26

Earlier quoted context omitted.

I don't think it's part of the terminal emulator (e.g. xterm, gnome-terminal) but the shell (bash, zsh, etc.). You're correct that it's not something that's implemented as an external program though; the "current directory" is state for a currently running terminal session, so changing that state is done via the shell interface (either directly by built-in commands like cd or indirectly via external commands that use…

Note: Child processes can't change the working directory of the parent. An external command (that is, not a shell builtin, shell function, or externally loaded module) cannot change the working directory, because they're launched as child processes.

Good point. I'm not sure why I was thinking that it was possible to do via some other command invoking `cd` or something, but you're right that the only examples I can think of are all using other builtins (e.g. invoking `source` to have a script change the current state).

Re: "Rules" that terminal programs follow

#86

Post by saghm »

emmelaich wrote: post #63
saghm wrote: post #20

Earlier quoted context omitted.

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.

Interesting! Too bad my googling didn't come up with that, since it was not at all easy to discover anything from within the shell.

Re: "Rules" that terminal programs follow

#87

Post by saghm »

Sesse__ wrote: post #28
saghm wrote: post #20

Earlier quoted context omitted.

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…

If you ever need to do so again, try gqlplus, which wraps sqlplus to add such quality-of-life features :-)

I hope my streak of almost a decade of not needing to use Oracle will continue, but if not, I definitely will be looking for alternatives to sqlplus...

Re: "Rules" that terminal programs follow

#88

Post by xuhu »

How did copy-pasting text between programs fit in the initial shell design ? You can't paste from a remote tmux to a local one, you can't mouse-copy multiple lines from a vim vertical split, etc. Where's the terminal clipboard that works across programs ?

Re: "Rules" that terminal programs follow

#89

Post by eviks »

Some of the rules codify many bad practices, from poor color support to unergonomic keybindings. Given that the support isn't universal and breaks in parts anyway, it's better to break it competely and use something more ergonomic

Re: "Rules" that terminal programs follow

#90

Post by Sophira »

One thing I'm wondering about is what text encoding the program should use to output. I tend to write scripts that output exclusively in UTF-8, but I realise this might not be a given. (And, of course, the user's terminal expected encoding setting doesn't necessarily mean that files should be written in that encoding.)

Presumably, you would ideally output text in whatever encoding is specified by the LANG environment variable, but this seems like something that only comes with full i18n/l10n support, since it also specifies the actual language to use.

Are there any actual established guidelines on this?

Post reply on HN