Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
ncl has quit [Remote host closed the connection]
ncl has joined #nix-darwin
philr_ has quit [Ping timeout: 240 seconds]
Chiliparrot has joined #nix-darwin
ncl has quit [Remote host closed the connection]
ncl has joined #nix-darwin
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Chiliparrot has joined #nix-darwin
<LambdaDuck>
How do I make the nix stuff come before the os stuff in PATH? For example, I want to use the nix version of vim and not the one that comes with macos.
<LnL>
that should happen by default AFAIK
__monty__ has joined #nix-darwin
Ericson2314 has quit [*.net *.split]
ncl has quit [*.net *.split]
aterius1 has quit [*.net *.split]
Ericson2314 has joined #nix-darwin
ncl has joined #nix-darwin
aterius1 has joined #nix-darwin
Ericson2314 has quit [Max SendQ exceeded]
sparogy has quit [Ping timeout: 240 seconds]
aterius1 has quit [Ping timeout: 244 seconds]
qqlq has quit [Ping timeout: 244 seconds]
domenkozar[m] has quit [Ping timeout: 260 seconds]
thefloweringash has quit [Ping timeout: 240 seconds]
kaychaks_riot has quit [Ping timeout: 240 seconds]
rycee has quit [Ping timeout: 256 seconds]
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Chiliparrot has joined #nix-darwin
ChanServ has quit [shutting down]
<LambdaDuck>
This is my path: /usr/local/bin /usr/bin /bin /usr/sbin /sbin /Users/anka/.nix-profile/bin /run/current-system/sw/bin /nix/var/nix/profiles/default/bin
<LambdaDuck>
Oh, right. It works in zsh, but not in fish.
<LnL>
that definitively looks like something is prepending that after all the nix setup
<LambdaDuck>
I just have the files that darwin-nix generates in /etc/fish. I get the same result if I move away my ~/.config/fish directory
<LambdaDuck>
But it works for other users, so it's obviously a problem for my user directory. I'll keep digging in my homedir
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<LambdaDuck>
Oh, it works for non-login shells as well, even for fish. I'm not sure if other users was relevant
ChanServ has joined #nix-darwin
Chiliparrot has joined #nix-darwin
<LambdaDuck>
Yep. `sudo su anka` gives a correct PATH, but `sudo su -l anka` gives the wrong path.
<clever>
LambdaDuck: why are you using sudo and su at the same time?
<clever>
LambdaDuck: its like using a hammer between the nail and another hammer!
<clever>
`sudo -u anka -i` should be a replacement
<clever>
or `sudo -u anka bash` if you want a non-login shell
<LambdaDuck>
To not need a root password for su. Maybe that's not neccessary. It's a habit I learnt long ago
<clever>
sudo doesnt use the root pw, and can do the same thing
<LambdaDuck>
I didn't know that
<LambdaDuck>
It has needed root password on linux, so I didn't know that mac was different
<clever>
which password it needs is up to the distro and /etc/sudoers file
<clever>
the usuall setup is for sudo to ask for your current users pw
<clever>
and `sudo su` still runs sudo first, so its sudo that decides which pw, not su
<LambdaDuck>
Oh, I misread your message. Yes, sudo doesn't need root, which is why I run that first. su needs root, which is why it comes after sudo. I'm not entirely sure about the subtle differences in behaviour between the two.
<clever>
sudo runs things as root by default (`-u foo` changes who to run it as)
<clever>
`sudo -i` opens an interactive shell as the target user
<clever>
and by default, sudo will ask for your own pw, not root's
<clever>
su asks for the root pw instead
<clever>
but if either sudo or su is ran as root, it wont ask for a pw
<LambdaDuck>
Anyways, do you have any clue why login-shells are broken?
<clever>
not fully, but you can try `opensnoop` and `execsnoop` to see what programs are doing behind the scenes
<clever>
ive also found that the bash darwin ships with, doesnt support a global /etc/bashrc, so you must setup ~/.bashrc for every single user
<LnL>
that's only the case for non login (or interactive?) shells
<LnL>
like ssh host vs ssh host -- env
<clever>
LnL: which is when nix needs it most, for remote builders
<LnL>
yeah, I wish environment.d was just a thing
<LnL>
alltho we could probably use paths.d to get at least that for every case
<__monty__>
LambdaDuck: I think I have the same issue with my path. Haven't really looked into it yet. fish_trace is proving very unfruitful.
<LambdaDuck>
Yes, it's a whole lot of spam from fenv and difficult to find the actual source
<__monty__>
I'm finding it just inherits PATH from the environment I start it in.
<LambdaDuck>
But why does it work in non-login shells? And where does the starting environment come from?
<__monty__>
non-login or non-interactive? Cause my shells are all non-login.
<LambdaDuck>
Oh, I might be using the wrong term. Which is which?
<LambdaDuck>
What works for me is if I run fish in fish
<__monty__>
Login shells are like the ones in linux consoles, where you have to provide login details (which a terminal could provide for you though I think).
<__monty__>
You get the proper path with fish in fish?
<__monty__>
That's different from my case then.
<LambdaDuck>
No, I said wrong. I get the correct path when I run `sudo -u anka fish` in fish
<LambdaDuck>
I think that all terminals on mac behave like login-shells, but I may be mistaken. What is non-interactive?
<__monty__>
Ah, yep, that works for me as well. I think that clears the environment the shell is started in?
<LambdaDuck>
Makes sense.
<LambdaDuck>
However a login shell "sudo -u anka -l fish" does not work
<__monty__>
Non-interactive shells are the ones not connected to a tty I think. So `fish -c blah` would run a non-interactive shell. Most commonly GUI terminals run non-login interactive shells.
<LambdaDuck>
Ah, it seems like that doesn't clear the environment. I thought it was the opposite.
<__monty__>
Not sure what Terminal.app does though, I use kitty.
<LambdaDuck>
Scratch my last comment. The flag for making a login shell with sudo is -i and not -l.
<LambdaDuck>
If I have a correct PATH variable and then run sudo -iu anka fish I will get back an incorrect variable
<LambdaDuck>
* incorrect PATH.
<__monty__>
Ah, you're right that on OSX shells are usually login interactive. On linux they're usually non-login because X11 makes .profile available so individual shells don't need to load that again.
<LambdaDuck>
Yes. Something definetely goes wrong when making a login interactive shell with fish.
<__monty__>
Ok, one of the paths prepended to my path comes from /etc/paths.d
<__monty__>
Aha, check /etc/paths, LambdaDuck.
<LambdaDuck>
Yes, I see that. What can I do about it?
<LambdaDuck>
Or, rather, what about /etc/paths?
<LnL>
that's normal, every shell looks at that AFIAK but that all happens _before_ the system config, etc.
<LnL>
unless you run path_helper yourself somewhere
<__monty__>
/usr/libexec/path_helper is run from /etc/profile.
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<__monty__>
And I guess fish respects that if it's run as a login shell?
<LambdaDuck>
Ah, right. That's probably the problem
<LnL>
I hate how complicated and inconsistent this stuff is
<LnL>
where's that graph at again...
<LambdaDuck>
I agree
<LambdaDuck>
It doesn't seem like fish is sourcing /etc/profile
<__monty__>
Please correct me if I'm wrong. fish is started as a login interactive shell, reads /etc/profile, PATH=blah, reads /etc/fish/config.fish (not sure whether .config/fish/config.fish overrides or is loaded in addition), and fenv is used to source some environment files and... now I can't find where NIX_LINK is added to the path >.<
<__monty__>
Hmm, in the set-environment I guess?
<LnL>
so what I'd expect is that any shell either inherits paths.d from the terminal application or loads profile before it's own stuff
<LambdaDuck>
__monty__: I tried adding echo to /etc/profile and nothing is printed, so no. That part is ignored.
<LnL>
shell specific files (when configured) will load the darwin environent through set-environment ignoring anything before
<LambdaDuck>
Unless it does it sneakily.
<__monty__>
Try adding a path in /etc/paths.d instead?
<LambdaDuck>
That doesn't say anything about /etc/profile though.
<__monty__>
I'm not finding whether the set-environment is sourced anymore.
<LnL>
what happens afterwards is what can prepend (or even overwrite) PATH
<__monty__>
Well /etc/profile is the only place that could've run /usr/libexec/path_helper for me.
<LambdaDuck>
I also tried commenting out the line and got the same result.
<__monty__>
I think fenv spawns a bash to get the environment? I think that may be reading /etc/profile?
<__monty__>
Ah, so fish calls path_helper.
<__monty__>
LnL: What would you consider the best way to change the order of the PATH? Ideally, I wouldn't touch /etc/paths so other shells will still work as expected. But I would like .nix-profile/bin prepended, rather than appended.
<LnL>
no idea
<LambdaDuck>
I think the problem might be that nixos-env-preinit is sourced too early
<LambdaDuck>
running "export /nix/store/g4asvx243r1an8mw6dm0faglb25b9s6c-set-environment" works fine in the final shell, but in the context it causes errors. But maybe I misinterpreted the situation. Wait a minute.
<LnL>
I would like to use paths.d instead for everything but I don't think that can prepend before /usr/local/bin
<__monty__>
I think you're right. /etc/paths +
<__monty__>
/etc/paths.d/*, in that order it seems.
<LambdaDuck>
Oh, yes "This happens before $__fish_datadir/config.fish sets fish_function_path" that's why export is not in scope. And probably why the path_helper is run later.
<LambdaDuck>
The solution is probably to make that thing run later, but I'm not sure how.
<__monty__>
LambdaDuck: But the path_helper is run by fish, nothing nix does.
<LambdaDuck>
Yes
<LambdaDuck>
As "grep -r path_helper /nix/store/qingw75aajws050g7azcv0gg1hzjzms1-fish-3.1.2" shows
<LambdaDuck>
but "cat /etc/fish/nixos-env-preinit.fish" says that that thing is run before /nix/store/qingw75aajws050g7azcv0gg1hzjzms1-fish-3.1.2/share/fish/config.fish, which is the problem, since that contains the call to path_helper.
<LambdaDuck>
Anyways, got to go. We'll have to keep investigating later.
<__monty__>
So this is where /etc/paths things end up prepended: set -a result $existing_entry
<__monty__>
I'm not sure there's a good solution tbh. Guess I'll have to explicitly prepend.
<__monty__>
Apple *really* wanted these things to come first. Modifying /etc/paths would affect non nix-installed shells. Patching the behavior in fish for all nix-darwin users could mess up some people expecting the regular behavior so I think only explicit prepending is left?
Chiliparrot has joined #nix-darwin
<LnL>
meh, they put /usr/local/bin at the front
<LnL>
that said I do really like the idea of making shells that don't use /etc at all
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Chiliparrot has joined #nix-darwin
cransom has quit [Quit: WeeChat 2.7.1]
cransom has joined #nix-darwin
cransom has quit [Quit: WeeChat 2.7.1]
__monty__ has quit [Quit: leaving]
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Chiliparrot has joined #nix-darwin
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]