Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: xterm title/screen title+hardstatus
- X-seq: zsh-workers 13183
- From: "Glenn F. Maynard" <glennm@xxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: xterm title/screen title+hardstatus
- Date: Thu, 23 Nov 2000 00:35:42 -0500
- In-reply-to: <1001122081141.ZM11237@xxxxxxxxxxxxxxxxxxxxxxx>; from schaefer@xxxxxxxxxxxxxxxxxxxxxxx on Wed, Nov 22, 2000 at 08:11:41AM +0000
- Mail-followup-to: zsh-workers@xxxxxxxxxxxxxx
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <20001121145838.A2755@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1001122081141.ZM11237@xxxxxxxxxxxxxxxxxxxxxxx>
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author