[NTLUG:Discuss] Re: Debian/SuSE /etc/bash.bashrc -- WAS: SuSE Linux 103 Exam

[Chris Cox]

Bryan J. Smith wrote:
..
> But the system-wide environmental _variables_ go in /etc/profile.
> The system-wide aliases and functions go in /etc/[bash.]bashrc.

That's by Red Hat tradition and if you look you can clearly
see environment variables being set by SUSE there.

NOTHING prevents you from putting system wide variables
there at all.  Only Red Hat makes the statement
about aliases and functions and even then, it's with
regards to their bastardized /etc/bashrc file which
is NOT understood by bash but strictly by the user's
local .bashrc (which is volatile).  Red Hat is suggesting
a convention... not dictating policy.  If they wanted
to dictate policy, putting the control in the user's
~/.bashrc is not a good idea.  Red Hat is attempting
to show how you could have system wide ALIASES inside
of not only login shells but sub shells as well.  I'm
not saying it's bad.. it's just easily undone by any
user.  It's a good guideline, a good convention, but
not very good for policy enforcement.

A better solution is using the bash that SUSE and Debian
use.  There you have a /etc/bash.bashrc that can be
used to house aliases inside of sub shells... but
nothing prevents you from putting environment variables
there as well.  This is much better than assuming that
the user's .bashrc will pull in /etc/bashrc.


> 
> Again, why?  Even on SuSE, things in /etc/bash.bashrc do _not_
> get passed onto subshells.  It's not "system-wide" by design,
> that's why you don't use it for variables.

First of all... that's not true.  Environment variables
set in bash.bashrc are passed down to sub shells.
Where are on earth are you getting this information?  You
could at least verify this for yourself (though it's
easily understood without verification).

Sure, the creation of /etc/bash.bashrc was primarily
for the use of system wide aliases and functions, but
nothing precludes you from setting environment variables
there.

> 
> I might prefer Red Hat, but I keep myself abridged of _all_ the
> major differences.  I maintain login scripts that handle several
> distribution flavors and their quirks (along with Solaris and
> Irix) -- _especially_ Debian (including Xandros) _and_ SuSE.
> 
> 
>>B is VERY wrong.. but it's obvious you have Red Hat leanings.
> 
> 
> I said it was _wrong_ for SuSE, yes. 
> I eliminated "B" based on that, because it is Red Hat's equivalent.
> Or are you just agreeing with me?

B works on Red Hat only if you do not modify your ~/.bashrc...
but that file is user modifiable by design.  So you should
NOT count on /etc/bashrc as a realiable means of setting
system wide variables on Red Hat ... PERIOD.

There's a reason why SUSE and Debian have /etc/bash.bashrc.

> 
> 
>> If you look close enough you'll see why it's the wrong
>>answer even on Red Hat since it assumes the Red Hat user
>>has not modified his local ~/.bashrc.
> 
> 
> Actually, in Red Hat, the ~/.bashrc calls /etc/bashrc.
> I am _very_familar_ with how the system/user bashrc set
> works across Debian, Red Hat and SuSE.  ;-ppp
> 

I don't think you understand it nearly as well as
you claim.  I'm not trying to be mean... I'm just trying
to point out that you really need to examine this
more closely.

Don't get me wrong though... I have been known to make
some (many) mistakes.. it can get quite complicated with
the differences between "bash" and bash invoked as "sh".

> 
>>Btw.. that Red Hat behavior has changed over time, so
>>if you don't see your ~/.bashrc trying to pull in
>>/etc/bashrc.. don't fret.  You can add it if you want
>>since it is your local profile.
> 
> 
> Correct.
> 
> But I'm not even talking that.  I'm talking about the behavior
> of SuSE's /etc/bash.bashrc.
> 
> It was clear to me that the test writer _might_ have though variables set
> in /etc/bash.bashrc would be passed to subshells, but they are _not_.

Untrue.  Environment variables set there are valid for subshells as well.
There are no restrictions placed on what commands are valid there.

> 
> At the same time, I though the test writer _might_ be testing to see
> if *I* knew that they would not be, and that's why he/she _specically_
> said "environment variables" and not just "environment."

"Environment variables" is perfectly acceptable.  However, leaving
out the context of "bash" and "login" are the mistakes IMHO.
Bash does things differently a bit if invoked as "sh".  I think
a bit more detail would help, but even so, since they asked
for 2, you could make the correct assumption with regards
to the question.

Hmmm.. I took another look at what you posted... it did say
"bash"... but "login" is important in this context as well.
If it's not a login shell, the /etc/profile isn't used.

This kind of question on a Red Hat exam might also have
to include a statement about assuming all users are using
the default skeleton ~/.bashrc.

> 
> So in the end, he gave me a question that had "no best answer."

Eh... oddly enough, I agree that the question was not worded
clearly.  But I totally disagree with the items that you
thought were ambiguous.  The right answer is easily ascertained...but
I could see 50% of the class missing that one, but not for
the reason you mention.

> 
> I picked the answer that worked for variables to _all_ subshells, 
> and that was (D) /etc/SuSEconfig/profile alongside (A) /etc/profile.

D (similar to B in a Red Hat environment) should be considered
volatile since YaST could rip up the whole thing replacing any
modifications you may have made.  Arguably it's more volatile
with Red Hat's /etc/bashrc since that is changeable on a per
user basis... but still I'd consider SuSEConfig/profile to
be too volatile to use safely.

> 
> Again, the word "variables" was key.
> It shows that test exam really need a beta, at least in the US
> (if it has one in Germany).

I get the feeling that for some strange reason you feel
that an environment "variable" is not variable.  Unless marked
as read only, you are welcome to override an environment
VARIABLE in any given shell context (well... there are some
intrinsic "variables" that are always read only).

> 
> Debian works similarly as well for it's /etc/bash.bashrc.
> 
> As we discussed, Red Hat calls it /etc/bashrc, so B was wrong aswell.
> 
> 

The bash on SUSE and Debian process /etc/bash.bashrc.  The ONLY
system wide file processed by Red Hat is /etc/profile.  The /etc/bashrc
is pulled in through the volatile, changing, deletable, user
modifiable ~/.bashrc... and thus should NOT be considered
a safe place for system wide settings.  It simply cannot
be guaranteed to work for any given user on Red Hat.  On
Red Hat you use /etc/profile for system wide environment
variable settings.  SUSE and Debian give you a better way
of handling system wide shell aliases and functions via bash.bashrc, but
again.. NOTHING, nothing, nothing prevents you from putting
environment variables there.  Red Hat does not provide
a reliable mechanism for system wide aliases/functions today
(not in RHELAS 3 anyway).  Somebody can enlighten me if
they know different.


Sorry mate...but if it's all about the "bash" question, I'm
afraid I'd have to mark it wrong as well.  If your asked for
partial credit using your current reasoning, I wouldn't
let you have it.  Your reasoning is flawed.