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

111–120 of 153 posts

Re: "Rules" that terminal programs follow

#111

Post by jrockway »

jrockway wrote: post #67

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…

Oh, and I just remembered where this always burns me. It's cases like this:

   ./myprogram --config=~/.config/myprogram
Of course, many flags parsers are aware of this, or at least accidentally aware of this, because you can write it in a form that your shell will expand.

   ./myprogram --config ~/.config/myprogram
For some reason, my muscle memory requires me to type the =. I don't know why. It's probably a habit I picked up from a former employer's flag parsing library. I also always use --underscores_like_this instead of --hyphens-like-normal-people for the same reason. Sigh!

Re: "Rules" that terminal programs follow

#112

Post by neilv »

ratorx wrote: post #108
rascul wrote: post #104

Earlier quoted context omitted.

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

For example, I've seen a program that sets foreground color to a symbolic (not RGB value) yellow, and doesn't set background. While that combination might be legible on some terminals, it's definitely not on all of them. Don't assume that the user's terminal's color map makes all combinations legible.

Re: "Rules" that terminal programs follow

#113

Post by GuB-42 »

jrockway wrote: post #67

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…

I would not do that to your own REPL unless you are really serious about it, with good documentation, escaping, etc...

What if there is a file named "~"? What about "~username"? How do you escape/quote it? What if $HOME is not set, or set to something different than the actual user home directory? What about Windows? Also, a lesser known fact is that typing "~." after newline in ssh will force close the connection from the client side and there is nothing the server can do about it, so don't make it part of your workflow.

Re: "Rules" that terminal programs follow

#114

Post by Vegenoid »

neilv wrote: post #112
ratorx wrote: post #108

Earlier quoted context omitted.

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…

For example, I've seen a program that sets foreground color to a symbolic (not RGB value) yellow, and doesn't set background. While that combination might be legible on some terminals, it's definitely not on all of them. Don't assume that the user's terminal's color map makes all combinations legible.

What combinations can be assumed to be legible? I think if a terminal user has their colors configured so that some of the 8 ASCII colors aren’t legible on their background, that’s on them, with the exception of white and black.

It seems like the only way to satisfy your ask is to not use color at all.

Re: "Rules" that terminal programs follow

#115

Post by yencabulator »

> then the operating system will return an EOF when you press Ctrl-D on an empty line.

This is akshully not correct. Control-D makes the read(2) return with the data currently in the input buffer. If there's no data in the buffer, that results in a 0-length read, which is how EOF is signaled.

Try this: run cat, type foo, press control-D. "foo" will be echoed, without any newline.

Re: "Rules" that terminal programs follow

#116

Post by wizzwizz4 »

yencabulator wrote: post #115

> then the operating system will return an EOF when you press Ctrl-D on an empty line. This is akshully not correct. Control-D makes the read(2) return with the data currently in the input buffer. If there's no data in the buffer, that results in a 0-length read, which is how EOF is signaled. Try this: run cat, type foo, press control-D. "foo" will be echoed, without any newline.

It is correct, because when you press Ctrl+D on an empty line, the OS will return an EOF. It's not a complete answer, but neither's yours, because you didn't consider what happens when the OOM killer reaps cat. However, it's not intended to be a complete description, because it's describing a UI convention.

Re: "Rules" that terminal programs follow

#117

Post by neilv »

Vegenoid wrote: post #114
neilv wrote: post #112

Earlier quoted context omitted.

For example, I've seen a program that sets foreground color to a symbolic (not RGB value) yellow, and doesn't set background. While that combination might be legible on some terminals, it's definitely not on all of them. Don't assume that the user's terminal's color map makes all combinations legible.

What combinations can be assumed to be legible? I think if a terminal user has their colors configured so that some of the 8 ASCII colors aren’t legible on their background, that’s on them, with the exception of white and black. It seems like the only way to satisfy your ask is to not use color at all.

The default configurations of most terminals includes illegible color combinations.

So I think it's not on every user to somehow design optimal color palette settings on their computer that work in all combinations (if they even can), but rather on the developers of software not to say "Hey, I bet every yellow would be legible on white" or "Yolo, I bet yellow is legible on every background, so I'm just going to set this foreground to yellow and not set background at all."

Re: "Rules" that terminal programs follow

#118

Post by quectophoton »

d3VwsX wrote: post #107
matheusmoreira wrote: post #23

Earlier quoted context omitted.

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.

Then there's `ssh-keyscan`, printing the "real" output to stdout, but also printing "comments" to stderr.

Nothing wrong with that, but it was a bit confusing the first time I saw that behavior.

Re: "Rules" that terminal programs follow

#119

Post by quectophoton »

matheusmoreira wrote: post #23
lionkor wrote: 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?

I think what they meant was something like:

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

With the first "output" meaning "specifically stdout", and the second meaning "what you see on the terminal".

As in, you run a command, see it printed a lot of stuff, so then you do it again but piping it to `grep` or `less`, and realize none of that output was actually going to stdout.

Re: "Rules" that terminal programs follow

#120

Post by linhns »

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 this: https://github.com/hakluke/how-to-exit-vim
Post reply on HN