Live data from Hacker News

"Rules" that terminal programs follow

jvns.ca

101–110 of 153 posts

Re: "Rules" that terminal programs follow

#101
post #71

Some more notes: - If this is your first time hearing about the readline/emacs keybindings like Ctrl-E and Ctrl-W, you'll be pleased to know that most macOS input sources use these keybindings. If you're on macOS, feel free to try Ctrl-E, Ctrl-W, or Ctrl-U in your browser's address bar right now - If you're using a command line program that doesn't support _any_ line editing (e.g. no readline keybindings, and no othe…

> If you're on macOS, feel free to try Ctrl-E, Ctrl-W, or Ctrl-U in your browser's address bar right now

Most browsers I've used close the current tab when you press Ctrl-W. Actually, the terminal emulator I use, Alacritty, also does this, and most file explorers that have tabs also do. Iirc even windows explorer does this now, but it's been a while since I've actually used windows.

Re: "Rules" that terminal programs follow

#102
post #71

Some more notes: - If this is your first time hearing about the readline/emacs keybindings like Ctrl-E and Ctrl-W, you'll be pleased to know that most macOS input sources use these keybindings. If you're on macOS, feel free to try Ctrl-E, Ctrl-W, or Ctrl-U in your browser's address bar right now - If you're using a command line program that doesn't support _any_ line editing (e.g. no readline keybindings, and no othe…

> If you're on macOS, feel free to try Ctrl-E, Ctrl-W, or Ctrl-U in your browser's address bar right now Most browsers I've used close the current tab when you press Ctrl-W. Actually, the terminal emulator I use, Alacritty, also does this, and most file explorers that have tabs also do. Iirc even windows explorer does this now, but it's been a while since I've actually used windows.

Actually no I'm wrong, I forgot that command isn't control on a mac. Zen browser just does nothing when I press ctrl-W in the address bar.

Re: "Rules" that terminal programs follow

#103

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 wo…

In my opinion it should remain a shell thing. Adding tilde expansion just complicates the implementation of the tool. Now you need to know the current users home directory. And some tools might implement it incomplete so that '~' works but '~name' does not work.

In POSIX shells '~name' expands to the home directory of user 'name'

  $ echo ~bin
  /bin
Now your tool need a way to query home directory for any user including system users. Depending on NSS configuration this is more complicated than just reading /etc/passwd.

All for the rare case that someone passes a file path starting with tilde and wants it to be expanded. IMO, when you provide a file interactively you do so through a shell and tilde expansion is handled by the shell and otherwise just provide the actual file path and do not rely on the tool doing additional expansions.

PS: I mixed up TUI and CLI program a bit in my head. For an interactively used TUI program it might be beneficial to implement tilde expansion (but then it should be as complete as in Shells). A CLI program should not do magic stuff like tilde expansion.

Re: "Rules" that terminal programs follow

#104
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…

> * 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.

This is kind of impossible. One can potentially provide for customized colors, though.

Re: "Rules" that terminal programs follow

#105

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 wo…

wordexp() might be interesting.

https://pubs.opengroup.org/onlinepubs/9799919799/functions/w...

Re: "Rules" that terminal programs follow

#107
post #8

Earlier quoted context omitted.

Unless your app doesn't generate output,then grepping the output will not work if it's stderr and it will be confusing

How can you grep output if there's no output? Can you provide a concrete example of such an application?

Some applications print usage information (e.g. with --help flag) to stderr. That is a bit annoying when there is a lot of output and I just want to grep for some flag, since the first attempt will fail and then I have to try again after adding 2>&1.

Re: "Rules" that terminal programs follow

#108
post #104
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…

> * 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. This is kind of impossible. One can potentially provide for customized colors, though.

You can delegate the choice to the terminal by using ANSI color codes [1]. Then the onus is on the user/terminal developer to make sure the colors they’ve configured (or the defaults provided) are reasonable.

A downside of this is that it is quite restrictive, there are only like 8 colors.

EDIT: I missed the “regardless of the color map” bit, that is a bit unreasonable. Either you trust the terminal emulator or don’t. I think trying to have it both ways is too much.

[1]: https://gist.github.com/JBlond/2fea43a3049b38287e5e9cefc87b2...

Re: "Rules" that terminal programs follow

#109
post #85

Earlier quoted context omitted.

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).

There is a workaround I saw used by wcd, a tool for changing directories. To install it you have to add a wrapper function in your shell that executes the actual wcd binary, and after possibly interacting with the user to figure out what directory to change to the executable will print out the destination, and then the wrapper function will make the call to cd, affecting the shell it runs in.

https://wcd.sourceforge.io/

Post reply on HN