You are not logged in.

#1 2007-02-04 14:34:13

Zoranthus
Member
From: muc
Registered: 2006-11-22
Posts: 166

Setting a dynamic urxvt window title

Hi,

I'm using urxvt windows for alot of apps and I don't like to have 6 windows in the taskbar that all say "urxvt [Number]").
That's why I would like to have either the name of the last app started in urxvt or at least a tail output of what's currently in there.

I understood that with

printf '\33]2;%s\007' "foo"

I can set the window title to foo but that was it.


Does anyone know if/how I can put something dynamic to the console title bar?
Doesn't have to be urxvt, but would be cool.

Thanks in advance. smile

Last edited by Zoranthus (2007-02-04 14:34:39)

Offline

#2 2007-02-04 15:49:49

_Pi
Member
From: CT
Registered: 2005-07-07
Posts: 26

Re: Setting a dynamic urxvt window title

Why not just use screen? It emulates as many consoles as you need in one urxvt window and has a custom configured dynamic title or a static title which you can set. A bit hard getting the hang of it at first but it's a great app.

Offline

#3 2007-02-04 20:27:05

skymt
Member
Registered: 2006-11-27
Posts: 443

Re: Setting a dynamic urxvt window title

I have something like what you want, but it only works in ZSH. I have this in my .zshrc:

THSTATUS=`tput tsl`
FHSTATUS=`tput fsl`

set_xterm_title() {
    if tput hs ; then
        print -Pn "$THSTATUS$@$FHSTATUS"
    fi
}

preexec() {
    set_xterm_title "%n@%m: %50>...>$1%<<"

precmd() {
    set_xterm_title "%n@%m: %50<...<%~%<<"
}

zsh runs preexec() before each command and precmd() before each prompt (cmd stands for command prompt in this case). preexec sets the title bar to "username@hostname: command", precmd sets it to "username@hostname: current directory".

Offline

#4 2007-02-05 10:01:00

onearm
Member
From: Anywhere but here
Registered: 2006-07-06
Posts: 359
Website

Re: Setting a dynamic urxvt window title

Following skymt suggestion, I found this script which should make the preexec() and precmd() work in bash too, but I'm too newbie to figure out how the whole works hmm

#!/bin/bash

# preexec.bash -- Bash support for ZSH-like 'preexec' and 'precmd' functions.

# The 'preexec' function is executed before each interactive command is
# executed, with the interactive command as its argument.  The 'precmd'
# function is executed before each prompt is displayed.

# To use, in order:

#  1. source this file
#  2. define 'preexec' and/or 'precmd' functions (AFTER sourcing this file),
#  3. as near as possible to the end of your shell setup, run 'preexec_install'
#     to kick everything off.

# Note: this module requires 2 bash features which you must not otherwise be
# using: the "DEBUG" trap, and the "PROMPT_COMMAND" variable.  preexec_install
# will override these and if you override one or the other this _will_ break.

# This is known to support bash3, as well as *mostly* support bash2.05b.  It
# has been tested with the default shells on MacOS X 10.4 "Tiger", Ubuntu 5.10
# "Breezy Badger", Ubuntu 6.06 "Dapper Drake", and Ubuntu 6.10 "Edgy Eft".


# This variable describes whether we are currently in "interactive mode";
# i.e. whether this shell has just executed a prompt and is waiting for user
# input.  It documents whether the current command invoked by the trace hook is
# run interactively by the user; it's set immediately after the prompt hook,
# and unset as soon as the trace hook is run.
preexec_interactive_mode=""

# Default do-nothing implementation of preexec.
function preexec () {
    true
}

# Default do-nothing implementation of precmd.
function precmd () {
    true
}

# This function is installed as the PROMPT_COMMAND; it is invoked before each
# interactive prompt display.  It sets a variable to indicate that the prompt
# was just displayed, to allow the DEBUG trap, below, to know that the next
# command is likely interactive.
function preexec_invoke_cmd () {
    precmd
    preexec_interactive_mode="yes"
}

# This function is installed as the DEBUG trap.  It is invoked before each
# interactive prompt display.  Its purpose is to inspect the current
# environment to attempt to detect if the current command is being invoked
# interactively, and invoke 'preexec' if so.
function preexec_invoke_exec () {
    if [[ -n "$COMP_LINE" ]]
    then
        # We're in the middle of a completer.  This obviously can't be
        # an interactively issued command.
        return
    fi
    if [[ -z "$preexec_interactive_mode" ]]
    then
        # We're doing something related to displaying the prompt.  Let the
        # prompt set the title instead of me.
        return
    else
        # If we're in a subshell, then the prompt won't be re-displayed to put
        # us back into interactive mode, so let's not set the variable back.
        # In other words, if you have a subshell like
        #   (sleep 1; sleep 2)
        # You want to see the 'sleep 2' as a set_command_title as well.
        if [[ 0 -eq "$BASH_SUBSHELL" ]]
        then
            preexec_interactive_mode=""
        fi
    fi
    if [[ "preexec_invoke_cmd" == "$BASH_COMMAND" ]]
    then
        # Sadly, there's no cleaner way to detect two prompts being displayed
        # one after another.  This makes it important that PROMPT_COMMAND
        # remain set _exactly_ as below in preexec_install.  Let's switch back
        # out of interactive mode and not trace any of the commands run in
        # precmd.

        # Given their buggy interaction between BASH_COMMAND and debug traps,
        # versions of bash prior to 3.1 can't detect this at all.
        preexec_interactive_mode=""
        return
    fi

    # In more recent versions of bash, this could be set via the "BASH_COMMAND"
    # variable, but using history here is better in some ways: for example, "ps
    # auxf | less" will show up with both sides of the pipe if we use history,
    # but only as "ps auxf" if not.
    local this_command=`history 1 | sed -e "s/^[ ]*[0-9]*[ ]*//g"`;

    # If none of the previous checks have earlied out of this function, then
    # the command is in fact interactive and we should invoke the user's
    # preexec hook with the running command as an argument.
    preexec "$this_command"
}

# Execute this to set up preexec and precmd execution.
function preexec_install () {

    # *BOTH* of these options need to be set for the DEBUG trap to be invoked
    # in ( ) subshells.  This smells like a bug in bash to me.  The null stderr
    # redirections are to quiet errors on bash2.05 (i.e. OSX's default shell)
    # where the options can't be set, and it's impossible to inherit the trap
    # into subshells.

    set -o functrace > /dev/null 2>&1
    shopt -s extdebug > /dev/null 2>&1

    # Finally, install the actual traps.
    PROMPT_COMMAND=preexec_invoke_cmd
    trap 'preexec_invoke_exec' DEBUG
}

To get something done, a committee should consist of no more than three persons, two of them absent.
--
My Github

Offline

#5 2007-02-05 16:55:03

Zoranthus
Member
From: muc
Registered: 2006-11-22
Posts: 166

Re: Setting a dynamic urxvt window title

Thank you very much, zsh is awesome, as is screen, I'm using both now. big_smile

Offline

Board footer

Powered by FluxBB