-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
base repository: NixOS/nix
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: a25214a2bc38
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
...
head repository: NixOS/nix
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: f5941e14e0f1
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 1 commit
- 1 file changed
- 1 contributor
Commits on Apr 10, 2020
-
installer: Fix terminal colors.
The install-multi-user script uses blue, green, and red colors, as well as bold and underline, to add helpful formatting that helps structure its rather voluminous output. Unfortunately, the terminal escape sequences it uses are not quite well-formed. The relevant information is all there, just obscured by some extra noise, a leading parameter `38`. Empirically, the result is: * On macOS, in both Terminal.app and iTerm2, the spurious `38` is ignored, the rest of the escape sequence is applied, and the colors show up as intended. * On Linux, in at least gnome-terminal and xterm, the spurious `38` and the next parameter after it are ignored, and what's left is applied. So in the sequence `38;4;32`, the 4 (underline) is ignored but the 32 (green) takes effect; in a more typical sequence like `38;34`, the 34 (blue) is ignored and nothing happens. These codes are all unchanged since this script's origins as a Darwin-only script -- so the fact that they work fine in common macOS terminals goes some way to explain how the bug arose. Happily, we can make the colors work as intended by just deleting the extra `38;`. Tested in all four terminals mentioned above; the new codes work correctly on all of them, and on the two macOS terminals they work exactly the same as before. --- In a bit more technical detail -- perhaps more than anyone, me included, ever wanted to know, but now that I've gone and learned it I'll write it down anyway :) -- here's what's happening in these codes: An ECMA-48 "control sequence" begins with `\033[` aka "CSI", contains any number of parameters as semicolon-separated decimal numbers (plus sometimes other wrinkles), and ends with a byte from 0x40..0x7e. In our case, with `m` aka "SGR", "Select Graphic Rendition". An SGR control sequence `\033[...m` sets colors, fonts, text styles, etc. In particular a parameter `31` means red, `32` green, `34` blue, `4` underline, and `0` means reset to normal. Those are all we use. There is also a `38`. This is used for setting colors too... but it needs arguments. `38;5;nn` is color nn from a 256-color palette, and `38;2;rr;gg;bb` has the given RGB values. There is no meaning defined for `38;1` or `38;34` etc. On seeing a parameter `38` followed by an unrecognized argument for it, apparently some implementations (as seen on macOS) discard only the `38` and others (as seen on Linux) discard the argument too before resuming. (cherry picked from commit 7313aa2)
Configuration menu - View commit details
-
Copy full SHA for f5941e1 - Browse repository at this point
Copy the full SHA f5941e1View commit details
There are no files selected for viewing