From owner-freebsd-stable@FreeBSD.ORG Tue Apr 17 22:47:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 449BD106566C for ; Tue, 17 Apr 2012 22:47:13 +0000 (UTC) (envelope-from carlj@peak.org) Received: from redcondor2.peak.org (redcondor2.peak.org [69.59.192.56]) by mx1.freebsd.org (Postfix) with ESMTP id 135388FC12 for ; Tue, 17 Apr 2012 22:47:13 +0000 (UTC) Received: from zmail-mta02.peak.org ([207.55.16.112]) by redcondor2.peak.org ({6c724cae-de34-4c5f-b615-3072b86419fa}) via TCP (outbound) with ESMTP id 20120417224348828 for ; Tue, 17 Apr 2012 22:43:48 +0000 X-RC-FROM: X-RC-RCPT: Received: from birch.localnet (unknown [207.55.106.132]) by zmail-mta02.peak.org (Postfix) with ESMTPSA id 5B3EA6C98C0 for ; Tue, 17 Apr 2012 15:43:47 -0700 (PDT) Received: from oak.localnet (oak.localnet [192.168.193.34]) by birch.localnet (Postfix) with ESMTP id B13A155E22 for ; Tue, 17 Apr 2012 15:43:45 -0700 (PDT) Received: from oak.localnet (localhost.localnet [127.0.0.1]) by oak.localnet (Postfix) with ESMTP id 4E58AC195 for ; Tue, 17 Apr 2012 15:43:45 -0700 (PDT) Received: (from carlj@localhost) by oak.localnet (8.14.4/8.14.4/Submit) id q3HMhj53014308; Tue, 17 Apr 2012 15:43:45 -0700 (PDT) (envelope-from carlj@peak.org) X-Authentication-Warning: oak.localnet: carlj set sender to carlj@peak.org using -f From: Carl Johnson To: freebsd-stable@freebsd.org References: <20120417182242.GA58449@icarus.home.lan> <20120417195115.GA60447@icarus.home.lan> <20120417200252.GA60718@icarus.home.lan> Mail-Followup-To: freebsd-stable@freebsd.org Date: Tue, 17 Apr 2012 15:43:45 -0700 Message-ID: <87bomq3roe.fsf@oak.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: top not restoring terminal echo/icanon correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 22:47:13 -0000 Jeremy Chadwick writes: > On Tue, Apr 17, 2012 at 12:51:15PM -0700, Jeremy Chadwick wrote: >> On Tue, Apr 17, 2012 at 11:22:42AM -0700, Jeremy Chadwick wrote: >> > (Please keep me CC'd as I'm not subscribed to the list) >> > >> > I'd like to request that folks running RELENG_8 (and RELENG_9, though I >> > do not use it) please check the behaviour of their terminal after each >> > of following commands are run (check terminal after each command): >> > >> > top -a (press "q" after 1 screen refresh) >> > top -b >> > >> > If you find that your input characters in your shell aren't being echo'd >> > back after one of the above commands, blindly type "stty icanon echo" >> > and hit and things should be back to normal. >> > >> > What I'm looking for is confirmation from others of the problem. >> > >> > Also very important: please provide uname -a output, specifically world >> > rebuild date. It greatly matters, because a commit was recently done >> > where now -b functions fine (was previously busted in this way), but now >> > -a behaves like -b did. So src/world date matters. >> > >> > All of this is documented in PR 161739. I urge anyone experiencing this >> > problem to read that PR in full, as I spent many hours today writing a >> > debug routine to confirm that top is sometimes not calling tcsetattr() >> > with the original terminal parameters when it exits, and what the >> > condition seems to be. >> > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/161739 >> > >> > Finally, if anyone want to tackle the problem (work out the logic bug >> > that is in there which causes it), please be my guest. I have other >> > things going on right now (doctors appointments) so I don't have as much >> > time as I'd like. >> > >> > Thanks everyone. >> >> Thanks to all those who have responded, including kib@. >> >> The problem is very odd and appears specific to the bash shell, but >> only "somewhat". Below is a part of what I sent kib@ on the matter. >> A chart showing what I've found: >> >> Location Username TERM Shell bug? >> ============================================================= >> VGA console root cons25 /bin/csh no >> VGA console jdc cons25 /usr/local/bin/bash no >> SSH (PuTTY) root xterm /bin/csh no >> SSH (PuTTY) jdc xterm /bin/csh no >> SSH (PuTTY) jdc xterm /usr/local/bin/bash yes >> ============================================================= >> >> In the last case (and only that case): if I move my dotfiles (.bashrc >> and .bash_profile) aside and log in (SSH), top behaves normally. >> Naturally this made me think "something is wonky with my dotfiles!"... >> >> But the problem *doesn't* happen if my dotfiles are intact and I >> log in via VGA console (cons25) as myself with a bash shell. So it's >> almost like there's some bizarre combination of things that causes this >> problem. >> >> I'll continue to try and narrow it down. > > Boy this is a weird one. > > In my .bashrc I've been using the following statement to show all > arguments and set the update interval to 1 second: > > export TOP="-a -s 1" > > Removing this completely and logging back in results in no problems > when running "top" in any way (top -a, top -s 1, or top -a -s 1). > > However, the problem I describe with icanon/echo never getting restored > rears its ugly head when running "top -a -b", but only under bash > (with no dotfiles too). It never happens under csh. > > I can also reproduce this on VGA console when logged in (regardless of > user), e.g. log in as root (get csh shell), run bash, "top -a -b", bam, > issue happens. > > I don't know what's different about the two shells at this level that > would cause oddities like this, but um, yeah..... *blink* I checked /bin/sh and it shows the same problem as bash, but pdksh and csh don't have any problem. Running stty -a shows that all have -icanon and -echo after runnin top, but csh and pdksh appear to ignore those settings. I have tried in xterm and console and it doesn't make any difference. I tested both on 8.1-RELEASE and 9.0-RELEASE (without ksh). These are unmodified systems with GENERIC kernels, so the problem is not new. -- Carl Johnson carlj@peak.org