Environment variables are difficult.
We spend insane amounts of time in our life troubleshooting environment variable induced issues, and I’ve come to realize that even seasoned GNU/Linux users are unclear about how variables propagate, let alone .profile vs. .bashrc.
(Comment comes from seeing people confused when using Guix and similar tools. Very few know in which shell startup file env var definitions “should” go; even fewer know what ‘hash’ does.)
@civodul dynamic scope considered harmful
@civodul this is why reimplementing Guix on Plan 9 with overlays instead of environment variable magic is on my TODO list.
the only reason we need path variables is because Linux doesn't have nice usable overlays. and everyone reimplementing path lookup in different ways (eg.: Lua) is also not helping.
Environment variables are a MonadReader - a way to implicitly pass constants to whoever might be interested, without involving everyone in the middle. This is opposed to argv, which is passed explicitly, and everyone in the exec chain needs to be aware of the.
Now, PATH, LD_LIBRARY_PATH, etc. are indeed workarounds for lack of per-process namespaces and union filesystems, but you'll still need some way of passing implicit data from one process to its (grand-)*children
Of course you can imitate env vars with a tmpfs in a process''s namespace, but the upkeep would take some work - you'd need to mount a fresh tmpfs and copy all the variables every time you fork (overlayfs wouldn't do the trick, because you don't want to propagate changes from the parent)
@AbbieNormal @civodul it's like overlayfs and bind mounts on Linux, but you don't need to be root.
eg. /bin is formed at boot time by running bind -a /$cputype/bin /bin
bind -a /rc/bin /bin
and when you log in, usually your $home/lib/profile does a
bind -a $home/bin/rc /bin
bind -a $home/bin/$cputype/bin /bin
but crucially, these are only visible in your login shell's namespace. you can have as many namespaces as you like. activating a package can be as simple as bind mounting it. (well, kinda. you need a helper fs for deeper directory hierarchies, but there are good reasons for why that isn't how it works by default.)
*thunderous, sustained applause*
@civodul Can confirm on the .profile vs .bashrc issue. On newly installed accounts, one of the first things I do is arrange for .profile, .bashrc, and if needed, others to invoke a common script. (And, I can never remember when each is called.) It is exceedingly rare for me to have to differentiate between interactive vs. non-interactive log-ins.
@civodul things implicitly passed behind our backs are invisible to us. The more we allow in our computing stack the less we can reason about it. If envars bring more pain than joy then let’s banish them from the Guix realm.
@civodul did you know that it's *impossible* for a user's config to add to PATH when sshing into a host non-interactively?
only in certian bash compiles, in others .bashrc works but not .bash_profile
@joeyh Oh yes, and the idea that there are compile-time flags in Bash that change pretty fundamental behavior like this has always scared me.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!