zsh-users
 help / color / mirror / code / Atom feed
* 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).