Zsh Mailing List Archive
Messages sorted by:
Re: Problem with early key strokes at startup
- X-seq: zsh-users 22519
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Sebastian Gniazdowski <psprint3@xxxxxxxxxxxx>, zsh-users@xxxxxxx
- Subject: Re: Problem with early key strokes at startup
- Date: Tue, 28 Feb 2017 13:16:18 -0800
- Authentication-results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=brasslantern-com.20150623.gappssmtp.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=NVGKRiBdsayJa2Vf8dQnbEMsrqtgAA0xh/k9Jg7VS3w=; b=x4qJY9Mqpm0ugymemHlkwzfbQZ/NvwdvVyYtx7c70IoXrjfNO2cii1D6c6ytVem+tp cRHJ9O2KjJPgLdhmGnG0soWrpzl5pvipvM5nrdeU/3eQ4lmxr4W85SRtEFB7d7KKfsEn r+gyQXOCUH0mXZkS2FBliRj0EGoH5mSi/Leplz9WBXb4i/QcsGuH3mxKNwfZcldO69cT nqUyYAqFIHQS24h0CFWEsgJBj21SeqBSuIP9T7UpEVugSzUpcqPs1vV2ZtcXM7S56zEZ 2+UGDNx1hk7qOfrw0i3gjGOwpq7TSqAnv+QZmoLuuLpPBuFHajF8masMzV6tCRlcDSGN Gyog==
- In-reply-to: <1488277394.2867401.895300784.0A2F382A@webmail.messagingengine.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <1488277394.2867401.895300784.0A2F382A@webmail.messagingengine.com>
On Feb 28, 2:23am, Sebastian Gniazdowski wrote:
} when I startup zsh to just run a tool with Ctrl-O Ctrl-P, I get "^P" or
} "^O^P" printed instead:
} Maybe it's easy to fix?
Unfortunately not. Typeahead (characters present on stdin before the
shell is ready to read them) is exceptionally difficult to deal with
in a portable way. There are several lengthy comments about this in
the C code in shell startup and zle.
In this specific case, the problem is likely ctrl-O. If you look at
output of "stty -a" you'll probably find ^O bound to something called
"flush" which is annoyingly undocumented but means to throw away all
previous input that has not already been read by whatever is connected
to the TTY device. This is likely being seen and intepreted by the
terminal driver before zsh has a chance to change the state to "raw"
input, and there's absolutely nothing we can do about *that*.
If this is a new shell being spawned by an already-running zsh, you
can try playing around with the value of the STTY environment variable
to disable some of the special tty driver settings ahead of time (see
the zsh manual for how STTY works). If it's not zsh you'll have to
figure out a different way to frob the driver -- and either way I do
not promise it'll work.
Messages sorted by: