Why .bashrc is executed iff none of .bash_profile (or similar) exist?

[Kenny McCormack]

I understand this to be true - and it is probably documented somewhere
(though I could not find it) - but I am wondering what the logic behind it
is.

Basically, if you put stuff in .bashrc - then logout and back in again,
that stuff will not be executed (the file is just ignored) if any of the
following files exist:

1) .profile
2) .bash_profile
3) .bash_login

Is there any good reason for this?

--
"There's no chance that the iPhone is going to get any significant market share. No chance." - Steve Ballmer

[Kaz Kylheku]

On 2014-06-17, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> I understand this to be true - and it is probably documented somewhere
> (though I could not find it) - but I am wondering what the logic behind it
> is.
>
> Basically, if you put stuff in .bashrc - then logout and back in again,
> that stuff will not be executed (the file is just ignored) if any of the
> following files exist:
>
> 1) .profile
> 2) .bash_profile
> 3) .bash_login
>
> Is there any good reason for this?

This is documented behavior. When bash is started as a login shell, it
doesn't read the bashrc file.

Incidentally, here is another possible scenario.

--norc Do not read and execute the system wide initialization file
/etc/bash.bashrc and the personal initialization file ~/.bashrc
if the shell is interactive. This option is on by default if
the shell is invoked as sh.

Anyway, a good reason for a login bash not to read ~/.bashrc is that the
commands in bashrc may depend on content that needs to be set up by your
profile scripts!

I think the purpose is to that you have maximum control in your login
script at login time: you can place the call to load ~/.bashrc into that
script, whereever you want, allowing yhou to define some things before
~/.bashrc, and then to execute some things which depend material from
~/.bashrc.

[Eric]

On 2014-06-17, Kenny McCormack <gaz...@shell.xmission.com> wrote:

> I understand this to be true - and it is probably documented somewhere
> (though I could not find it) - but I am wondering what the logic behind it
> is.
>
> Basically, if you put stuff in .bashrc - then logout and back in again,
> that stuff will not be executed (the file is just ignored) if any of the
> following files exist:
>
> 1) .profile
> 2) .bash_profile
> 3) .bash_login
>
> Is there any good reason for this?

The whole startup behaviour is carefully documented in the INVOCATION
section of the bash manpage. It allows you to have different properties
for shells in different circumstances. It is also extremely common to
source .bashrc in whichever of the above three files actually gets read,
but that doesn't leave you with anything unique to interactive non-login
shells.

Eric
--
ms fnd in a lbry

[Keith Keller]

On 2014-06-17, Kaz Kylheku <k...@kylheku.com> wrote:
> On 2014-06-17, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> I understand this to be true - and it is probably documented somewhere
>> (though I could not find it) - but I am wondering what the logic behind it
>> is.
>>
>> Basically, if you put stuff in .bashrc - then logout and back in again,
>> that stuff will not be executed (the file is just ignored) if any of the
>> following files exist:
>>
>> 1) .profile
>> 2) .bash_profile
>> 3) .bash_login
>>
>> Is there any good reason for this?
>
> This is documented behavior. When bash is started as a login shell, it
> doesn't read the bashrc file.

To be very clear, what Kenny writes above is *not* true. .bashrc is
*never* executed on login (unless you explicitly source it in a login
script), even if none of the three above files exist. As another poster
noted, the behavior is in the INVOCATION section of man bash.

--keith




--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

[Kenny McCormack]

In article <i8m67bx...@goaway.wombat.san-francisco.ca.us>,
Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
...

>To be very clear, what Kenny writes above is *not* true. .bashrc is
>*never* executed on login (unless you explicitly source it in a login
>script), even if none of the three above files exist.

Not the case in my experience.

If I have none of those 3 files present, .bashrc is executed.

Just the way it is...

--
Watching ConservaLoons playing with statistics and facts is like watching a
newborn play with a computer. Endlessly amusing, but totally unproductive.

[Eric]

On 2014-06-17, Kenny McCormack <gaz...@shell.xmission.com> wrote:

