Fedora setup package's change to PROMPT_COMMAND makes gives completely different behaviour

[Ankur Sinha]

Hi,

I'm really not sure if this is a byobu bug, or a regression in this change.

In https://bugzilla.redhat.com/show_bug.cgi?id=969429 , the maintainer changed the PROMPT_COMMAND sequence (or something!).

I use byobu with a screen backend. Initially, creating a new screen window would give me an unnamed new window, and the terminal emulator's title would be set to my pwd etc. With this change, my new window is named "user@host:pwd" and the terminal emulator just says "screen". I'm uncertain of what the actual behaviour is supposed to be. The earlier behaviour fit much better, since user@host:pwd as window name clutters up the hard status line completely (the bugzilla report has screenshots of my screen instances too).

Would you have time to please look into this and comment on what the correct PROMPT_COMMAND etc is supposed to be?

Thanks,
Ankur

[Carl-Johan (carl-johan-redhat-bugs)]

Description of problem:

If $TERM matches screen (or screen* since 2.8.64), the title escape sequence doesn't start with the correct escape codes.

Version-Release number of selected component (if applicable):

setup-2.8.57-1.fc18.noarch
screen-4.1.0-0.14.20120314git3c2946.fc18.x86_64

How reproducible:

Always.

Steps to Reproduce:
1. Start screen.
2.
3.

Actual results:

Window title is "bash".

Expected results:

Window title is "${USER}@${HOSTNAME}:${PWD/#HOME/~}".

Additional info:

Screen's escape sequence starts with "\033k", not "\033]0;".

[Ondrej (ondrej-redhat-bugs)]

Thanks for report - \033]0 is really wrong, will fix that in next update - in csh.cshrc I see \033_ ... is that wrong as well? I see it disputed e.g. in old gentoo thread - http://forums-lb.gentoo.org/viewtopic-t-334689-start-0.html and in several other discussions.

[Carl-Johan (carl-johan-redhat-bugs)]

\033_ sets the hardstatus, while \033k sets the caption, i.e. the title, on the screen windows. I'm fairly sure that captions are what we're after in this case.

[Fedora (fedora-redhat-bugs)]

setup-2.8.71-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/setup-2.8.71-1.fc19

[Fedora (fedora-redhat-bugs)]

Package setup-2.8.71-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing setup-2.8.71-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10339/setup-2.8.71-1.fc19
then log in and leave karma (feedback).

[Ankur (ankur-redhat-bugs)]

Hi,

Before this update, screen (via byobu) would start new windows with a blank name, which is what I assumed is to be done. The "user@host:$PWD" part was shown in the gnome-terminal window title, which also seems correct.

Now, all new windows start with "user@host:$PWD" and keep changing according to pwd in the hardstatusline, not the gnome-terminal title bar. This seems wrong. Also incredibly cluttered. Gnome-terminal now just says "screen".

Can you please confirm how it's supposed to work? I think the earlier behaviour made more sense really.

I'm giving negative karma to the update for the time being.

Thanks,
Warm regards,
Ankur

[Ankur (ankur-redhat-bugs)]

Created attachment 758998
Screenshot showing previous terminal visuals.

[Ankur (ankur-redhat-bugs)]

Created attachment 759005
Screenshot showing terminal visuals after package update

[Dan (dan-redhat-bugs)]

This is working as expected on mate-terminal.

[Ankur (ankur-redhat-bugs)]

Created attachment 759017
screen without byobu in xterm.

[Ankur (ankur-redhat-bugs)]

Created attachment 759018
screen without byobu in xterm after update.

It looks OK with plain screen. Is it Byobu issue then, or a terminal emulator issue? If someone can pin point where it's going weird, I can go run around file relevant bugs.

[Fedora (fedora-redhat-bugs)]

setup-2.8.71-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.

[Ankur (ankur-redhat-bugs)]

Just reopening until we figure out the issue. Will close it thereafter.

[James (james-redhat-bugs)]

I'm experiencing the same problem with screen-4.1.0-0.14.20120314git3c2946.fc19.x86_64 and setup-2.8.71-1.fc19.noarch

[Ondrej (ondrej-redhat-bugs)]

Based on the report and change, I think this change is intentional, however - it seems that not all screen users are happy with the change. If I'm not missing something, screen now behaves the same way as xterm, with different escape codes. This is imho right way. Reporter - could you please react on the complaints? I'm not really sure what's the right way.

