On Tue, Sep 20, 2005 at 03:22:29AM +0200, Gurvan Huiban wrote:
> On Monday 19 September 2005 22:00, you wrote:
> > On Mon, Sep 19, 2005 at 03:41:27PM -0300, Gurvan Huiban wrote:
> > > Package: bash
> > > Version: 3.0-16
> > > Followup-For: Bug #292023
> > >
> > > Dear sir,
> > >
> > > I have just noticed that I have the same problem. No configuration file
> > > is read when a user (including root) logs in. It worked "before".
> > >
> > > Trying to "force" bash to take into accoung the config files: source
> > > .bash_profile does not work either: nothing happens, and the
> > > configuration of the shell is not updated.
> >
> > Can you send the output of ls -l on that file, as well as its
> > contents? What if you add set -x; as the first line; is there any
> > output? Could you send the result of running "set", stripped of any
> > sensitive information (also possibly don't load the shell completion
> > functions in /etc/bash_completion, by commenting out that line in
> > ~/.bashrc, if that file is getting loaded).
>
> Dear sir,
>
> I succeed in identifying the problem: it seems that the HOSTTYPE variable
> changed from i386 to i486. My .bash_profile was testing the value of this
> variable, in order to adapt the profile of the computer architecture (I am
> sorry for not having seeing that before).
>
> Changing the test solved completely the problem.
>
> I don't know if this change in the HOSTTYPE variable is a bug or a feature.
> Is
> there any reason for this? I gave a look to the changelog and the files
> in /usr/share/doc/bash, but I could not find any reference to this change.
> Maybe it would be worth adding a comment somewhere when the buit-in
> environment variables value changes.
I suspect it is ultimately because of a change in gcc. As I
understand, Debian dropped support for straight-up i386 hardware in
Sarge, for a couple reasons. Firstly, it was difficult to have gcc
produce code which would run on a real 386, which would not be
considerably slower on more recent hardware. Secondly, it is possible
to run the same software on real 386 with an emulation patch for the
kernel, which simulates the new instructions (imov or something, I
think, was the important one).
So, compiling bash with a new gcc, not meant to produce binaries for
use on a real 386, probably changes the string from i386 to i486.
> Obviously, the importance of the bug drop from important to
> minor/wishlist ("polishing").
Does the bug still apply at all? If so, I doubt it is anything that
should be fixed in bash.
--
Clear skies,
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