> In article <i8m67bx...@goaway.wombat.san-francisco.ca.us>,
> Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
> ...
>>To be very clear, what Kenny writes above is *not* true. .bashrc is
>>*never* executed on login (unless you explicitly source it in a login
>>script), even if none of the three above files exist.
>
> Not the case in my experience.
>
> If I have none of those 3 files present, .bashrc is executed.
>
> Just the way it is...

Do you have an /etc/profile, and if so what does it contain?

[Keith Keller]

On 2014-06-17, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>

> Not the case in my experience.
>
> If I have none of those 3 files present, .bashrc is executed.

Then it's being sourced by a global profile script.

> Just the way it is...

No it's not.

[Kaz Kylheku]

On 2014-06-18, Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
> On 2014-06-17, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>
>> Not the case in my experience.
>>
>> If I have none of those 3 files present, .bashrc is executed.
>
> Then it's being sourced by a global profile script.

That doesn't easily explain why it is suppressed when Kenny does have the
per-user profiles, because Bash tries the global /etc/profile first, then those
(so any action done by the global profile would be done regardless of whether
the local profiles are done, unles the global profile checks whether the local
ones exist and modifies its behavior.)

[Eric]

Well, distros sometimes get over-complicated in files like /etc/profile,
so I wouldn't be suprised - especially if it's in something called by
/etc/profile.

Also possibly relevant is the evidence being checked for the use or
otherwise of .bashrc .

[Kenny McCormack]

In article <slrnlq2f5...@teckel.deptj.eu>, Eric <er...@deptj.eu> wrote:
...

>Well, distros sometimes get over-complicated in files like /etc/profile,
>so I wouldn't be suprised - especially if it's in something called by
>/etc/profile.

It is a mistake to rely too much upon documentation to the exclusion of
observance of the real world.

You guys remind me of those people you periodically read about who drive
their cars off cliffs because their GPSes told them to do it.

--
For instance, Standard C says that nearly all extensions to C are prohibited. How
silly! GCC implements many extensions, some of which were later adopted as part of
the standard. If you want these constructs to give an error message as
“required” by the standard, you must specify ‘--pedantic’, which was
implemented only so that we can say “GCC is a 100% implementation of the
standard”, not because there is any reason to actually use it.

[Eric]

On 2014-06-18, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <slrnlq2f5...@teckel.deptj.eu>, Eric <er...@deptj.eu> wrote:
> ...
>>Well, distros sometimes get over-complicated in files like /etc/profile,
>>so I wouldn't be suprised - especially if it's in something called by
>>/etc/profile.
>
> It is a mistake to rely too much upon documentation to the exclusion of
> observance of the real world.

You know what? You don't make any sense at all. What you just wrote
there is nothing to do with my sentence which you quoted and which is
purely derived from "observance of the real world".

In your original post you said "... is probably documented somewhere
(though I could not find it)", so I told you where. I understood that
you wanted reasons but they're a lot easier to work out when you know
exactly what is supposed to happen.

> You guys remind me of those people you periodically read about who drive
> their cars off cliffs because their GPSes told them to do it.

Well we shouldn't, because we're not behaving like that. There's
nothing wrong with referring to the documentation, because it is what is
supposed to happen, and any discrepancy is one or more of a code bug, a
documentation bug, and an insufficiently well-understood situation. With
appropriate translation this is also true of the GPS issue.

On the other hand, your response to a discrepancy seems to be "Just
the way it is..." which seems sort of equivalent to driving off the
cliff. You have been asked a few questions about the situation which
you do not seem to have answered. May I suggest that you

* choose a time when no-one else is likely to log in to the system

* open a root session in which you edit /etc/profile and put

set -x

at the start.

* keep that session open

* log in as yourself (or whatever user has the problem) in an environment
where you can record the output

* do the above step again with (or without, depending) one of the 3
files being present

* go back to the root session and change /etc/profile back again

Now you will be able to see what happens in which order and where the
differences are between the two cases. Then either you will understand
or you will have hard evidence of a code and/or documentation bug.

[Eric]

On 2014-06-18, Kenny McCormack <gaz...@shell.xmission.com> wrote:

8><

> It is a mistake to rely too much upon documentation to the exclusion of
> observance of the real world.
>

8><

