Byobu overwrites shell prompt setting

Hi there, thanks for the report.

I just verified in the source code, Byobu doesn't modify PS1 at all, anywhere in its source code.

What do you get if you just run screen (without byobu)?

Also, can you try putting your PS1 definition into your ~/.bashrc ?

With just screen, it's working fine.

If I put PS1 into ~/.bashrc, it is working too.

Any you able to reproduce the problem?

How are you launching byobu?

By typing the command 'byobu' or launching automatically on login?

By typing the command 'byobu'

And once you're in there, what happens if you source your profile with:

. ~/.profile

I take it that you mean ~/.bash_profile? If I source that file, it sets the prompt correctly.

Okay, from the bash manpage, it says:

       When bash is invoked as an interactive login shell, or as a
non-interactive shell with the --login option, it first reads and
executes commands from the file /etc/profile, if that file exists.
       After reading that file, it looks for ~/.bash_profile,
~/.bash_login, and ~/.profile, in that order, and reads and executes
commands from the first one that exists and is readable. The
--noprofile option may be used when the shell is started to inhibit
this behavior.

Can you confirm that you only have one of these 3 files?

Almost:

[0] inspiron:~$ cat .bashrc
cat: .bashrc: No such file or directory
[1] inspiron:~$ cat .bash_login
cat: .bash_login: No such file or directory
[1] inspiron:~$ cat .bash_profile
#
# ~/.bash_profile (executed by bash(1))
# Settings for interactive login shells
#

# include settings for noninteractive logins
if [ -f ~/.profile ]; then
    source ~/.profile
fi

# include settings for subshells
if [ -f ~/.bashrc ]; then
    source ~/.bashrc
fi

export PS1='\[\e[1m\][$?] \h:\w$\[\e[22m\] '
export EDITOR=vim
export VISUAL=vim
export PAGER=less

[0] inspiron:~$ cat .profile
#
# ~/.profile (executed by bash(1))
# Settings for interactive logins (e.g. GDM)
#

export TEXMFHOME=~/lib/texmf
export PYTHONSTARTUP=~/.pythonrc.py
export EC2_PRIVATE_KEY=~/lib/aws-x509-key.pem
export EC2_CERT=~/lib/aws-x509-cert.pem

Okay, and which set of those environment variables are present in your
environment? All of them? Or just some of them?

All of the variables are present in both the "normal" and the screen session. Except for PS1, of course.

/me is baffled.

I'll have to keep looking

Apart from being baffled ;-), can you reproduce this? Just curious...

This bug affects me also, system is running an older CentOS.
I noticed it in byobu 3.1 (and still affects 3.3) which was a configure && make && make install job of the release tarball.
Like the submitter, I run this as "byobu" from the shell, and only PS1 seems to be affected.
It didn't happen in byobu 2.82 from the "other systems build" download on the ppa site (which was the pre-built version which ran as "screen" and overwrote ~/.screenrc to load byobu settings instead)

Its a tad annoying to have to "grep PS1 ~/.bash_profile" and cut & paste that line in for every opened window.

I'm wondering if something in the CentOS build of bash or screen or rxvt is doing something stupid, as I've checked out byobu
(grepping for 'exec' 'env' 'set' 'prompt' and 'ps1') and its consistently running os.execv (so not overwriting the environment) or otherwise messing with PS1.

Marking confirmed, since Matthew is seeing this as well.

Right, so whatever is causing this, it's happening indirectly, as byobu doesn't directly mangle PS1. Not to say it's not happening -- I believe it is, I just haven't figured out why/how.

What is your desired value of PS1? Paste that here and I'll play with it.

Thanks.

Another question ... What if you move your "export PS1=..." to ~/.bashrc instead of ~/.bash_profile? Any difference?

Also, what if you do:
 byobu bash --login

I am on a different computer now (but with the same home directory!) and I'm not able to produce the problem here. I will have access to the original machine in a couple of weeks again.

Hi Dustin,

I'm just using the power prompt from here: http://www.askapache.com/linux-unix/bash-power-prompt.html
Running "byobu bash --login" gives me one window where everything is fine, subsequent windows opened (ctrl-a c) still exhibit the unwanted behaviour (I guess this indicates PS1 is gone before screen runs)

exporting PS1 in ~/.bashrc works around the problem since that's sourced by every bash instance.

The environment in the rxvt terminal where I run 'byobu' has the correct PS1 so its only after running byobu that its messed with - and like you I can't see where exactly in the byobu sources this is!

I just noticed byobu-janitor creates a blank ~/.screenrc - could it be that people who don't see this issue have "deflogin on" in the screen config, and those who experience this issue don't (because of a blank ~/.screenrc and nothing in byobu setting it on) ?

My above findings are making more sense, byobu launches screen using the -c switch, which overrides both /etc/screenrc and ~/.screenrc loading /usr/local/share/byobu/profiles/byoburc instead. This sources ~/.screenrc (which was created by byobu-janitor and is blank) but not /etc/screenrc - /etc/screenrc sets deflogin on

