On Thu, 8 Jun 2006 21:26:54 -0400, Andrea Reina wrote:
> Brandon wrote:
> Try something like `set | grep UID' from your root shell and confirm
that
> both UID and EUID are zero. I'm not sure that's the exact mechanism used
> by bash, but if they are right or wrong might give a clue where to start
> looking....
set | grep UID returns 0 for both the UID and EUID. I took a look at the
Bash source -- well, more like I grepped it -- and found these lines
relevant to the substitution starting at line 5490 of y.tab.c:
case '$':
t = temp = (char *)xmalloc (3);
if ((promptvars || posixly_correct) && (current_user.euid != 0))
*t++ = '\\';
*t++ = current_user.euid == 0 ? '#' : '$';
*t = '\0';
goto add_string;
I don't know c (one of the things I want to learn but haven't got
started), but I'm wondering if there's supposed to be the asterisk
before the 't ='? Most of the other case statements (for the other
prompts) don't have the asterisk before the variable.
The lines turned up by your grep are relevant, but not the end of the trail.
If the asterisks were wrong as you suggest, there would be many thousands
of people with the same problem...
Quick C lesson: The t is a pointer variable, so the 't = ... xmalloc...'
allocates a buffer to hold a string and sets t to point to the start of the
buffer. In the other assignments '*t++ =' or '*t =' the * _dereferences_ the
pointer, i.e. they store stuff in the buffer pointed to by t rather than
updating the value of t itself. (It's the ++ 'post-increment operator' that
updates t to point to the next char in the buffer.) As you can see, C is a
very compact language. I hope this compact explanation makes some sense but
this is not really the forum for learning C so I stop there.
The important line is the one that takes # or $ depending on whether
current_user.euid is zero or not. If you hope to find the problem by
searching the code, you most likely need to find out why current_user is not
initialized as you expect. But we can't even be sure that's what the problem
is without running the code in a debugger. It's just unlikely to be an
obvious bug in such a well-used program as bash.
It is more likely to be something in your environment, for example bash will
use standard C library functions (from glibc) to retrieve the user info and
all the user, group, hostname, etc. functions in glibc depend on NSS
configuration, so your problem could be a bad /etc/nsswitch.conf (I'm
guessing a bit here) or an error in /etc/passwd and nothing directly related
to bash. Try to check those files with the relevant sections of the LFS
book and run some pwck and grpck checks, for example. Do you notice
anything else strange in your your root shell related to user id's, e.g.
wrong owner in ouput of 'ls -l'?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