> --
> For instance, Standard C says that nearly all extensions to C are
> prohibited. How silly! GCC implements many extensions, some of which were
> later adopted as part of the standard. If you want these constructs to
> give an error message as "required" by the standard, you must specify
> "--pedantic", which was implemented only so that we can say "GCC is a
> 100% implementation of the standard", not because there is any reason
> to actually use it.

Firstly, you put that bit below a sig separator so many people won't
even see it, and most of those who do will have to play tricks to get it
quoted in a followup message!

Secondly, it shows that you do not know what a standard is for. It's
definitely not "for" GCC, it exists to provide a careful definition
of the language which can be verified as working in a whole horde of
limited, specialised and/or weird environments. GCC's support of it and
--pedantic allow you get a lot of development done in the (relatively)
friendly GCC environment before dragging the code into the actual target
environment where you know, because it meets the standard, that it will
at least compile.

[Keith Keller]

On 2014-06-18, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>

> It is a mistake to rely too much upon documentation to the exclusion of
> observance of the real world.

I replicated exactly the scenarios described by the INVOCATION section
of the bash man page before posting, in particular moving my
.bash_profile and ensuring that .bashrc was not executed on login (and
is sourced when starting a nonlogin interactive shell). It is an even
larger mistake to assume that referring to the documentation means one
has not also observed the real world.

[Kaz Kylheku]

On 2014-06-18, Eric <er...@deptj.eu> wrote:
> On 2014-06-18, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> 8><
>> It is a mistake to rely too much upon documentation to the exclusion of
>> observance of the real world.
>>
> 8><
>> --
>> For instance, Standard C says that nearly all extensions to C are
>> prohibited. How silly! GCC implements many extensions, some of which were
>> later adopted as part of the standard. If you want these constructs to
>> give an error message as "required" by the standard, you must specify
>> "--pedantic", which was implemented only so that we can say "GCC is a
>> 100% implementation of the standard", not because there is any reason
>> to actually use it.
>
> Firstly, you put that bit below a sig separator so many people won't
> even see it, and most of those who do will have to play tricks to get it
> quoted in a followup message!

It's below a sig separator because it's a sig, doh?

It has appeared in prior Kenny articles.

> Secondly, it shows that you do not know what a standard is for. It's

If so, it shows that the author does not know what a standard is for;
that author ("you") is not Kenny:

http://www.gnu.org/prep/standards/html_node/Non_002dGNU-Standards.html

That is where Kenny cribbed the text for his quote. See the fourth
paragraph.

The only name on this document is "Free Software Foundation", not any
specific person.

> definitely not "for" GCC, it exists to provide a careful definition
> of the language which can be verified as working in a whole horde of
> limited, specialised and/or weird environments. GCC's support of it and
> --pedantic allow you get a lot of development done in the (relatively)

--pedantic hardly promotes development productivity in any way; most of the
diagnostics are a waste of time. This is why they are "farmed out" under
--pedantic.

It is much more useful to select individual diagnostics, and turn them
into errors, e.g. -Werror=<name-of-warning>

For instance, if I have string literals longer than 512 characters, but
coding to C90, I don't need to be reminded of this each time I type "make".

[Eric]

On 2014-06-18, Kaz Kylheku <k...@kylheku.com> wrote:

OK. But quote from elsewhere or not, it seemed to be a deliberate choice
as relevant to, and a comment on, the conversation.

>
>> definitely not "for" GCC, it exists to provide a careful definition
>> of the language which can be verified as working in a whole horde of
>> limited, specialised and/or weird environments. GCC's support of it and
>> --pedantic allow you get a lot of development done in the (relatively)
>
> --pedantic hardly promotes development productivity in any way; most of the
> diagnostics are a waste of time. This is why they are "farmed out" under
> --pedantic.
>
> It is much more useful to select individual diagnostics, and turn them
> into errors, e.g. -Werror=<name-of-warning>
>
> For instance, if I have string literals longer than 512 characters, but
> coding to C90, I don't need to be reminded of this each time I type "make".

Missing the point: using -pedantic (with -std) and fixing evething that
is reported allows you to say "this program is standard C (standard
version xxx)", which is useful for the reasons I gave,