[gentoo-user] Bash prompt
Charles Trois
I am getting confused with profile, bashrc, etc.
The prompt string I want to use is
PS1="[\u@\h \W]\$ "
I therefore wrote it in /etc/profile (at two levels, root and non-root),
~/.bash_profile and ~/.bashrc.
If I log in as a plain user (moi), I get this:
[moi@sirrah moi]$
which is all right. But, if I log in as root, I get the basic default
bash-2.05b# .
I thought that /etc/profile should provide the default, but I was
obviously wrong. Trying to mend things, I created two files
/root/.bash_profile and /root/.bashrc, writing just PS1 in each. Now,
logging in as root, the result is
[root@sirrah root]$
which is wrong, since "$" appears in place of "#", as though my syntax
of PS1 were incorrect, but I don't see that it is.
How am I to clean up all this? I'll be grateful for all suggestions.
Charles
--
gento...@gentoo.org mailing list
Hans-Werner Hilse
On Wed, 14 Sep 2005 11:15:13 +0200
Charles Trois <charle...@wanadoo.fr> wrote:
> I am getting confused with profile, bashrc, etc.
> The prompt string I want to use is
>
> PS1="[\u@\h \W]\$ "
>
> [...]
> I thought that /etc/profile should provide the default, but I was
> obviously wrong. Trying to mend things, I created two files
> /root/.bash_profile and /root/.bashrc, writing just PS1 in each. Now,
> logging in as root, the result is
>
> [root@sirrah root]$
>
> which is wrong, since "$" appears in place of "#", as though my syntax
> of PS1 were incorrect, but I don't see that it is.
That's probably due to multi level backslash escaping. Because you
surrounded the prompt string with "", the backslash isn't surviving the
first parser run by bash. You'd need to double it or even triple it
(because the "$" may need escaping on the first level, too).
-hwh
--
gento...@gentoo.org mailing list
Holly Bostick
> Hello!
>
> I am getting confused with profile, bashrc, etc. The prompt string I
> want to use is
>
> PS1="[\u@\h \W]\$ "
>
> I therefore wrote it in /etc/profile (at two levels, root and
> non-root), ~/.bash_profile and ~/.bashrc.
>
> If I log in as a plain user (moi), I get this:
>
> [moi@sirrah moi]$
>
> which is all right. But, if I log in as root, I get the basic default
>
>
>
>
>
> bash-2.05b# .
>
> I thought that /etc/profile should provide the default, but I was
> obviously wrong. Trying to mend things, I created two files
> /root/.bash_profile and /root/.bashrc, writing just PS1 in each. Now,
> logging in as root, the result is
>
> [root@sirrah root]$
>
> which is wrong, since "$" appears in place of "#", as though my
> syntax of PS1 were incorrect, but I don't see that it is.
No, it's not incorrect, but if you wrote the exact same PS1 in the root
entry as in the user entry, perhaps you see that there's a 'literal'
dollar sign character at the end:
PS1="[\u@\h \W]\$ "
which is going to be printed as itself, as you are not using any code to
change it to the 'correct' character based on user (perhaps bash thinks
you've escaped the closing bracket, not the following "$". A space
between the bracket and the "\$" might solve this, but I've never really
got /$ to work properly. It may, however, be because of the 'login shell
issue' -- see below, but basically, if you're using su and not su -, your
UID is not changing, so the /$ is not changing either).
Now, as to /etc/profile, /.bash_profile, and /.bashrc;
OK, this is a bit complex. /etc/profile should in fact provide the
default if no other is provided (bash_profile overrides, but since if a
bash_profile is provided, as it seems to be on Gentoo, it only contains
a little scriptlet that says "look at (source) ~/.bashrc", making
~/.bashrc the
*real* override. This is how it works on my system, and this seems to be
a generally default behaviour, as I've seen it under all distros where I
tried to customize the bash prompt, as I usually do if I stick with the
distro for any length of time).
My gentoo /etc/profile says:
if [ -n "${BASH_VERSION}" ] ; then
# Newer bash ebuilds include /etc/bash/bashrc which will setup PS1
# including color. We leave out color here because not all
# terminals support it.
if [ -f /etc/bash/bashrc ] ; then
# Bash login shells run only /etc/profile
# Bash non-login shells run only /etc/bash/bashrc
# Since we want to run /etc/bash/bashrc regardless, we
source it
# from here. It is unfortunate that there is no way to do
# this *after* the user's .bash_profile runs (without
putting
# it in the user's dot-files), but it shouldn't make any
# difference.
. /etc/bash/bashrc
else
PS1='\u@\h \w \$ '
fi
else
# Setup a bland default prompt. Since this prompt should be useable
# on color and non-color terminals, as well as shells that don't
# understand sequences such as \h, don't put anything special in it.
PS1="`whoami`@`uname -n | cut -f1 -d.` \$ "
fi
So, if there's a /etc/bash/bashrc found, it is sourced under all
circumstances, but if for some reason that doesn't work (like why??) the
prompt is set at
user@host workdir appropriate_symbol_for_user_class
Fine.
If there is no /etc/bash/bashrc found (as in the case of using another
shell), I think that the prompt is set to be the same thing, but just
with different language, since as mentioned, every shell doesn't
understand bash sequences.
OK. So far so good.
So this tells us that the first thing you did 'incorrectly' was changing
/etc/profile, instead of /etc/bash/bashrc (or /etc/bashrc, if that's
where bash 2 puts it).
This fits with what I know, insofar as I know that bashrc (preferably in
~/) trumps everything, generally. So it makes sense to me that if you
don't have a .bashrc in your home, there's a default one in /etc that
basically trumps everything.
So let's look at /etc/bash/bashrc (I'm using bash 3.0). The relevant
entries would seem to be:
if ${use_color} ; then
if [[ ${EUID} == 0 ]] ; then
PS1='\[\033[01;31m\]\h \[\033[01;34m\]\W \$ \[\033[00m\]'
else
PS1='\[\033[01;32m\]\u@\h \[\033[01;34m\]\w \$ \[\033[00m\]'
fi
else
if [[ ${EUID} == 0 ]] ; then
# show root@ when we don't have colors
PS1='\u@\h \W \$ '
else
PS1='\u@\h \w \$ '
fi
fi
Fine, so if the user is root, and it's a color term, the prompt is
hostname short_path_to_workdir symbol (in this case presumably '#')
with colors, and if the user is not root, it's
user@host full_path_to_workdir symbol (in this case, presumably '$')
with colors.
If there's no color, for root it's
user@hostname short_path_to_cwd symbol
and for user
user@hostname full_path_to_cwd symbol.
I have no idea (and I have never had any idea) why, despite all these
files that set up PS1, you would ever get
bash-2.05b#
which I also hate, because it's the most uninformative prompt that is
possible. As if I give the first hairy hoot as to what version of bash
it is (rather than my cwd or the hostname, for example).
But OK. Moving on to the files in your ~/ folder (user or root).
The setup on my system (and I think this is default) was that I got a
~/.bash_profile, which sources ~/.bashrc, and a ~/.bashrc, which
contained mostly aliases, allowed for bash completion (if I uncommented
it), and set up the same boring bash prompt as the one in /etc
(user@hostname cwd symbol).
This would likely be, then, the second thing you did 'incorrectly'-- your
/root/.bash_profile does not source ~/.bashrc as it (apparently) should,
but contains a PS1 entry alone.
I basically just copied my ~/.bash_profile to /root and left it at that:
# /etc/skel/.bash_profile:
# $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/skel/.bash_profile,v
1.10 2002/11/18 19:39:22 azarah Exp $
#This file is sourced by bash when you log in interactively.
[ -f ~/.bashrc ] && . ~/.bashrc
So ~/.bashrc is king of the hill, as it is apparently meant to be, so
we'll talk about that. As I said, the default ~/.bashrc contained a
number of aliases, and because I use a lot of aliases, I worked with
~/.bashrc a lot (for both home and root). Using a lot of links (posted
below) I was able to get a nice 3-line prompt that I like. I then copied
the prompt to root's bashrc and made minor changes (the colors, mostly).
and that was fine.
Then I tackled the problem of the login shell.
You see, ~/.bashrc is only sourced when you login (to the terminal,
which, don't forget, is a virtual console). So if you're in the term as
a user, and then you su normally to root, root's bashrc is not going to
be sourced, and (among other issues) you're not going to get the right
prompt (seemingly because your UID doesn't actively change to UID 0, but
rather you remain the regular user with elevated permissions).
The solution to this is (for me, as I really like bash but am not all
that good with it as yet, so any more 'elegant' solutions are unknown to
me), is to make sure my su is always a login prompt (alias su="su -"),
so that root's bashrc is sourced when I su, so I can use root's aliases,
and get root's $PATH, since there's nothing more annoying to me than
su-ing to root and still getting a 'file not found' error because
whatever I'm trying to do is still not in my $PATH, because root's PATH
was somehow not exported by su-ing. I also added an ENV_SUPATH variable
in my ~/.bashrc, but as I understand it, this variable is deprecated (it's
going out in 4.0.9 of pam-login? anyway version 4.0.9 iirc of whatever
provides or reads /etc/login.defs which version I have not yet upgraded
to, but likely will at some point), so I felt it wise to consider setting
ENV_SUPATH a fallback setting that will continue to work until such time
as I upgrade that program to the version where it won't work anymore--
which I probably won't notice doing, all things considered-- and aliasing su
to be the main setting to work around this issue).
For reference, here's my prompt (all one line, but naturally it's going
to be wrapped by the mail client):
PS1="\n\[\033[1;35m\]\$(/bin/date +%a\ %D\
%R)\n\[\033[32m\]\w\n\[\033[1;33m\]\u@\[\033[1;37m\]\h\[\033[1;34m\]\[\033[1;33m\]
-> \[\033[0m\]"
and it looks like this on-screen:
wo 09/14/05 12:20
/usr/local/games/morrowind
user@hostname -> cd
(in color; date is magenta, cwd is green, user@ is white, host -> is
yellow, command is the traditional light gray).
if I su, the prompt remains the same:
wo 09/14/05 12:22
~
root@hostname ->
except that the date is now green (because it's OK), cwd is now yellow
(warning), and 'root@' is now red (big warning), as is the ->, so that I
have some visual clue that I'm running as root and I should be careful.
The /$ thing never worked for me, so I just got rid of it and use
another method (color) to distinguish which user is active, and replaced
the symbol with another set of symbols to distinguish the command from
the prompt.
Now, as for the links that I used to actually set up the prompt:
http://www.pages.drexel.edu/~jec43/bash.htm
http://www.linuxhelp.net/guides/bashprompt/
http://www.linuxjournal.com/node/3215/print
http://www.linuxlookup.com/html/articles/custom-prompts.html (site is
currently down due to hardware failure)
http://www.linuxselfhelp.com/howtos/Bash-Prompt/Bash-Prompt-HOWTO-2.html
http://www-128.ibm.com/developerworks/linux/library/l-tip-prompt/
http://www.linuxfocus.org/English/May2004/article335.shtml#335lfindex3
and of course you can always read man bash or the Advanced Bash
Scripting guide (emerge abs-guide) to learn more about what you can do
with bash.
Hope this helps; bash prompt setup is one of those (many?) things in
Linux that is terribly confusing until you get the hang of its internal
consistency.
Holly
--
gento...@gentoo.org mailing list
wiqd
> Hello!
>
Hi Charles,
Put this into /home/user/.profile
PS1="[\u@\h \W]$ "
and this into /root/.profile
PS1="[\u@\h \W]# "
And all should be fine.
> Charles
>
>
>
Greg
--
gento...@gentoo.org mailing list
Willie Wong
No. That's wrong.
[08:13 AM]wwong ~ $ id
uid=1001(wwong) gid=0(root) groups=0(root),6(disk),10(wheel),11(floppy),16(cron),18(audio),19(cdrom),27(video),35(games),245(locate),250(portage),408(web),440(speech),443(slocate)
[08:13 AM]wwong ~ $ su
Password:
sep wwong # id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
sep wwong #
<snip>
> So ~/.bashrc is king of the hill, as it is apparently meant to be, so
> we'll talk about that. As I said, the default ~/.bashrc contained a
> number of aliases, and because I use a lot of aliases, I worked with
> ~/.bashrc a lot (for both home and root). Using a lot of links (posted
> below) I was able to get a nice 3-line prompt that I like. I then copied
> the prompt to root's bashrc and made minor changes (the colors, mostly).
> and that was fine.
>
> Then I tackled the problem of the login shell.
>
> You see, ~/.bashrc is only sourced when you login (to the terminal,
> which, don't forget, is a virtual console). So if you're in the term as
> a user, and then you su normally to root, root's bashrc is not going to
> be sourced, and (among other issues) you're not going to get the right
> prompt (seemingly because your UID doesn't actively change to UID 0, but
> rather you remain the regular user with elevated permissions).
1. Your UID does change. See the experiment above.
2. .bashrc is sourced for ALL interactive shells. .bash_profile is
sourced ONLY for login shells. So: opening an xterm sources .bashrc.
Logging in remotely via ssh sources .bash_profile.
3. su opens an interactive shell. It DOES source .bashrc
> The solution to this is (for me, as I really like bash but am not all
> that good with it as yet, so any more 'elegant' solutions are unknown to
> me), is to make sure my su is always a login prompt (alias su="su -"),
> so that root's bashrc is sourced when I su, so I can use root's aliases,
4. "su -" would open a login shell, and thus source .bash_profile
instead of .bashrc
> and get root's $PATH, since there's nothing more annoying to me than
> su-ing to root and still getting a 'file not found' error because
> whatever I'm trying to do is still not in my $PATH, because root's PATH
> was somehow not exported by su-ing. I also added an ENV_SUPATH variable
I would say something is borked on your setup. Be default, su would
look in /etc/login.def for ENV_SUPATH and ENV_PATH for default PATHs
for superusers and users respectively. Here there's also a difference
between "su" and "su -". "su" loads ENV_SUPATH from /etc/login.def,
which by default is /sbin;/bin;/usr/sbin;/usr/bin. For "su -". because
it invokes a login shell, it should grab the path from /etc/profile,
which in turn grabs it from /etc/profile.env, which is created by
env-update from the information in /etc/env.d
--
I've got a patent pending on swallowing, oxidation, and chewing gum.
Sortir en Pantoufles: up 33 days, 15:15
--
gento...@gentoo.org mailing list
Willie Wong
Use single quotes if you want to use \$
$ is a reserved character in bash. So when using double quotes, you
need to type \\$
sep wwong # export PS1="[test]\$ "
[test]$ export PS1="[test]\\$ "
[test]# export PS1='[test]\\$ '
[test]$ export PS1='[test]\$ '
[test]#
W
--
"Dude, this is making the same approximation twice in a row. It's like a
whack-a-mole game."
~DeathMech, Some Student. P-town PHY 205
Sortir en Pantoufles: up 33 days, 15:41
--
gento...@gentoo.org mailing list
Holly Bostick
> On Wed, Sep 14, 2005 at 01:25:00PM +0200, Holly Bostick wrote:
>
>> Charles Trois schreef:
>>>
>> and get root's $PATH, since there's nothing more annoying to me
>> than su-ing to root and still getting a 'file not found' error
>> because whatever I'm trying to do is still not in my $PATH, because
>> root's PATH was somehow not exported by su-ing. I also added an
>> ENV_SUPATH variable
>
>
> I would say something is borked on your setup. Be default, su would
> look in /etc/login.def for ENV_SUPATH and ENV_PATH for default PATHs
> for superusers and users respectively. Here there's also a
> difference between "su" and "su -". "su" loads ENV_SUPATH from
> /etc/login.def, which by default is /sbin;/bin;/usr/sbin;/usr/bin.
> For "su -". because it invokes a login shell, it should grab the path
> from /etc/profile, which in turn grabs it from /etc/profile.env,
> which is created by env-update from the information in /etc/env.d
OK, you're right. I think that the problems that I was working around
may have been based in *sudo*, not su itself, which works fine (now), as
does sudo su. But when I was setting up my system with sudo (like a
month and a half ago), I had all kinds of issues, because sudo did not
seem to source anything (or at least not in the way I expected). For
example, I had some weird borked PATH (the default ENV_SUPATH as you
said above, rather than the root PATH, which I would expect from a sudo
su -) , programs opened as (sudo su) root were opening with user
colors and themes (though they worked with root privs), and that sort of
thing. It was really bizarre, so I had a bunch of bizarre workarounds to
get things to work as it seemed they should, but didn't.
Maybe I borked something back in the day. It's also possible that I was
having real issues, and an upgrade to shadow (hey!! *that's* the program
where version 4.0.9 obsoletes ENV_SUPATH!) and/or sudo solved the issues
and I just didn't notice (I did remember that I knew I was unlikely to
notice the update that was going to obsolete ENV_SUPATH, and in fact, I
wouldn't really note an update to shadow without making a note to myself
to watch out for it. Which I should probably do).
In any case, I completely forgot that sudo was involved at all, so...
sorry, and just ignore me :) . I'll be busy cleaning up my bashrcs.
anyway (now that everything looks to be working properly :) ).
Willie Wong
> OK, you're right. I think that the problems that I was working around
> may have been based in *sudo*, not su itself, which works fine (now), as
> does sudo su. But when I was setting up my system with sudo (like a
> month and a half ago), I had all kinds of issues, because sudo did not
> seem to source anything (or at least not in the way I expected). For
> example, I had some weird borked PATH (the default ENV_SUPATH as you
> said above, rather than the root PATH, which I would expect from a sudo
> su -) , programs opened as (sudo su) root were opening with user
> colors and themes (though they worked with root privs), and that sort of
> thing. It was really bizarre, so I had a bunch of bizarre workarounds to
> get things to work as it seemed they should, but didn't.
right. sudo doesn't start a sub-shell. It executes commands with
escalated privileges. On the other hand, you *can* start sudo with
sudo -i
which, at least according to the manpage, would start a login shell
and set all the env variables. What I am not sure is whether sudo -i
asks you for the root password or the sudo password....
W
--
Tried to play my shoehorn... all I got was footnotes!
Sortir en Pantoufles: up 33 days, 19:10
--
gento...@gentoo.org mailing list