Zsh and control-t

Den Mon, 06 Nov 2006 17:47:24 +0100, skrev Markus Weiss:

> Eivind E writes:
>
>> I have a Freebsd machine and I use zsh. For some reason or another,
>> when I start X using Xdm, control-t doesn't work. It works on a regular
>> console and when I start X from a console using xinit. This doesn't happen
>
> Works here with rxvt and xterm.
>
> # stty
>
> speed 38400 baud;
> lflags: echoe echok echoke echoctl pendin
> iflags: -ixany ignpar
> oflags: -oxtabs
> cflags: cs8 -parenb -hupcl

Thanks for the tip. I tried changing stty settings, but it didn't help.
After taking a closer look, I also see this happening :

Using xdm to log in xterm/zsh will handle control-t correctly if it's
started from kde's konsole. Konsole will also handle it correctly.

Xterm will handle control-t correctly if I run csh from it
and then dropping back to zsh by running exit.

When starting X with xinit from a regular console, xterm/zsh will
stop handling control-t correctly as soon as I log out from the console
(for instance xinit&;exit).

Any ideas on this? Could it be a filehandler that gets closed when
exiting from the console or never opened if I login from xdm?

Regards Eivind

--
_
//
_ //
\\ //
\\//
\/

Eivind E
 >> Stay informed about: Zsh and control-t 

In article
Eivind E writes:
>Den Mon, 06 Nov 2006 17:47:24 +0100, skrev Markus Weiss:
>
>> Eivind E writes:
>>
>>> I have a Freebsd machine and I use zsh. For some reason or another,
>>> when I start X using Xdm, control-t doesn't work. It works on a regular
>>> console and when I start X from a console using xinit. This doesn't happen

I assume you refer to the status report that ctrl-t gives when you have
a program running in the foreground, rather than the transpose-chars
editing function that it provides at the prompt? If so, I can reproduce
the problem by firing up 'xterm -e zsh' (I have tcsh as my login shell).

>> Works here with rxvt and xterm.
>>
>> # stty
>>
>> speed 38400 baud;
>> lflags: echoe echok echoke echoctl pendin
>> iflags: -ixany ignpar
>> oflags: -oxtabs
>> cflags: cs8 -parenb -hupcl
>
>Thanks for the tip. I tried changing stty settings, but it didn't help.

Did you try looking at 'stty -a', and doing 'stty status ^t'? For me,
the former shows 'status = <undef>' when the problem is present, as
opposed to 'status = ^T' when it isn't, and the latter fixes it.

>After taking a closer look, I also see this happening :
>
>Using xdm to log in xterm/zsh will handle control-t correctly if it's
>started from kde's konsole. Konsole will also handle it correctly.
>
>Xterm will handle control-t correctly if I run csh from it
>and then dropping back to zsh by running exit.
>
>When starting X with xinit from a regular console, xterm/zsh will
>stop handling control-t correctly as soon as I log out from the console
>(for instance xinit&;exit).
>
>Any ideas on this? Could it be a filehandler that gets closed when
>exiting from the console or never opened if I login from xdm?

I think it's a symptom of a long-standing problem with many/most
terminal emulators - how should they initialize the stty settings on the
pseudo-tty that they allocate? The default settings that the kernel
gives may not be appropriate for typical use, but it's highly
OS-dependant both what those defaults are and what the "proper" settings
are.

In some cases I've seen them trying to read the settings on the tty they
are started from, which doesn't work at all when they're started from
the window/session manager and may give very weird and inconsistent
results in other cases (e.g. you give 'xterm &' on the commandline -
will the xterm manage to read the "cooked" settings that are in effect
when the shell runs a command, or get the "raw" ones that your shell
uses because it has taken control of the tty again - it's a classical
race condition).

You don't see this problem with tcsh because tcsh has a design decision
to always set the tty in a "sane" mode - both for itself and for the
commands it runs, to the point that it will clean up the mess left by a
program that has set the tty in "raw" or non-blocking mode and then
crashed. It's the only shell that does this AFAIK. Of course it also has
tons of #ifdef'ed code to get this right on all kinds of weird OSes.

I'm not sure what xterm currently does, and for some reason xterm keeps
changing - but at least it provides a way for you to control it: Look
into the -tm option and/or the 'ttyModes' resource. I realize that this
doesn't cover the 'xinit&exit' case, and don't really know why that
triggers the problem - but I gather that that's not your actual problem.

--Per Hedeland
per.DeleteThis@hedeland.org
 >> Stay informed about: Zsh and control-t 

