Created attachment 47162 [details]
changes to /etc/bashrc for setting screen's hardline

fixed in 2.5.8-1

I can't reproduce the problem with screen-3.9.11-6, setup-2.5.13-3
and the above patch reverted.  Furthermore I really don't like
the above patch since it changes the default screen title to
something much less information, ie with it screen no longer displays
the list of titles of the individual screens, just the user@host and
dir of where screen was run.

Could this please be reverted?

Also I think this was a screen bug -- screen used to just set
the title to just "screen", but at least our screen package
doesn't do that anymore.
I'm happy to fix setup, if it helps.

Could you be more specific about the behavior you are seeing and the setup that
you have?

There are two patches involved here: this one, and the one from bug#60597.  

I have never seen screen display the title list continually (by default at
least). Is there perhaps a custom .screenrc at work here?  Perhaps you have the line

defhstatus '^Ew'

in your .screenrc?  If you think that the screen default should always be to
display the title list, then you should ask for a change to /etc/screenrc. A
line something like

hardstatus string "screen: %w"

would do this, and the bash $PROMPT_COMMAND from this bug would not change it.

Now I'm confused.  For me with the patch, "defhstatus '^Ew'" in my .screenrc
has no effect, both in xterm and gnome-terminal.  This is with pretty
current packages from Limbo.  Perhaps this a Valhalla related problem...
it is really annoying when logging into a 7.3 machine and not being able to
see the screen window list in the titlebar...

Sorry, I didn't mean for you to add "defhstatus '^Ew'" to your .screenrc, I was
asking if you already had such a line there.  I'm just trying to figure out why
you used to get the window list as the hardstatus line, because I have never
seen this behavior in the default configuration.

This whole subject is confusing because screen has two notions of hardstatus. 
The 'stored hardstatus' is a per-screen string whose default value is set by the
defhstatus command.  Its value can be changed by certain terminal codes (as in
this bashrc patch), and can be accessed various places in screen by the %h (or
^Eh) escape sequences.  Whether or not the hardstatus is displayed, and what
value is actually displayed is controlled by the hardstatus command.  In
particular the command

hardstatus string "my string"

will set the actual displayed hardstatus to "my string" nomatter what the stored
hardstatus is.  The (screen) default value is

hardstatus string "%h"

which shows the stored hardstatus.  The current /etc/screenrc alters this to
something a little more informative:

hardstatus string "[screen %n] %h"

which still shows the stored hardstatus, but prepends the screen number.

The change to /etc/bashrc instigated by this bug merely causes bash to send the
appropriate terminal escape to change screen's stored hardstatus line to the
same thing that it changes xterms hardstatus line to.  Ideally, if a user is
running bash in a screen session in an xterm, the titlebar of the xterm should
read something like "[screen 0] user@host:~/www/cgi", which is certainly
reasonably informative (and much better that simply "screen").

If a user wants a custom hardstatus line, then they can place the following line
in their .screenrc:

hardstatus string "whatever i want"

There are a number of % escapes that can be used in the string. See the screen
man page and search for STRING ESCAPES.  If you want the window list, then

hardstatus string "%w"

will do that.  If on the other hand, the user would like for bash to set the
hardstatus line to something slightly different, they can set a custom value for
 PROMPT_COMMAND in their .bashrc.

Again to be clear, I have never seen a default configuration where the screen
window list is displayed in the hardstatus continually, I always had to press
^Aw to see the window list, and it reverted to the (then uninformative)
hardstatus after a few seconds.  I've tested 7.0, 7.1, and 7.2.

It seems most likely to me that you have a customized /etc/screenrc or .screenrc
that sets defhstatus to "^Ew".  Bash's escape codes are now overriding this. 
The fix is for the user's custom screen directive to be changed to hardstatus
string "%w", which will take precedence over the bash escape codes.

This is not a good reason to back out this patch.

Yes, I have been using "defhstatus '^Ew'" in my own .screenrc for months.
The point I'm trying to make is that with the patch, it doesn't seem possible
to change the title of screen's windows anymore.  Do you agree?

To reproduce on a fresh 7.3 install:

