From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8589 invoked from network); 23 Nov 2000 05:36:09 -0000 Received: from sunsite.dk (HELO sunsite.auc.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 Nov 2000 05:36:09 -0000 Received: (qmail 25931 invoked by alias); 23 Nov 2000 05:35:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13183 Received: (qmail 25924 invoked from network); 23 Nov 2000 05:35:45 -0000 Date: Thu, 23 Nov 2000 00:35:42 -0500 From: "Glenn F. Maynard" To: zsh-workers@sunsite.auc.dk Subject: Re: xterm title/screen title+hardstatus Message-ID: <20001123003542.A4645@h0040333b7dc3.ne.mediaone.net> Mail-Followup-To: zsh-workers@sunsite.auc.dk References: <20001121145838.A2755@h0040333b7dc3.ne.mediaone.net> <1001122081141.ZM11237@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1001122081141.ZM11237@candle.brasslantern.com>; from schaefer@candle.brasslantern.com on Wed, Nov 22, 2000 at 08:11:41AM +0000 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