Re: xterm title/screen title+hardstatus

["Glenn F. Maynard" <glennm@mediaone.net>]

On Wed, Nov 22, 2000 at 08:11:41AM +0000, Bart Schaefer wrote:
> } My objective is to display exactly what was typed in the titlebar (parsed
> } somewhat: the first word, the command, is placed in the title; the remainder,
> } if anything, is placed in the hardstatus line.)
> 
> I hate to rain on your parade, but you haven't even begun to address all
> the possible problems here.  What do you do about the AUTO_FG option?  What

I'm not terribly concerned with options I don't use.  I'm not looking for
a generic solution; I'm looking for an acceptable one for what features
I use.  (Where is auto_fg, anyway?  It doesn't seem to be mentioned in
the CVS tree.)

> zsh% ( print look, I am a subshell ; sleep 60 ; echo goodbye ) &
> 
> (Your function, and mine below, will put "(" in the title bar for that.)

I never do that outside of sh scripts.

> How meaningful is your hardstatus line when you run several commands in
> a pipeline?  What about redirections?

Meaningful enough to clearly identify it, which is what I'm looking for.

> (Did you know that you can write
> `2>/dev/null foo bar' in place of `foo bar 2>/dev/null'?)  What about
> `fg %2 %3 %5'?  (Brings multiple jobs to the foreground in succession.)

Again, I never do either of these things.  (I've never found a reason to
use the former syntax; I only find it slightly confusing.  I've no use for the
latter.)

> (OK, maybe I did like raining, just a little.  One solution would be to
> forget about putting one word in the title, and instead put a truncated
> prefix of the entire command line there.)

The problems I listed are the only ones that affect me ... and doing this
would make its operation worse (overall), for my use.  (If I run "~/bin/irc
irc.foo.com", I don't want to see the parameters as part of the title, just
"irc".) 

Doing this selectively could be useful, however: if the text in the title
wouldn't be somewhat meaningful.  (Perhaps if there isn't at least one
alphanumeric in it?  Not foolproof, but enough to catch most useless
titles.) 

> Anyway, here's a preexec to do what your patches and precmd did, without
> having to hack on the zsh source.

Thanks, I was hoping for that. 

> Probably the oddest bit of that is ${(z)${(e):-\$jt$num}} ... $num will be
> a string such as "[3]", so \$jt$num is $jt[3], which evaluated with (e) is
> the desired job text, which is then parsed with (z).
 
Eeg.
 
> } Currently, I've added a variable expansion parameter: if FOO=%vi, then
> } ${(J)FOO} expands to the job number.
> That was a creative approach, but I don't think it's the best way.  An
> option to the `jobs' command to have it stick its output in a parameter,
> like the `stat' command from the zsh/stat module does, would probably be
> much better.

Yep; I didn't like cluttering up expansions, but wasn't sure of a better
place.

> } Other problems I've had: Whitespace stripping was rather tricky; I'm sure
> } there's a better way to do it.  The (z) (split) expansion command has very
> } strange behavior: it splits on spaces if there's more than one word; if
> } there's only one word, it splits it into an array of single characters.
> Nope, that's not what's happening.  Subscripts on zsh parameters always
> behave that way:  If the parameter is a string, the subscript indexes it
> by characters, and if it's an array, it indexes by array elements.

Yuck. 

> } preexec() {
> } 	local cmd spl pnum lhs rhs
> } 	cmd=$@
> 
> This is unneccesary; preexec always gets exactly one argument (the whole
> command line, unparsed).

Yep, but since I was changing the functions around a lot, I shoved it
directly into a local so I didn't have to keep changing the parameters to
the first command.

> } 	spl=${(z)cmd}
> } 	if [[ ${#spl} == ${#cmd} ]] then
> } 		# it was split into an array of chars
> Oh, really?  Try `echo 1 2 3'.

That worked fine.

> } 	if [[ $lhs == "fg" ]] then
> } 		pnum=${(J)rhs}
> } 		preexec ${jobtexts[$pnum]}
> This recursive call is a lot of work just to get those two `echo's.

I had to reparse the string from jobtexts in the same way I parsed $@,
so it was the best way.  (If any other modifications are done to the
title, such as selectively setting titles and HS, it'll be needed, too.)
Removing literal newlines in $@ is 

To the first reply:

> It is worse than just quoting. You have to deal with pipelines and complex
> commands. Consider:

> bor@itsrm2% preexec() { print $1 > /tmp/foo }
> bor@itsrm2% while false
> while> do
> while> print x
> while> done

This works fine with both functions.  Something is changing this
to "while false ; do ; print x ; done"; I'm not sure what.

-- 
Glenn Maynard