-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
darwin-installer: work around zshrc overwrites #9243
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -216,3 +216,7 @@ poly_create_build_user() { | |
poly_prepare_to_install() { | ||
: | ||
} | ||
|
||
poly_extra_init_for_zshenv() { | ||
: | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,7 @@ | ||
# Only execute this file once per shell. | ||
if [ -n "${__ETC_PROFILE_NIX_SOURCED:-}" ]; then return; fi | ||
export __ETC_PROFILE_NIX_SOURCED=1 | ||
|
||
if [ -n "$HOME" ] && [ -n "$USER" ]; then | ||
|
||
# Set up the per-user profile. | ||
|
@@ -51,9 +55,24 @@ if [ -n "$HOME" ] && [ -n "$USER" ]; then | |
# pick up `.nix-profile/share/man` because is it close to `.nix-profile/bin` | ||
# which is in the $PATH. For more info, run `manpath -d`. | ||
if [ -n "${MANPATH-}" ]; then | ||
export MANPATH="$NIX_LINK/share/man:$MANPATH" | ||
# only append once | ||
case ":$MANPATH:" in | ||
*:"$NIX_LINK/share/man":*) | ||
;; | ||
*) | ||
export MANPATH="$NIX_LINK/share/man:$MANPATH" | ||
;; | ||
esac | ||
fi | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure how well this will work. When I run
And get empty output in Terminal. This is in a session where both the default and my user profile have been sourced and man can access manpages installed by nix. Running
But the environment variable is still empty. Very strange. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think what you're observing here is that the block will only operate if MANPATH is already set when the shell hook runs, because it's guarded with: if [ -n "${MANPATH-}" ]; then This doesn't sound like a problem, though I'm less certain about whether a knock-on implication of your observation and this change would be a problem: Moving Nix's shell hook from /etc/zshrc to /etc/zshenv does move it up in the execution order, which in turn comes with some risk of shifting behavior for any users that explicitly set MANPATH before the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm that seems to only be a problem if the order of paths in PATH and MANPATH differs. In that case, you could hit a situation where by order of PATH, you execute one version of a program, but by order of MANPATH, the manpage of a different version would be shown. On macOS in particular, the highest disruption around this would probably be related to coreutils, where the BSD versions are used instead of the GNU versions, and git, where Apple provides their own fork that interacts well with the macOS keychain. In these cases, though, they're installed system-wide, and their PATH is not mentioned in However, if PATH (or MANPATH) were to be set before the nix hook, that could indeed change the behavior. So the only situation where this change would cause an effect is if a user changed
This seems exceedingly unlikely though. Normally you customize the
I would say the positive impact of this change far outweighs the small likelyhood that this might potentially break some obscure configuration change that the next OS update would have wiped out anyway. |
||
|
||
export PATH="$NIX_LINK/bin:$PATH" | ||
# only append once | ||
case ":$PATH:" in | ||
*:"$NIX_LINK/bin":*) | ||
;; | ||
*) | ||
export PATH="$NIX_LINK/bin:$PATH" | ||
;; | ||
esac | ||
|
||
unset NIX_LINK NIX_LINK_NEW | ||
fi |
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'm a bit concerned that this is a pretty surprising way to implement this. If I came across something like this on my own I'd start from the assumption that my system was compromised ...
Is there a way this could be done in a less surprising way?
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 don't think so--and this is a good complaint.
That said, both workarounds have this property to some degree. What would you think if you weren't aware of the repair-daemon's presence, intentionally removed the Nix shell hook, and found it in place later?
Reaching a consensus decision about which is least-surprising will probably be the main task ahead here. I'm on the fence, myself :)
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.
That's a good note. I don't know :').
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.
One additional issue I'm seeing with this change is that it only fixes the issue for new installations. Existing installations have to be manually removed and then re-installed or manually fixed. Even if #7603 was merged, one could not simply re-run the installer, as that would leave the change in
/etc/zshrc
from the previous run.@grahamc AFAIU, this is not an issue for the repair-daemon; you can just run the installer again and an existing installation will receive the fix, correct?