Updating the Xterm title with every execution?

Updating the Xterm title with every execution?

[Ryan Tennant]

Hello.  I am trying to update the Xterm title every time I execute an
application, script, etc.  To do this, it would seem logical that I have to
process the commands I enter at the command line before executing them.  Zsh
seems to offer some preprocessing functionality, but not so much that I can
ask it to preprocess command line information and then execute an arbitrary
command.

A script to display what I'm interested in doing is below.  

script name: hi
#!/bin/zsh
echo '\033]; '$*'\007'				# Displays command in xterm
title after script name (i.e hi ls -la, would display ls -la)
trap "trap '' 2"  2					
$*						# Executes commands I enter
after the script name
trap ""  2
echo '\033]; '${HOSTNAME}: IDLE'\007'		# Displays idle xterm title


i want to do line 1 after i hit enter before execution of $*.  I want to
reset the title bar in the event that I hit ctrl-c (traps).  I want to do
line 6 after execution of the commands.

obviously the functionality of this script is limited in the fact that it
doesnt parse beyond "|"s or other delimeters.

essentially, i'm looking for someone more gifted than myself to aid in my
quest.

thanks.

ryan tennant

Re: Updating the Xterm title with every execution?

[Larry P . Schrof]

About the closest non-convoluted way to do it I can think of is to use
preexec to echo various arguments to the title bar. (These arguments
will be echoed after history expansion but before any other type of
substitution / generation)

Resetting the title bar in this case is a tricky issue. Assuming an
interactive shell, you could use precmd to reset the title bar to
something just before the zsh prompt is displayed. That doesn't
necessarily mean you'll retain the same title bar as before the
command ran.

Anything attempts beyond this I personally see as getting a bit
hackish, ie.  wasn't intended to be supported by zsh specifically.

On Thu, Mar 25, 1999 at 03:15:25PM -0500, Ryan Tennant wrote:
> Hello.  I am trying to update the Xterm title every time I execute an
> application, script, etc.  To do this, it would seem logical that I have to
> process the commands I enter at the command line before executing them.  Zsh
> seems to offer some preprocessing functionality, but not so much that I can
> ask it to preprocess command line information and then execute an arbitrary
> command.
> 
> A script to display what I'm interested in doing is below.  
> 
> script name: hi
> #!/bin/zsh
> echo '\033]; '$*'\007'				# Displays command in xterm
> title after script name (i.e hi ls -la, would display ls -la)
> trap "trap '' 2"  2					
> $*						# Executes commands I enter
> after the script name
> trap ""  2
> echo '\033]; '${HOSTNAME}: IDLE'\007'		# Displays idle xterm title
> 
> 
> i want to do line 1 after i hit enter before execution of $*.  I want to
> reset the title bar in the event that I hit ctrl-c (traps).  I want to do
> line 6 after execution of the commands.
> 
> obviously the functionality of this script is limited in the fact that it
> doesnt parse beyond "|"s or other delimeters.
> 
> essentially, i'm looking for someone more gifted than myself to aid in my
> quest.
> 
> thanks.
> 
> ryan tennant

Re: Updating the Xterm title with every execution?

[Matthew Lovell]

On 25 March 1999, Ryan Tennant writes:
 > Hello.  I am trying to update the Xterm title every time I execute an
 > application, script, etc.  To do this, it would seem logical that I have to
 > process the commands I enter at the command line before executing them.  Zsh
 > seems to offer some preprocessing functionality, but not so much that I can
 > ask it to preprocess command line information and then execute an arbitrary
 > command.

This certainly isn't a general solution to your problem, but I do
change the terminal title for some commands (and take care to restore
it upon others).

function print_banner {
         print -n "\e]0;$1\a"
       }

function chpwd() {
       banner="$(print -Pn '%n@%m - %55<...<%~')"
       print_banner "$banner"    
     }

     function vi     { print_banner $1; =vi $1; chpwd }
     function su     { =su $*; chpwd }
     function zsh    { =zsh $*; chpwd }
     function rlogin { =rlogin $*; chpwd }
     function rcmd   { =rcmd $*; chpwd }