Den Tue, 07 Nov 2006 00:11:48 +0000, skrev Per Hedeland:

> I assume you refer to the status report that ctrl-t gives when you have
> a program running in the foreground, rather than the transpose-chars
> editing function that it provides at the prompt? If so, I can reproduce
> the problem by firing up 'xterm -e zsh' (I have tcsh as my login shell).

Yes, indeed it's the status report I refer to.

> Did you try looking at 'stty -a', and doing 'stty status ^t'? For me,
> the former shows 'status = <undef>' when the problem is present, as
> opposed to 'status = ^T' when it isn't, and the latter fixes it.

Indeed it does, adding a check for TERM=xterm in .zshrc and if so
running stty status ^T solves the problem. Thank you very much for
suggesting this.

> You don't see this problem with tcsh because tcsh has a design decision
> to always set the tty in a "sane" mode - both for itself and for the
> commands it runs, to the point that it will clean up the mess left by a
> program that has set the tty in "raw" or non-blocking mode and then
> crashed. It's the only shell that does this AFAIK. Of course it also has
> tons of #ifdef'ed code to get this right on all kinds of weird OSes.

When messing about with this, I did setup tcsh and intended to use it
until a solution appeared. I got it fairly alike what I like to have
my shell look like with help of implicitcd and such. Well, I guess it
doesn't hurt to know a little about tcsh aswell.

> I'm not sure what xterm currently does, and for some reason xterm keeps
> changing - but at least it provides a way for you to control it: Look
> into the -tm option and/or the 'ttyModes' resource. I realize that this
> doesn't cover the 'xinit&exit' case, and don't really know why that
> triggers the problem - but I gather that that's not your actual problem.

Allright, I'll make a note of this in case I need it later, for now,
I'll just use the above solution and run stty status ^T from .zshrc
whenever it detects that $TERM is xterm.

Again thank you very much for your kind help.

Regards Eivind

--
_
//
_ //
\\ //
\\//
\/

Eivind E
 >> Stay informed about: Zsh and control-t 

In article
Eivind E writes:
>Den Tue, 07 Nov 2006 00:11:48 +0000, skrev Per Hedeland:
>
>> I'm not sure what xterm currently does, and for some reason xterm keeps
>> changing - but at least it provides a way for you to control it: Look
>> into the -tm option and/or the 'ttyModes' resource. I realize that this
>> doesn't cover the 'xinit&exit' case, and don't really know why that
>> triggers the problem - but I gather that that's not your actual problem.
>
>Allright, I'll make a note of this in case I need it later, for now,
>I'll just use the above solution and run stty status ^T from .zshrc
>whenever it detects that $TERM is xterm.

You could do it regardless of $TERM, doesn't hurt to set it even if it's
right to start with:-) - however you need to make sure that you only do
this for interactive and/or tty-using shells, otherwise the spurious
error message will break e.g. scp. In .[t]cshrc the canonical way to
check for an interactive shell is to use 'if ( $?prompt ) ...', not sure
what the zsh equivalent is (actually I'm not even sure whether zsh
sources .zshrc at all for non-interactive shells...).

--Per Hedeland
per.RemoveThis@hedeland.org
 >> Stay informed about: Zsh and control-t 

Den Tue, 07 Nov 2006 23:23:49 +0000, skrev Per Hedeland:

>>Allright, I'll make a note of this in case I need it later, for now,
>>I'll just use the above solution and run stty status ^T from .zshrc
>>whenever it detects that $TERM is xterm.
>
> You could do it regardless of $TERM, doesn't hurt to set it even if it's
> right to start with:-) - however you need to make sure that you only do
> this for interactive and/or tty-using shells, otherwise the spurious
> error message will break e.g. scp. In .[t]cshrc the canonical way to
> check for an interactive shell is to use 'if ( $?prompt ) ...', not sure
> what the zsh equivalent is (actually I'm not even sure whether zsh
> sources .zshrc at all for non-interactive shells...).

I've never thought about this situation before, but it seems I didn't
have problems coming my way. After looking a bit in the manual, it seems
that zsh first read /etc/zprofile or $HOME/.zprofile, and then reads
/etc/zshrc and $HOME/.zshrc only if the shell is interactive.

Neither /etc/zprofile nor $HOME/.zprofile exist, so they should be fine.
So now I know why scp has never given me problems, hehe.

Regards Eivind
--
_
//
_ //
\\ //
\\//
\/

Eivind E
 >> Stay informed about: Zsh and control-t