On Thu, Dec 26, 2024 at 10:56:31 +0000, Chris Green wrote:
henrik@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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)