-- 

Matthew Lovell                       voice: (970) 898-6264 
Hewlett-Packard WSL                    fax: (970) 898-2510 
3404 E. Harmony Rd. MS A0         location: 3UQ4
Fort Collins, CO 80528-9599         mailto:lovell@fc.hp.com

Re: Updating the Xterm title with every execution?

[Greg Badros]

Ryan Tennant <rtennant@trcinc.com> writes:

> Hello.  I am trying to update the Xterm title every time I execute an
> application, script, etc.  To do this, it would seem logical that I have to
> process the commands I enter at the command line before executing them.  Zsh
> seems to offer some preprocessing functionality, but not so much that I can
> ask it to preprocess command line information and then execute an arbitrary
> command.

You should take a look at my patch to zsh-3.0.5:

http://www.cs.washington.edu/homes/gjb/patches/zsh-3.0.5-color-postprompt.README
http://www.cs.washington.edu/homes/gjb/patches/zsh-3.0.5-color-postprompt.patch

it adds a POSTPROMPT that lets zsh output an arbitrary prompt-like
expression *after* reading a command (optionally delaying some
configurable number of seconds).  I use this with XTerm escape sequences 
to do exactly as you suggest (and in fact this was the motivating
problem-- I just generalized it in case anyone else can think of other
cool things to use it for).  My Xterm titles reflect the name of the
last command that ran for more than $PPTMOUT (=5) seconds.

The patch also adds colorization (a la GNU color-ls) to the completion
lists.  (Also a run-time option).

Enjoy!

Greg J. Badros
gjb@cs.washington.edu
Seattle, WA  USA
http://www.cs.washington.edu/homes/gjb

Re: Updating the Xterm title with every execution?

[Larry P . Schrof]

The color in expansions is a cool idea, but I'm wondering what the
first half of the patch can do that preexec can't?

Thanks.

- Larry

On Thu, Mar 25, 1999 at 01:55:44PM -0800, Greg Badros wrote:
> Ryan Tennant <rtennant@trcinc.com> writes:
> 
> > Hello.  I am trying to update the Xterm title every time I execute an
> > application, script, etc.  To do this, it would seem logical that I have to
> > process the commands I enter at the command line before executing them.  Zsh
> > seems to offer some preprocessing functionality, but not so much that I can
> > ask it to preprocess command line information and then execute an arbitrary
> > command.
> 
> You should take a look at my patch to zsh-3.0.5:
> 
> http://www.cs.washington.edu/homes/gjb/patches/zsh-3.0.5-color-postprompt.README
> http://www.cs.washington.edu/homes/gjb/patches/zsh-3.0.5-color-postprompt.patch
> 
> it adds a POSTPROMPT that lets zsh output an arbitrary prompt-like
> expression *after* reading a command (optionally delaying some
> configurable number of seconds).  I use this with XTerm escape sequences 
> to do exactly as you suggest (and in fact this was the motivating
> problem-- I just generalized it in case anyone else can think of other
> cool things to use it for).  My Xterm titles reflect the name of the
> last command that ran for more than $PPTMOUT (=5) seconds.
> 
> The patch also adds colorization (a la GNU color-ls) to the completion
> lists.  (Also a run-time option).
> 
> Enjoy!
> 
> Greg J. Badros
> gjb@cs.washington.edu
> Seattle, WA  USA
> http://www.cs.washington.edu/homes/gjb

Re: Updating the Xterm title with every execution?

[Greg Badros]

"Larry P . Schrof" <larry@schrof.net> writes:

> The color in expansions is a cool idea, but I'm wondering what the
> first half of the patch can do that preexec can't?

Please correct me if I'm wrong, but I don't think 'preexec' exists in
Zsh 3.0.5 -- I'm just going on the man pages since I don't have the
source handy at the moment.