[Carl-Johan (carl-johan-redhat-bugs)]

Sorry, I haven't tried Byobu, so I can't really comment on that. Everything works as expected here on plain Screen, i.e. captions are set to "user@host:pwd" and are also used for terminal (xterm, gnome-terminal) titles. Since Byobu is an extension of Screen, I'd suspect it's interfering somehow. Maybe by changing the termcaps or the hardstatus string?

[Steven (steven-redhat-bugs)]

Please note that F19 is no longer compatible with OpenStack's devstack script. This blocks all development of OpenStack on Fedora 19 hosts. For others that come across this bug in search ofa workaround, place the following in /etc/sysconfig/bash-prompt-screen:
printf "\033]0;%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"

For the specific issue, this change breaks the -t flag to screen and interaction with the -p flag. A reproducer is as follows:
screen -d -m -S stack -t shell -s /bin/bash
screen -r stack -X hardstatus alwayslastline '%{= .} %-Lw%{= .}%> %n%f %t*%{= .}%+Lw%< %-=%{g}(%{d}%H/%l%{g})'^

After running screen -r, the hardstatus line should display the window name (bash) but instead is displaying the full path. This breaks how screen and -t operate with another in a way I don't entirely understand.

This causes an operation like:
screen -t key bash
screen -S stack -p key -X stuff 'cd /opt/stack/keystone && /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug || touch "/opt/stack/status/stack/key.failure"^M'

to fail because screen -p cannot be used to preselect a window name if the window name keeps changing and doesn't match the actual name of the window title.

[Ondrej (ondrej-redhat-bugs)]

Steven, are you saying that OpenStack relies on the most probably wrong escape code in screen? I don't think that \033]0; is the right sequence. However, based on the response saying that this change in behaviour is not what the users expect, I'm not really sure if the current behaviour is the right one as well. Tcsh uses different one as well - as I mentioned in comment#1 - so screen prompt command handling definitely lacks consistency. It would be good to come with something what will be suitable for all users.

[Steven (steven-redhat-bugs)]

Ondrej,
Not OpenStack itself, but devstack, a tool used for OpenStack development. One thing I believe we can agree upon is that screen -t and screen -p should work with whatever PROMPT_COMMAND is used. They apparently rely on the escape codes for their functionality.

I have no idea what should be the proper escape sequences (I don't know how escape sequences work in detail). One thing that may make sense is to look at escape sequences in other distros for the screen terminal type.

[Steven (steven-redhat-bugs)]

Note for those looking for a working DevStack, the following devstack review works around the problem:

https://review.openstack.org/#/c/35071/

[Ankur Sinha (sanjay-ankur)]

https://bugzilla.redhat.com/show_bug.cgi?id=969429#c5

[Dustin Kirkland  (kirkland)]

Thanks for the report. I don't currently have access to a Fedora system, so I'm not entirely sure what's going on.

I agree with your comments in that Bugzilla thread -- your previous screenshot looks "correct", whereas the new one looks very crowded and not terribly useful.

Can you try zero'ing out your $PROMPT_COMMAND, perhaps in your ~/.bashrc?

[Ankur Sinha (sanjay-ankur)]

The $PROMPT_COMMAND variable has been changed from:

[asinha@localhost ~]$ echo $PROMPT_COMMAND
printf "\033]0;%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"

to

[asinha@localhost ~]$ echo $PROMPT_COMMAND
printf "\033k%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"

The only change seems to be in the beginning, where "\033]0;" was changed to "\033k".

Using export PROMPT_COMMAND=0 in my bashrc does give me unnamed screen windows as expected. This doesn't set the window title though, which remains "screen" in my byobu instance.

Thanks,
Ankur

[Ankur (ankur-redhat-bugs)]

(In reply to Carl-Johan Schenström from comment #2)
> \033_ sets the hardstatus, while \033k sets the caption, i.e. the title, on
> the screen windows. I'm fairly sure that captions are what we're after in
> this case.

I haven't been able to find a complete list to differentiate between 033]0; and 033k. 033]0; seems to be used to set the title of the terminal emulator window, as I found in quite a few posts:

http://mg.pov.lt/blog/bash-prompt.html
http://www.kirsle.net/blog/kirsle/set-window-title-in-bash
http://hints.macworld.com/article.php?story=20031015173932306

Using 033k sets the gnome-terminal title as:

[screen 0: user@host:pwd]

while 033]0; sets it as:

[screen 0: bash] user@host:pwd

and using a hardstatus line with 033]0; sets the hardstatus line as "bash" while keeping setting the xterm window title as user@host:pwd.

