@b0rkJulia Evans I used to think the same: that the login shell is the outermost one, so you can put settings in there just once and have the inner shells inherit them.

But then, when I started using the feature of SSH that runs multiple terminal sessions over the same encrypted network connection, I was surprised to find that opensshd defaults to making the first one a login shell, and subsequent ones not, even though the subsequent shells _aren't_ nested within the first one – the shell sessions are independent. So if I defined any important environment variables only in login shells, they'd be missing in those secondary terminal sessions over SSH.

My best guess is that the OpenSSH policy is based on the idea that the extra login-shell setup is about _printing_ stuff, not _setting_ stuff. Something like: the first time you log in to a machine, maybe it wants to print the contents of /etc/motd in case the sysadmin has any important announcements about downtime, and maybe you have your own script to print your list of meetings for the day, or what have you. You want to see that kind of infodump every so often (goes the theory), but not every single time you start a shell.

But I don't want to say you're _wrong_. I think it's more like: people have historically disagreed about what login shells are for, so now it's a confused mishmash that doesn't consistently do what _anyone_ wants :-/