* Problems with precmd/urxvt
@ 2012-12-03 9:20 Yuri D'Elia
2012-12-03 15:48 ` Bart Schaefer
0 siblings, 1 reply; 5+ messages in thread
From: Yuri D'Elia @ 2012-12-03 9:20 UTC (permalink / raw)
To: zsh-users
Hi everyone. Recently I tried make zsh change my terminal title with the
following in my .zshrc:
precmd() { print -Pn '\e]2;%~\a' }
it works ok, but from time to time, when I fire up a new urxvt terminal,
I get the following:
precmd:print: write error: interrupt
anybody got the same?
Also, since print is builtin, I wasn't able to silence the error anyway.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problems with precmd/urxvt
2012-12-03 9:20 Problems with precmd/urxvt Yuri D'Elia
@ 2012-12-03 15:48 ` Bart Schaefer
2012-12-04 14:10 ` Yuri D'Elia
0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2012-12-03 15:48 UTC (permalink / raw)
To: zsh-users
On Dec 3, 10:20am, Yuri D'Elia wrote:
}
} precmd() { print -Pn '\e]2;%~\a' }
}
} it works ok, but from time to time, when I fire up a new urxvt terminal,
} I get the following:
}
} precmd:print: write error: interrupt
I don't have the error, but this probably means urxvt is starting up
the shell before it has the window open and is ready to display.
You could try something like
precmd() { [[ -t 0 && -w 0 ]] && print -Pn '\e]2;%~\a' }
but that may not help.
} Also, since print is builtin, I wasn't able to silence the error anyway.
You can redirect internal errors from builtins by using braces:
precmd() { { print -Pn '\e]2;%~\a' } 2>/dev/null }
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problems with precmd/urxvt
2012-12-03 15:48 ` Bart Schaefer
@ 2012-12-04 14:10 ` Yuri D'Elia
2012-12-04 16:01 ` Bart Schaefer
0 siblings, 1 reply; 5+ messages in thread
From: Yuri D'Elia @ 2012-12-04 14:10 UTC (permalink / raw)
To: zsh-users
On 12/03/2012 04:48 PM, Bart Schaefer wrote:
> I don't have the error, but this probably means urxvt is starting up
> the shell before it has the window open and is ready to display.
>
> You could try something like
>
> precmd() { [[ -t 0&& -w 0 ]]&& print -Pn '\e]2;%~\a' }
>
> but that may not help.
Humm, I tried with just "[ -t 0 ] && .." and seems to be enough.
Strangely enough, not only I don't get the error anymore, but the
terminal title also seem to be always correctly set on startup (which is
weird, since I would expect to start the default once in a while).
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problems with precmd/urxvt
2012-12-04 14:10 ` Yuri D'Elia
@ 2012-12-04 16:01 ` Bart Schaefer
2012-12-05 14:35 ` Yuri D'Elia
0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2012-12-04 16:01 UTC (permalink / raw)
To: zsh-users
On Dec 4, 3:10pm, Yuri D'Elia wrote:
}
} Humm, I tried with just "[ -t 0 ] && .." and seems to be enough.
Possibly the -t test is blocking until the terminal is ready. That
would synchronize the shell with the parent urxvt, which would also
explain this:
} Strangely enough, not only I don't get the error anymore, but the
} terminal title also seem to be always correctly set on startup
On the other hand I'd have expected zsh's internals to do the equivalent
of -t at some point during initialization, to decide whether the shell
is interactive in the first place, so maybe introducing a tiny delay
before the print is enough to break the race condition.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problems with precmd/urxvt
2012-12-04 16:01 ` Bart Schaefer
@ 2012-12-05 14:35 ` Yuri D'Elia
0 siblings, 0 replies; 5+ messages in thread
From: Yuri D'Elia @ 2012-12-05 14:35 UTC (permalink / raw)
To: zsh-users
On 12/04/2012 05:01 PM, Bart Schaefer wrote:
> Possibly the -t test is blocking until the terminal is ready. That
> would synchronize the shell with the parent urxvt, which would also
> explain this:
>
> } Strangely enough, not only I don't get the error anymore, but the
> } terminal title also seem to be always correctly set on startup
>
> On the other hand I'd have expected zsh's internals to do the equivalent
> of -t at some point during initialization, to decide whether the shell
> is interactive in the first place, so maybe introducing a tiny delay
> before the print is enough to break the race condition.
I spoke too soon. I got another interrupted call today.
It seems that, like you say, [ -t 0 ] just delays the call long enough
for urxvt to be available most of the time, so it became very rare, but
not absent.
I just suppressed the error now. This is tricky to debug and I'm quite
sure urxvt is at fault (probably the message is due to the window being
mapped, but maybe not managed yet!?). Just don't have time to debug it
properly now.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-12-05 14:35 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-03 9:20 Problems with precmd/urxvt Yuri D'Elia
2012-12-03 15:48 ` Bart Schaefer
2012-12-04 14:10 ` Yuri D'Elia
2012-12-04 16:01 ` Bart Schaefer
2012-12-05 14:35 ` Yuri D'Elia
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).