Previously, using the pre-built byobu 2.82 I ran as "screen" from the command-line, which sources both /etc/screenrc and ~/.screenrc (the ~/.screenrc sourced the byobu profile) & everything works.

Now that I built byobu from source, byobu is run as "byobu" not "screen", using the cutom byobu profile which never sets deflogin on.

There's a few ways to fix this, either byobu-janitor creates a ~/.screenrc that sets deflogin on, or the default system byoburc does it, or the ~/.byobu/profile does it ...

I haven't noticed this issue at home, however I'm also running Ubuntu and use the zsh shell there. Don't have either privilege here at work :(

Dammit.. setting that on isn't resolving this.
Whiskey Tango Foxtrot.

I can use "shell -$SHELL" in the screenrc to also resolve this (tested, works) which is also working around the fact that PS1 is being erased by something.

Hi Matthew,

Sorry I've missed your comments here until now :-(

I still would like to solve this bug...

Per your comments in #20, could this be solved by having byobu explicitly source /etc/screenrc *first*?

Hmm, actually, strike my question in #23. See Bug #328365. screen sources /etc/screenrc itself automatically. I just tested that, and that's accurate.

Okay, I'm going to explicitly set deflogin on in /usr/share/byobu/profiles/common.

Can you give the next release a try and let me know?

Also, can you give me a very explicit set of testing instructions? Thanks!!

This bug was fixed in the package byobu - 3.26-0ubuntu1

---------------
byobu (3.26-0ubuntu1) natty; urgency=low

  [ Dustin Kirkland ]
  * usr/bin/byobu-reconnect-sockets, usr/lib/byobu/date,
    usr/share/byobu/keybindings/f-keys,
    usr/share/byobu/keybindings/screen-escape-keys:
    - add a ctrl-f5 keybinding for reconnecting sockets
  * usr/share/byobu/profiles/common: explicitly set deflogin on,
    LP: #525552

  [ swalker <email address hidden> ]
  * A set of fixes for LP: #700911
  * usr/bin/byobu-status, usr/bin/byobu-status-detail:
    - improve support for byobu-status-detail on systems without vim
  * usr/lib/byobu/mail: test for mail dir, avoids errors
  * usr/lib/byobu/reboot_required: test for file existence, avoids errors

  [ Dustin Kirkland + swalker <email address hidden> ]
  * usr/lib/byobu/wifi_quality: avoid potential divide by zero error
  * usr/lib/byobu/fan_speed: add support for /proc/i8k for some other
    systems' fan speeds (e.g. Dell Inspiron), LP: #700204
 -- Dustin Kirkland <email address hidden> Sun, 23 Jan 2011 16:28:45 -0600

I can confirm this on CentOS 5.5. I have compiled byobu 3.27 from source. deflogin is set to on but still PS1 is lost within byobu. all goes well when running just screen. moving PS1 from .profile to .bashrc fix the issue though.

Reopening this bug per the last comment. Bummer.

I think the next step, then, is to go through ~/.byobu/profile commenting out each line starting at the end, working your way backwards, until we find the screen configuration setting that's breaking this in Byobu, but allowing it to work in Screen.

Thanks, Igor. For now, I'm going to document your workaround in the byobu.1 manpage.

Thanks!

This bug was fixed in the package byobu - 3.29-0ubuntu1

---------------
byobu (3.29-0ubuntu1) natty; urgency=low

  [ Dustin Kirkland ]
  * usr/share/man/man1/byobu.1: document PS1 workaround, LP: #525552
  * usr/share/man/man1/byobu.1: fix minor manpage typo, add SERVICES example
  * usr/lib/byobu/wifi_quality, usr/share/man/man1/byobu.1: support overriding
    the default wireless interface, LP: #723260
  * usr/share/man/man1/byobu.1: document TERM=vt100 for Mac keyboard users,
    LP: #482623
  * usr/bin/byobu-janitor: use readlink, much more graceful
  * usr/lib/byobu/time_binary, usr/share/byobu/profiles/common,
    usr/share/man/man1/byobu.1: fixup a couple of minor issues with the binary
    clock commit
  * usr/bin/byobu-status: switch the interpreter from sh to bash; this is
    needed to support James' time_binary script, which is bash and cannot be
    simply sourced by byobu-status; if significant performance regressions
    occur, we will need to back this change out and approach it a different
    way

  [ James Hunt ]
  * etc/byobu/statusrc, usr/bin/byobu-config, usr/lib/byobu/time_binary,
    usr/share/byobu/profiles/common, usr/share/man/man1/byobu.1:
    - add support for the super-geeky-but-fun binary clock; requires
      UTF8 support in GNU Screen, LP: #705037

  [ Chow Loong Jin and Dustin Kirkland ]
  * usr/lib/byobu/disk_io: canonicalize symlinks so that disk_io works
    with raid, lvm, dm volumes, LP: #709224, #711373, #723187
 -- Dustin Kirkland <email address hidden> Wed, 23 Feb 2011 16:24:38 -0600

The bug was about byobu not reading PS1's formatting in ~/.bash_profile. The fix apparently goes along "so just do not specify it there", which I would not go as far to call it a fix.