1. Start a new X-based terminal.  The titlebar shows "user@host:~".
2. Run screen in this terminal.  The title is now "[screen 0] user@host:~".
3. Press "Ctrl-a A" to set the title (you should see that the actual screen
   window title is "bash"), and change the title to say "mysession".
   The title does not change.

4. Now start a new X-based terminal
5. Run "screen bash --norc" (so that .bashrc and in turn /etc/bashrc are not
   sourced).  The title changes to "[screen 0] bash".
6. The title can be changed with "Ctrl-a A" as it should be.

AFAICT backing out the patch fixes this.

[So I would suggest if you want a more informative title when running
screen, it'd be better to change the screenrc default title to something more
informative.  I don't understand why this should be done at the bash level.]

Hrmm, re-reading your comments of 2002-07-19 15:45:03, I start to see your point
about the distinction of the terminal hard status and the screen window title.
So I realised that perhaps what I'm really asking for is that the screenrc default
hardstatus string be changed to use "%t" instead of "%h".  Then at least your
patch will not affect the default screen behaviour. ;-)

If that is done though, the bashrc patch seems less useful since it would not
have any user visible affect until "%h" is added to the hardstatus string by
the user.  At least the current behaviour is particularly annoying when one
logs into another machine and the hardstatus of the local machine still
appears in the terminal title, and it is non-intuitive, that users cannot
change the terminal title with "Ctrl-a A".

My points are:

1) The current behavior provides a reasonably informative default, one that is
certainly better than the default behavior in 7.2.

2) It is perfectly reasonable for bash to use the screen control codes to set
the stored hardstatus.  It does this with xterm, why not with screen?  In fact
screen supports xterm's codes for doing this, it's just that bash doesn't send
them unless TERM matches xterm*.

3) Users that want something different can easily modify their .screenrc and/or
.bashrc to get a wide variety of custom behaviors.

I take your point, though I think that having a list of screen windows
in the title-line would be more useful than just info on the current window.
Info on the current displayed shell is commonly visible as part of the shell
prompt, so just repeating this in the title doesn't seem as useful as a list
including all the other screen windows open.

Ok. I'm closing this bug.  If you want to press this issue, you should probably
open a bug against screen.

I am still not quite happy with this state of a affairs.
A further problem which I should have brought up earlier is that
PROMPT_COMMAND only really works well in a pure bash environment.
I know bash is our default shell, but if like me you use zsh say on
your own machine, but use the default bash on other machines, when
you ssh into a bash account (and your patch) [eg a 7.3 machine]
and then logout again, the hard status title from the remote bash session
sticks to the title which is most annoying.  So either the screenrc default
hardstatus string should not use "%h" or the bashrc patch should be reverted.
Users can always set PROMPT_COMMAND in their .bashrc files if they wish. ;-)

Ok, I need to check further, but perhaps with

defhstatus ""

I can live with PROMPT_COMMAND getting set on remote machines.

I little experiment reveals that this is also a problem in a plain old xterm. 
If you run 'xterm -e zsh' and then run bash, the xterm title is set by bash. If
you exit from bash back out to zsh, the xterm title remains as whatever bash set
it to.  This problem goes way back.

In fact there are many programs one might run from a bash shell that do not set
the xterm title or screen hardstatus, and so you will end up with a title that
is not directly relevant to the foreground app in the terminal.

I don't think that having bash not set these titles is the ideal solution.

At least with screen you have a little more info and control.  If the comprimise
change I suggested in bug 60597 was put in place, then the screen hardstatus
line would also include the screen number and title.  The screen title tends to
be even more out of out of sync with the foreground app, but at least it is
easily editable via [ctrl-A A].  Also in screen you can adjust nearly anything
*on the fly* by entering screen commands with [ctrl-A :].  You can, for example,
correct a stale stored hardstatus with 

hstatus "Something meaningful"

Or you can force the screen list to always appear with

hardstatus string "%w"

Hmm, we might even consider crafting a few different hardstatus strings and
binding some keys to switch among them.

Mike, thanks for all your help in clearing up this matter.
Since I had reverted your patch already before I saw your reply of
2002-07-03 11:30:31, I just brought it back now in setup-2.5.18-1.
Also I added a check for /etc/sysconfig/bash-prompt-screen like for
the other two cases.

Fixed in 8.0