bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I can't get bash-3.2.17 to process startup/login scripts to save me,


From: Bob Proulx
Subject: Re: I can't get bash-3.2.17 to process startup/login scripts to save me, please help!
Date: Thu, 16 Aug 2007 17:05:46 -0600
User-agent: Mutt/1.5.9i

SciFi wrote:
> Bob Proulx wrote:
> $ strings bash | grep profile
> noprofile
> /etc/profile
> ~/.profile
> ~/.bash_profile

That looks good at least.

> >   $ sudo chmod 0644 /etc/profile
> I *know* that!
> What I was striving for was to get at all the problems to be sure it
> is executable if need-be.  It does not hurt to be executable, bash
> shouldn't prevent sourcing just because it is executable, and so on
> and so forth.  I said I was trying to cover all the bases.

I disagree.  I think when things like that are broken it does hurt the
debug process.  Let me explain.  When simple things are seen that are
broken it means that nothing can be trusted.  It is like seeing broken
windows in a high crime neighborhood.  Fixing broken windows may not
seem valuable in the face of worse crimes but it is actually a very
important part of the cleanup process.  This does transfer over to
programming software development.

  http://en.wikipedia.org/wiki/Broken_windows

  Andrew Hunt and David Thomas use Fixing Broken Windows as a metaphor
  for avoiding software entropy in software development in their book,
  The Pragmatic Programmer.  Item 4 (of 22 tips) is Don't Live with
  Broken Windows. The term has also found its way into web-site
  development.

Therefore I believe in fixing the smaller obvious problems regardless
of the knowledge that it may not be *the* bug that is currently under
investigation.  Sorry but by "tring to cover all the bases" I think
things like this is actually detrimental and making the problem worse.

> I previously mentioned that a really big clue is that my other boxes
> don't run bash at this patch-level, they froze before May'07 I
> believe, so that gives me a clue to use in tracking down a possible
> buggy patch somehow somewhere.

If true then this would be specific to your instance of bash and in
that case would mean that you would need to debug because it won't be
in our instance of bash and we won't be able to see the problem.

> >> In meantime I am manually able to
> >> . /etc/bashrc
> >> every time I start a Terminal or xterm window, but doing this is a real
> >> pain y'know...
> > 
> > If you want /etc/bashrc to be sourced you could always source it in your
> > ~/.bashrc file.
> 
> ~sigh~
> earlier in this discussion thread I already mentioned
> ~/.bashrc is not being sourced as well.

The ~/.bashrc file is *not* supposed to be sourced by a login shell.
That it is not being sourced is correct.

> I keep re-iterating that I believe I've covered all the bases, else
> I wouldn't bother pestering ppl on this list...

What I read was that you were trying to create a login shell that
would source /etc/profile and ~/.bash_profile and that this was not
happening for you.  Sorry if that was not the case.  Sometimes you
will simply have to repeat yourself.  But that would not include
sourcing the ~/.bashrc file which does not happen for login shells.

> I'm still open for ideas.  But remember as I said I believe I've got
> all the usual bases covered.  If we need to run internal traces on
> things, I'd be much obliged for a crash course in how to test
> bash-3.2 in this manner, please.

Running strace could be interesting.  Try this command:

  strace -o /tmp/bash.strace.out -e trace=file /bin/bash -l -c 'echo hello'

Then show us the result of the bash.strace.out file.  I see things
like this here:

  open("/etc/profile", O_RDONLY)          = 3
  open("/home/bob/.bash_profile", O_RDONLY) = 3

After that it might be necessary to use the debugger to step through
the code.  But let's hope that the strace shows something useful.

Bob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]