The previous behaviour seems to fit better IMO. I'm unclear on what the issue that prompted this change is. Can you please clarify?

Thanks,
Warm regards,
Ankur

[Ankur (ankur-redhat-bugs)]

(By previous, I mean using "033]0;" rather than the "033k")

[Carl-Johan (carl-johan-redhat-bugs)]

(In reply to Ankur Sinha (FranciscoD) from comment #20)

> The previous behaviour seems to fit better IMO. I'm unclear on what the
> issue that prompted this change is. Can you please clarify?

(In reply to Ankur Sinha (FranciscoD) from comment #21)
> (By previous, I mean using "033]0;" rather than the "033k")

When using split regions in Screen, having the different regions called "bash" by default isn't very helpful. Especially not when logging in to remote machines and having it constantly reset. It would seem that setting the region captions, and let Screen propagate them to the terminal window title, is more user friendly. OTOH, that seems to break some things and confuse people.

[Alexandru (alexandru-redhat-bugs)]

I want to point out that this affects other programs that use PROMPT_COMMAND such as tmux. With the new version the chosen window titles are so large that opening more than two is unwieldy. If the default needs to be changed to "033k" then so be it, but it would be nice if maybe we put a comment about it in /etc/bashrc so beginners can figure out how to revert to the previous behavior more easily.

[Fedora (fedora-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

[Jan Klepek (jan-klepek-gmail)]

this is quite tricky,

the current way is the right way,
according to screen manual, prompt_command should look like this to set name of window:
PROMPT_COMMAND='echo -n -e "\033k\033\134"'

so, what was before was incorrect. Issue here is why when screen is invoked by byobu, it stops working, when screen is invoked directly, screen title is set correctly. So what to do next?

If ~/.bashrc contains:
PROMPT_COMMAND='echo -n -e "\033k;aa\033\134"'
Byobu shows: http://hpejakle.fedorapeople.org/byobu_1.PNG
Screen shows: http://hpejakle.fedorapeople.org/screen_1.PNG

if it contains:
PROMPT_COMMAND='echo -n -e "\033]0;aa\033\134"'
Byobu shows: http://hpejakle.fedorapeople.org/byobu_2.PNG
Screen shows: http://hpejakle.fedorapeople.org/screen_2.PNG

i have marked with red mark where the "aa" is written.

[Jan (jan-redhat-bugs)]

I'm currently discussing effect of this change with byobu upstream
(ticket: 1197726, https://bugs.launchpad.net/byobu/+bug/1197726)

anyway, it looks like this change is correct and issue might be somewhere in byobu.

[Dustin Kirkland  (kirkland)]

Just to be clear, Jan, do you have a patch that solves this problem? Is it as simple as changing the line in /usr/bin/byobu that sets the PROMPT_COMMAND, or is it less straightforward than that?

[Sylvain (sylvain-redhat-bugs)]

I have to agree with comment #23. This breaks all terminal multiplexers that show multiple window titles on a single line (tmux, byobu, screen with a custom caption string). I wonder if PROMPT_COMMAND should even be set when TERM=screen*

Anyway, here's a quick workaround: sudo ln -s /usr/bin/true /etc/sysconfig/bash-prompt-screen

[Jaroslav (jaroslav-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

[Pat B (b-ubuntuone-f)]

Following the conversation at:

https://bugzilla.redhat.com/show_bug.cgi?id=969429
---------------------------------------
 Sylvain Pasche 2014-08-24 18:20:14 EDT

I have to agree with comment #23. This breaks all terminal multiplexers that show multiple window titles on a single line (tmux, byobu, screen with a custom caption string). I wonder if PROMPT_COMMAND should even be set when TERM=screen*

Anyway, here's a quick workaround:
sudo ln -s /usr/bin/true /etc/sysconfig/bash-prompt-screen
---------------------------------------

This seems to fix the window name titles getting munched on my Fedora 22 / byobu / tmux

That was really annoying, hope it works for everyone.

[Fedora (fedora-redhat-bugs)]

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Stefan (stefan-redhat-bugs)]

This is broken again in Fedora 24 because screen does not seem to set TERM to "screen" anymore. Instead, "xterm-256color" is passed through.