Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #276034

Re: bashrc question

Show all headers | View raw

On 26.12.2024 14:03, Greg Wooledge wrote:
> 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.

Thanks for Greg and all others' help. that resolved my issue.

regards.

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

bashrc question henrik@privatembox.com - 2024-12-26 04:40 +0100
  Re: bashrc question George at Clug <Clug@goproject.info> - 2024-12-26 04:50 +0100
  Re: bashrc question Greg Wooledge <greg@wooledge.org> - 2024-12-26 05:00 +0100
    Re: bashrc question henrik@privatembox.com - 2024-12-26 09:30 +0100
      Re: bashrc question Chris Green <cl@isbd.net> - 2024-12-26 12:20 +0100
        Re: bashrc question pocket@homemail.com - 2024-12-26 14:00 +0100
        Re: bashrc question Greg Wooledge <greg@wooledge.org> - 2024-12-26 14:10 +0100
          Re: bashrc question henrik@privatembox.com - 2024-12-27 01:10 +0100
  Re: bashrc question Frank Jezzer <etphonehomefrance@gmail.com> - 2024-12-26 17:00 +0100

csiph-web