when PS1='\u:\w\$ ' and user is root, prompt is still $ under bash

Brandon Peirce brandon_peirce at hotmail.com
Sat Jun 10 17:31:25 PDT 2006


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'?





More information about the lfs-chat mailing list