Greg

Re: Updating the Xterm title with every execution?

[Bart Schaefer]

On Mar 25,  2:47pm, Greg Badros wrote:
} Subject: Re: Updating the Xterm title with every execution?
}
} "Larry P . Schrof" <larry@schrof.net> writes:
} 
} > The color in expansions is a cool idea, but I'm wondering what the
} > first half of the patch can do that preexec can't?
} 
} Please correct me if I'm wrong, but I don't think 'preexec' exists in
} Zsh 3.0.5

It's in 3.0.5-ext-2, available from ftp.brasslantern.com:/pub/zsh/, which
will be the basis of 3.0.6 appearing (I hope, if I get the archive scripts
learned soon) sometime this month.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

RE: Updating the Xterm title with every execution?

[Andrej Borsenkow]

> }
> } > The color in expansions is a cool idea, but I'm wondering what the
> } > first half of the patch can do that preexec can't?
> }
> } Please correct me if I'm wrong, but I don't think 'preexec' exists in
> } Zsh 3.0.5
>
> It's in 3.0.5-ext-2, available from ftp.brasslantern.com:/pub/zsh/, which
> will be the basis of 3.0.6 appearing (I hope, if I get the archive scripts
> learned soon) sometime this month.
>

I'd just like to point out, that setting title to the command
name/parameters is probably not trivial. preexec gets the whole command line
(at least,as long as I can beleive the manual. Are parameter assignments
included?). It means, that in case of some more or less complex things
(braces, pipelines etc) you have to parse the string again ... and, well,
you can even have redirection as the first word on command line :-)

cheers

/andrej

Re: Updating the Xterm title with every execution?

[Greg Badros]

"Bart Schaefer" <schaefer@brasslantern.com> writes:

> } Please correct me if I'm wrong, but I don't think 'preexec' exists in
> } Zsh 3.0.5
> 
> It's in 3.0.5-ext-2, available from ftp.brasslantern.com:/pub/zsh/, which
> will be the basis of 3.0.6 appearing (I hope, if I get the archive scripts
> learned soon) sometime this month.

That's great-- any chance of getting my colorized completion patch in
there?  It's plenty clean, has it's own option, and is pretty small --
it could be a compile-time switch if you're *really* concerned about
memory footprint (zsh 3.0.x still does not have any dynamic loading
capabilities, does it?).  Since 3.0.6 is the end of the road for 3.0,
the maintenance headache of another compile-time flag is not an issue.

The patch is the first one listed at:

http://www.cs.washington.edu/homes/gjb/patches/

I'll get it to apply cleanly without the postprompt stuff (assumming
preexec will let me do what I want) to .0.5-ext-2 if you don't want to
do that work.

Thanks,
Greg

Re: Updating the Xterm title with every execution?

[Sven Wischnowsky]

Greg Badros wrote:

> Though why can't
> executing a setopt load a module (as invoking a function loads that
> function)?

The problem is that the option code currently uses an array with one
entry per option, making testing for set/unset options nicely small
and fast. Enhancing that is not trivial.

Side note: once we have modules autoloadable on parameters, this might 
be another argument for mocing towards a associative-array based
option system.

> Similarly, I've wanted this for completion controls, too --
> scanning all my completion stuff takes forever at startup-- it'd be nice 
> to have them autoloaded when I first try to complete (ignorance warning: 
> I've not been following the 3.1.x discussion on completion stuff so
> maybe people are working on this or something similar).

Well, the new completion system (more precisely: the example
implementation of the new completion system) uses autoloaded functions.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Updating the Xterm title with every execution?

