On Thu, Dec 26, 2024 at 10:56:31 +0000, Chris Green wrote: > hen...@privatembox.com wrote: > > > > So, since I am using a login shell, and I have .bashrc created. thus I > > have to create a .profile to include .bashrc? Am I right? > > > Yes, I think that's the right way round.
Agreed. Even if you just put in a single line to dot in ~/.bashrc it should be sufficient. > Make sure you **don't** have either ~/.bash_profile or ~/.bash_login > as these will be used instead of ~/.profile if they exist. Aye. > Note that (according to my understanding anyway) .bashrc should be > used for settings that are needed for interactive shells whereas > .profile is used for settings that are used by all programs not just > interactive ones. For a user who only connects via ssh, a traditional model will work. Configure .profile to set up your environment variables, umask, resource limits, and so forth. Anything that can be inherited goes in .profile. Have .profile dot in .bashrc, and put all your non-inheritable shell settings (set, shopt, alias, function) in .bashrc. That's how it was designed to work originally, and that's the model that ssh gives you. If that's all you want to hear, you can stop there. For a long ranting explanation, read on. In the original Unix workflow models, you would come to work, sit down at your desk, turn on your terminal, and log in. This would run a login shell, which would read your ~/.profile, and set up your environment. You could also do one-time jobs (show me today's calendar, big news items, etc.) that you wouldn't want to do every time you launch another shell. What other shells? Well, you might be editing a document, and decide that you need to look something up, so you do a shell escape. This launches a NON-login shell, which is a child of your editor, which is a child of your login shell. You wouldn't want the new shell to show you the daily calendar again, because you've already seen it. Likewise, you don't need the new shell to export your environment variables, because you already have them. They were inherited from the login shell. Or, you might be using a terminal multiplexer like GNU screen, which lets you open multiple virtual terminals on your single physical terminal. Each of those virtual terminals will inherit your environment so they don't all need to re-export your variables, or show you the big news items. That would just be a waste of resources. Or, you might be a little farther into the future, and using an X terminal, which has a big fancy monitor and a mouse and can draw lots of windows. In this kind of environment, you might open several terminal windows simultaneously, and each one will run a non-login shell, because your environment is inherited from your Window Manager application, which launches the X terminals, which in turn launch the shells. But things changed over time. Unix started becoming widespread in universities, where students would encounter it for the first time, and have no idea how everything is set up, and how the different processes work together. A young student might edit their ~/.profile equivalent (probably ~/.login back then because they were likely using csh), and then wonder why it had no effect on their session. The answer, of course, was that changes to .profile or .login only take place when you log in, so you'd have to log out and back in to get the changes. Students didn't like that. They wanted everything to work immediately! And what was that other file even for, .cshrc? What was that? So, for whatever reason, what started happening was university environments would be set up so that all terminals launched login shells by default. Thus, students could modify their .login files, never even TOUCH their .cshrc files, and every time they would launch a new terminal, they would get their new settings. It was as inefficient as possible, but it was simple. A whole generation of students therefore had their first exposure to Unix in an environment where all shells were login shells. Fast forward another generation, and we have the current crop of abominations like GNOME, where nothing is inherited properly from any discernable parent process, and nothing is user-configurable at all. All terminals are children of a generic system daemon that you cannot configure, and inherit nothing whatsoever. In such an environment, you're all but forced to configure all terminals to run login shells, so that they can fully initialize their own environments ab initio. So... what should you, the reader, do? It all depends on your environment. How you login matters. What kind of Desktop Environment you run, if any, matters. There are no longer any consistent rules or policies.