My fix, if you can also call it that, is, instead, going to Menu > Create new windows > Command: /bin/bash --login, and tick "add to default windows" (the only one I have). Cannot tell for other shells since I just know bash.

`echo "shell -/bin/bash" >> $HOME/.screenrc` will solve your problem by invoking the bash as login shell

see `man 1 screen`, and search for `shell command` can find the answer.

I'm using byobu-tmux with bash and .bash_profile is not sourced at all so I'm missing my alias, functions, environment variables and even bash-completion doesn't work. To enable profile sourcing, login mode for the shell has to be used.

As far as I can gather, login mode is disabled on purpose. I don't know the reason for it though (maybe so that random stuff from profiles wouldn't get sourced), but it should provide at least a setting to chose whether to use login shell.

There are two places where new shell is started when launching byobu:
1) /usr/bin/byobu-shell does exec "$SHELL"
2) /usr/share/byobu/profiles/tmux does set -g default-command $SHELL

Tmux by default starts login shell, but it is explicitly disabled in /usr/share/byobu/profiles/tmux for byobu by setting default-command. A workaround is to comment out that line. I didn't manage to figure out how to unset default-command from user profile.

Seems like most shells support -l | --login flag, so that also can be used to start login shell:
1) /usr/bin/byobu-shell: exec "$SHELL" --login
2) /usr/share/byobu/profiles/tmux: set -g default-command $SHELL --login

The first point is need so that initial byobu window uses login shell and the second for the subsequent windows.

Previous commenter mentioned using -$SHELL to get login shell, but that link is not installed on all distros, so I think the flag is the best option.

I can confirm that this affects me as well with byoby 5.21-5.

I tried to edit the two places readan2 mentioned on Ubuntu 13.10, but that just caused byobu to immediately exit on start :( I need a login shell to get RVM to work.

I too can confirm that this is still present.

I also see this behavior with byobu 5.60-0ubuntu1 on Ubuntu 13.10.

I can run byobu manually or automatically at login (using byobu-enable) but the aliases and functions I have in a /etc/profile.d/lxc-helpers.sh script aren't available to me.

Interestingly, when I run tmux it does have my profile (aliases and funtions) available.

As a workaround for byobu I just append the following to my ~/.bashrc file to re-source the profile which gets everything working as expected.

. /etc/profile

+1 for the workarounds from @readan2 in #33. Using a mbp5,3 on OSX 10.9.1, with byobu and tmux from homebrew. I don't understand the reasons for wanting to avoid a login shell, but I can report that adding "--login" in the three places shown below gets my $PS1 back the way it's supposed to be.
  1) /usr/local/bin/byobu-shell: exec "$SHELL" --login || exec /bin/sh --login
  2) /usr/local/share/byobu/profiles/tmux: set -g default-command $SHELL --login

A separate, unrelated point, is that homebrew does not ship the python snack module in its libnewt, so byobu-config does not work. :(

+1 for @readan2

I've been trying to make byobu+screen automatically start a login shell for months (i know that sounds pathetic), and this workaround adequately solves this for me. In order to utilize my ruby on rails environment I must be logged into a login shell which required me to do bash -l, /bin/bash --login, etc. every time I opened my ssh connection. To clarify this workaround however,

With my distro, in /usr/local/bin/byobu-shell there is a line that looks like this:
[ -n "$SHELL" -a -x "$SHELL" ] && exec "$SHELL" || exec /bin/bash

I changed it to look like this:
[ -n "$SHELL" -a -x "$SHELL" ] && exec "$SHELL" --login || exec /bin/bash --login

just in case anyone wasn't sure how to implement @readan2's instructions, doing this worked for me.

I also inserted this just before the 3 present commands in /usr/share/byobu/profiles/screenrc (assuming it would work the same as with tmux). I also didn't test after the first modification so this may or may not be necessary, but after doing these two things I no longer need to run /bin/bash --login.:
set -g default-command $SHELL --login

thanks @readan2 for the working solution. WHY COULDN'T I FIND YOU WEEKS AGO??

Hi

you probably have a

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm|xterm-color|*-256color) color_prompt=yes;;
esac

in your .bashrc

and the default TERM for byobu is "screen" (for me)

So
1) add force_color_prompt=yes in your bashrc
or
2) add "screen" (or tmux depending what return "echo $TERM) in the case

Hello,

Getting color changing here too, after runing byobu at ubuntu server 4.4.0.

Just doing

nano .bashrc
ctrl-x

gets back to the previous prompt colors before issuing byobu.

Please notice nothing was really changed at .bashrc, just opened with nano.

I was also affected by issue.

But thanks to thread, I found how to disable PS1 changing by byobu.

Default bash.rc enables byobu colorizing if it exists:

[ -r /home/bhs/.byobu/prompt ] && . /home/bhs/.byobu/prompt #byobu-prompt#

If line is commented, PS1 remains identical to what's set by bash of user's .bashrc setting.

Personally, I feel byobu's authors tried to make prompt better but terminal program limitations might be screwing it up :(.