[Greg Badros]

Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> Greg Badros wrote:
> 
> > Why is an option a problem?  It's cleaner to use an option then to have
> > it be only a compile-time flag.  There are plenty of other options
> > affecting completion (listambiguous, listtypes, menucomplete, etc.).
> 
> Obviously I wasn't clear enough... I have no objections to put that
> into 3.0.6. But I wouldn't like to see an option to be used for it
> because people would then expect this option to be in 3.1x, too. And
> since I wouldn't like to see a feature as specific as this to be in
> the standard completion module and because modules currently can't
> define their own options, we would have to put it into the core.
> With the modules in 3.1. it would be easy to put enhancements like
> this one into separate modules, which, as I hope you agree, is much
> cleaner.

Ah, yes... now this makes much more sense to me.  Though why can't
executing a setopt load a module (as invoking a function loads that
function)?  Similarly, I've wanted this for completion controls, too --
scanning all my completion stuff takes forever at startup-- it'd be nice 
to have them autoloaded when I first try to complete (ignorance warning: 
I've not been following the 3.1.x discussion on completion stuff so
maybe people are working on this or something similar).

<snip>
> 
> I hope this is clear now -- backward-compatibility. And you don't need 
> the option if you make your patch alwasy use the parameter
> `ZLS_COLOUR' (or whatever) and turn on colours only if that parameter
> is set. The name should be seldom enough to not interfere with any
> existing parameter name.

This seems reasonable, and I'd be glad to make the colorized completion
stuff work as you suggest so as to not burden the 3.1 implementation
unnecessarily.

Thanks for your clarification.

Greg

Re: Updating the Xterm title with every execution?

[Sven Wischnowsky]

Greg Badros wrote:

> Why is an option a problem?  It's cleaner to use an option then to have
> it be only a compile-time flag.  There are plenty of other options
> affecting completion (listambiguous, listtypes, menucomplete, etc.).

Obviously I wasn't clear enough... I have no objections to put that
into 3.0.6. But I wouldn't like to see an option to be used for it
because people would then expect this option to be in 3.1x, too. And
since I wouldn't like to see a feature as specific as this to be in
the standard completion module and because modules currently can't
define their own options, we would have to put it into the core.
With the modules in 3.1. it would be easy to put enhancements like
this one into separate modules, which, as I hope you agree, is much
cleaner.
As for the different implementation: I didn't suggest *replacing* your 
stuff with something different. At least I *wanted* to suggest that by 
moving it into a separate module in 3.1. we could give the user a way
to decide if he wants to use your implementation (which would be one
module), or another implementation (which would give a bit more
control to colourise non-filenames and more and would be in another
separate module). The user would chose what he wants just by including 
one (or none at all) of these modules.

> > for it (well, something could be said against it: it's superfluous --
> > even in your patch making it use only `ZLS_COLOR' (or turning it into
> > an array and giving it a better name) and testing if that is set would
> > be enough).
> 
> I do not know what you mean use only "ZLS_COLOR".  Why is that better
> than setopt listcolors?

I hope this is clear now -- backward-compatibility. And you don't need 
the option if you make your patch alwasy use the parameter
`ZLS_COLOUR' (or whatever) and turn on colours only if that parameter
is set. The name should be seldom enough to not interfere with any
existing parameter name.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Updating the Xterm title with every execution?

[Greg Badros]

Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> > 
> > That's great-- any chance of getting my colorized completion patch in
> > there?  It's plenty clean, has it's own option, and is pretty small --
> > it could be a compile-time switch if you're *really* concerned about
> > memory footprint (zsh 3.0.x still does not have any dynamic loading
> > capabilities, does it?).  Since 3.0.6 is the end of the road for 3.0,
> > the maintenance headache of another compile-time flag is not an issue.
> 
> The problem I have with this is that it uses an option. In 3.1. I

Why is an option a problem?  It's cleaner to use an option then to have
it be only a compile-time flag.  There are plenty of other options
affecting completion (listambiguous, listtypes, menucomplete, etc.).

> would like to make the code in `zle_tricky.c' use a pointer variable to
> call `listmatches()' to allow stuff like this to be put in a different 
> module that may be loaded on top of `compctl'. We can then also add a
> different colourisation module which is a bit more zsh-ish. Probably
> using a assoc array to map patterns/descriptions to strings like
> `%B%n%b' where the `%n' gets replaced by the string (of course, the
> best way would be to allow different maps for different completions,
> but we could already use group names for that). Or something like
> that. This should be easy to use because I think that sometime we will 
> be able to make modules autoloaded on parameter names (haven't really
> looked for that in the code yet, but every parameter name lookup goes
> through the paramtab-hashtable functions, right?).

