Hide Forgot
setup-2.5.7-1 screen-3.9.9-3 With the current default configuration, screen's hardstatus line (which is displayed in the title bar when screen is run in an xterm) is not set. This results in the xterm title becoming simply "screen" after a short while. Slightly informative, yes, but less informative than it could be. /etc/bashrc already sets the xterm title when TERM=xterm. I have a patch for /etc/bashrc that will cause bash to set the hardstatus line to the same value it sets the xterm title to. Will attach.
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