-
-
Notifications
You must be signed in to change notification settings - Fork 15.4k
terminfo: symlink terminfo to /etc for ncurses #26897
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -46,6 +46,9 @@ stdenv.mkDerivation rec { | |||
buildInputs = lib.optional (mouseSupport && stdenv.isLinux) gpm; | |||
|
|||
preConfigure = '' | |||
# These paths end up in the default lookup chain. | |||
export TERMINFO_DIRS=/etc/terminfo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a mass rebuild? If yes, staging
might be appropriate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is, somehow. staging would be okay too, but this impacts only CLI apps with curses support. GUIs and many other tools are not impacted.
It is also a trivial change, with no failures to expect.
export TERM=$TERM | ||
''; | ||
|
||
security.sudo.extraConfig = '' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure whether everyone would want to have this on every machine. Adding some knob to disable this would help. Others probably also have an opinion on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have just gathered scattered options in the same file. This is not a new feature. Adding an option could be good, but that's not related to this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For context: the original motivation to disable this in sudo goes back to a bug in the 2000s: http://securityvulns.com/Adocument760.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean that it is now safe to export that env var for everyone ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@layus No, it means that it depends on your risk appetite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, we need to collect more feedback then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or we could simply drop these lines, as root's profile should setup TERMINFO correctly.
I will do that in a separate PR, and notify the ML.
@@ -46,6 +46,9 @@ stdenv.mkDerivation rec { | |||
buildInputs = lib.optional (mouseSupport && stdenv.isLinux) gpm; | |||
|
|||
preConfigure = '' | |||
# These paths end up in the default lookup chain. | |||
export TERMINFO_DIRS=/etc/terminfo | |||
|
|||
export PKG_CONFIG_LIBDIR="$dev/lib/pkgconfig" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need to quote here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, they cannot hurt, right ? Also, this is not part of the changeset :-).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that seems to be a recurring thing. I would like people to fix things when they are glaring in my face, and preferably also before they do a pull request for new features. I.e., to go over whatever wrong things the person before you has done and to fix it.
I.e., instead of arguing over it, wouldn't it be faster to just fix it and amend a commit? The alternative would be for me to create a PR specifically to fix whatever stupid quoting people do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why isn't quoting here appropriate? Where is it guaranteed that dev
will never contain any characters that require quoting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Ralith If you would be so kind to tell me how I can tell you in the kindest possible way that your assumptions are wrong, then I can tell you that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC, then unquoted values in export a=$b
isn't yet part of POSIX. But bash does already support it (dash doesn't, but we care only for bash in nixpkgs, right? :))
Refs: koalaman/shellcheck#595, http://austingroupbugs.net/view.php?id=351#c943
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @4z3 for providing references. I was unable to find any.
Now I really refuse to make a change according to an undocumented implementation of an unpublished (and not freely available) standard ;-).
I also agree that $out should never contain spaces, but again, look at the length of this discussion just to agree that not quoting is correct, while everybody agrees easily that quoting is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is available at http://pubs.opengroup.org/onlinepubs/9699919799/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@layus It has been like this since the 1990s. That you don't know this, nor the others, is becoming annoying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it is always nice to learn new things, and I really enjoy getting to the bottom of an issue/disagreement. You are indeed correct that the quotes are not needed here.
I think I can also understand your irritation at seeing code that does not match your standards. I also expect contributors to fix issues they encounter around their patches.
What I do not understand is why you consider extra quoting a big issue. It is common practice to quote bash strings, even when not needed. This shows that the content is intended to be a string. It is a bit like curly braces for blocks in C. If your block is only one statement, curly braces are not needed, but nobody ever asks you to remove them. While redundant, they are correct and convey intent.
The same applies with export: export CFLAGS="-Wall"
does not need quotes, but if you add another argument, then you will want the quotes, as in `export CFLAGS="-Wall -O1".
I will not change this, because it does not belong to this commit, and is not needed. You are of course free to fix it in another PR, but I urge you not to do that. While you really want to get rid of useless quotes, there will be someone else out there that insists on quoting every string. In the absence of a clear consensus, this will end up in a load of commits toggling quotes, with no added value. It will be even worse if these toggle happen together with unrelated changes.
For now, there is about 600 export
statements with quotes in nixpkgs, and the same without quotes. No consensus.
I really want to make a point here, because I did not appreciate being called on this non error. Like everyone else, I try to make my PR as good as possible and I appreciate constructive comments and technical discussions. I however find that subjective comments about code formatting make submitting PRs a pain. I do not understand why you would want to lose time even noticing that, and I am afraid that you may make the same comments to other contributors.
Can you understand how irritating it is to get these comments when members commit code like that all the time ? Even Eelco does that sometimes (3fe93d2, 452afd1, 81e530a) even though not all the time, and sometimes alternating style in the same commit (497c828). From his coding style, I am not even sure he knows about the above POSIX rules around export.
I understand that you may be annoyed, but it should no be at the expense of random contributors that just happen not to have direct commit access. If you want this to change, please make it a general discussion on the ML.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor things, and if nobody cares about the sudo thing, then I also don't care.
Please rebase this for staging. |
@Mic92 Rebased, and re-targeted the PR. |
ping @vcunat |
merging should be probably delayed until: #19785 (comment) |
I'm afraid I know nothing about terminfo and almost nothing about ncurses. |
It was only a reminder from side, since I do not have the permission to coordinate staging builds. |
Ah, I see what you meant. I didn't understand it only waited to be merged. (I didn't read the whole thread.) |
Isn't #19785 (comment) independent of this? My understanding is that it fixes zsh's intended magic handling of the relevant environment variables to Just Work when they're updated live, whereas this PR fixes things that lack such magic. |
yes, after realizing that, I merged this pull request. |
It isn't actually clear to me why we need to set $TERMINFO_DIRS at all. Ncurses looks in its own $out/share/terminfo by default, so it seems to me that it can find terminfo files just fine without $TERMINFO_DIRS or /etc/terminfo. Theoretically, $TERMINFO_DIRS allows people to install additional terminfo files in their own profile or in the system profile, but anybody still need that in 2017? Regarding #19785 the real question is why zsh doesn't use $ncurses/share/terminfo. A quick strace shows zsh finding terminfo files just fine when $TERMINFO_DIRS is unset:
|
Yes. Many widely used terminals come with their own terminfo, and will not gracefully degrade in its absence. I have personally been repeatedly frustrated by this issue when using urxvt and termite, for example. See discussion in #19785. |
Terminfo was bundled in the system path, but not made available via /etc/terminfo
This PR also collects all the scattered config in nixos/modules/config/terminfo.nix
This makes #19785 work for system-wide packages on NixOS.