Making it more zsh-ish defeats one of the goals which is transparent
interoperability with colorized GNU ls output-- my Zsh patch uses the
same configuration mechanism as that (and the same code, largely).

> Of course, if we add a way to allow modules to define options and make 
> modules autoloaded on them, nothing could be said against using a option

Sure, but that's for 3.1, not 3.0.6.

> for it (well, something could be said against it: it's superfluous --
> even in your patch making it use only `ZLS_COLOR' (or turning it into
> an array and giving it a better name) and testing if that is set would
> be enough).

I do not know what you mean use only "ZLS_COLOR".  Why is that better
than setopt listcolors?

> Anyway, I don't think that I'll ever use a feature like this and so
> would be against putting it into the zsh core itself. But it's not my
> duty to decide this...

Sure, and it'd be great if 3.0.x had dynamic module support so everyone
could be happy, but for very little space, you get a feature that is
pretty darn useful, and helps zsh interroperate better with one of the
most used commands (ls).

Greg

P.S., here's the size difference on an x86 compiled with egcs-1.1.x.

 397 -rwxrwxr-x   1 gjb      contrib    402882 Feb  9 16:46 zsh-3.0.5*
 402 -rwxr-xr-x   2 gjb      visitors   407740 Mar 19 18:18 zsh-gjb*

(zsh-gjb includes my patch for both post-prompts and colorized-completion)

Re: Updating the Xterm title with every execution?

[Sven Wischnowsky]

Greg Badros wrote:

> "Bart Schaefer" <schaefer@brasslantern.com> writes:
> 
> > } Please correct me if I'm wrong, but I don't think 'preexec' exists in
> > } Zsh 3.0.5
> > 
> > It's in 3.0.5-ext-2, available from ftp.brasslantern.com:/pub/zsh/, which
> > will be the basis of 3.0.6 appearing (I hope, if I get the archive scripts
> > learned soon) sometime this month.
> 
> That's great-- any chance of getting my colorized completion patch in
> there?  It's plenty clean, has it's own option, and is pretty small --
> it could be a compile-time switch if you're *really* concerned about
> memory footprint (zsh 3.0.x still does not have any dynamic loading
> capabilities, does it?).  Since 3.0.6 is the end of the road for 3.0,
> the maintenance headache of another compile-time flag is not an issue.

The problem I have with this is that it uses an option. In 3.1. I
would like to make the code in `zle_tricky.c' use a pointer variable to
call `listmatches()' to allow stuff like this to be put in a different 
module that may be loaded on top of `compctl'. We can then also add a
different colourisation module which is a bit more zsh-ish. Probably
using a assoc array to map patterns/descriptions to strings like
`%B%n%b' where the `%n' gets replaced by the string (of course, the
best way would be to allow different maps for different completions,
but we could already use group names for that). Or something like
that. This should be easy to use because I think that sometime we will 
be able to make modules autoloaded on parameter names (haven't really
looked for that in the code yet, but every parameter name lookup goes
through the paramtab-hashtable functions, right?).

Of course, if we add a way to allow modules to define options and make 
modules autoloaded on them, nothing could be said against using a option
for it (well, something could be said against it: it's superfluous --
even in your patch making it use only `ZLS_COLOR' (or turning it into
an array and giving it a better name) and testing if that is set would
be enough).

Anyway, I don't think that I'll ever use a feature like this and so
would be against putting it into the zsh core itself. But it's not my
duty to decide this...

Bye
 Sven

P.S.: Module-defined options may also be an argument for moving to a
      assoc array based option system.

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de