4 ms·

> How exactly do you propose that wttr.in, which is not actually a process running on your machine (but a remote server), call isatty() on your machine? That's

> How exactly do you propose that wttr.in, which is not actually a process running on your machine (but a remote server), call isatty() on your machine? That's exactly my point. You can't do that. $ curl --head -s wttr.in/London | grep Content-Type Content-Type: text/plain; charset=utf-8 This is not plaintext, this is ANSII garbage. If you're outputting HTML, you set the content type to text/html, so the client can interpret it. But the lack of an associated content type is not the problem, it's the blind assumptions about the capabilities of the client.

throwaway150 1y ago
Thanks for clarifying. You're right! The output isn't actually text/plain. As someone who values standards, it is annoying to see control-code garbage when the content type claims to be text/plain. But wttr.in seems more like a fun novelty than a serious service and I suspect they don't pay much attention to standards. Still, I'm not sure that excuses saying one thing in the headers and delivering something else in the body. But you've got a fair point. So thanks!
- kevin_thibedeau 1y ago
  Control codes are documented in a standard for use in terminals. So not all standards are valued?
  - throwaway150 1y ago
    That control codes are documented in a standard is orthogonal to the HTTP standard. A terminal program should follow the terminal standard by all means. But a web service advertising one Content-Type but delivering another Content-Type is a violation of the web standards.
klinch 1y ago
Agreed, but but what would the right content type even be? Afaik there's no `text/tty` or `text/with-control-characters` etc. On the other hand, using the generic `application/octet-stream` seems unnecessarily vague?
- rollcat 1y ago
  Here's my shot: - curl sees that the standard output is a tty, consults $TERM, termcap, etc - curl crafts an "Accept:" header, format to be specified - server sees Accept and responds with appropriately encoded response; e.g. for text/plain it would just output preformatted text As this is currently NOT a common use case (mostly fun toys, biggest use case is Github printing out a pride flag), the exact content type can be easily iterated on to standardise it. For example, the most common cases (TERM=xterm or xterm-256color) could be specified in the standard and treated as abbreviations for the complete description of capabilities. The server can have those common cases built-in, but it should also be free to ignore any capabilities it doesn't understand and send out a conservative response. All of these smarts could be a part of a library or framework. I made this up on the spot, it's not hard, because the entire stack is adequately layered. So just don't break those layers, m'kay?
anthk 1y ago
Pipiing it to less -r will work.

throwaway150 1y ago

Thanks for clarifying. You're right! The output isn't actually text/plain. As someone who values standards, it is annoying to see control-code garbage when the content type claims to be text/plain. But wttr.in seems more like a fun novelty than a serious service and I suspect they don't pay much attention to standards. Still, I'm not sure that excuses saying one thing in the headers and delivering something else in the body. But you've got a fair point. So thanks!

kevin_thibedeau 1y ago
Control codes are documented in a standard for use in terminals. So not all standards are valued?
- throwaway150 1y ago
  That control codes are documented in a standard is orthogonal to the HTTP standard. A terminal program should follow the terminal standard by all means. But a web service advertising one Content-Type but delivering another Content-Type is a violation of the web standards.

klinch 1y ago

Agreed, but but what would the right content type even be? Afaik there's no `text/tty` or `text/with-control-characters` etc. On the other hand, using the generic `application/octet-stream` seems unnecessarily vague?

rollcat 1y ago
Here's my shot: - curl sees that the standard output is a tty, consults $TERM, termcap, etc - curl crafts an "Accept:" header, format to be specified - server sees Accept and responds with appropriately encoded response; e.g. for text/plain it would just output preformatted text As this is currently NOT a common use case (mostly fun toys, biggest use case is Github printing out a pride flag), the exact content type can be easily iterated on to standardise it. For example, the most common cases (TERM=xterm or xterm-256color) could be specified in the standard and treated as abbreviations for the complete description of capabilities. The server can have those common cases built-in, but it should also be free to ignore any capabilities it doesn't understand and send out a conservative response. All of these smarts could be a part of a library or framework. I made this up on the spot, it's not hard, because the entire stack is adequately layered. So just don't break those layers, m'kay?

anthk 1y ago

Pipiing it to less -r will work.