From owner-freebsd-current@FreeBSD.ORG Fri Oct 21 07:52:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 125241065675 for ; Fri, 21 Oct 2011 07:52:19 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id C241A8FC12 for ; Fri, 21 Oct 2011 07:52:18 +0000 (UTC) Received: by yxn16 with SMTP id 16so4624258yxn.13 for ; Fri, 21 Oct 2011 00:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9OB/RFwfDTBj7PWY5IxHQEDvNFdROzURWJQx6z0rD84=; b=U63cyeKGT8JQWBgZA5dZ6LGqTrg9+tFHNY9VNDGKlpFDsH21JX5KemucZuUIk0J5t9 4bHM5WQWKZ8lsGHCa/JqiYL6125H1YPqg876zqrj8RZMKWRFV0PyXGrYfo12xp+AeY0N TJDITPBO05qZSU1wv758h+JKxn5PlpU+KVyDQ= MIME-Version: 1.0 Received: by 10.182.36.36 with SMTP id n4mr887680obj.16.1319183538018; Fri, 21 Oct 2011 00:52:18 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Fri, 21 Oct 2011 00:52:17 -0700 (PDT) In-Reply-To: References: <20111021065912.GE1874@hoeg.nl> <20111021070839.GF1874@hoeg.nl> Date: Fri, 21 Oct 2011 00:52:17 -0700 Message-ID: From: Garrett Cooper To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Not setting TERM explicitly wraps commands at 80 columns with nested shells in xterms using sh + bash? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 07:52:19 -0000 On Fri, Oct 21, 2011 at 12:15 AM, Garrett Cooper wrote= : > On Fri, Oct 21, 2011 at 12:08 AM, Ed Schouten wrote: >> * Garrett Cooper , 20111021 09:00: >>> On Thu, Oct 20, 2011 at 11:59 PM, Ed Schouten wrote: >>> > Hi Garrett, >>> > >>> > * Garrett Cooper , 20111021 08:40: >>> >> =A0 =A0 If I fire up an xterm without setting TERM=3D{ansi,vt100,xte= rm}, >>> >> [...] >>> > >>> > So what's the idea behind this? Why not just set TERM properly? >>> >>> It is set properly though -- that's the confusing part: >>> >>> $ echo $TERM >>> xterm >> >> Oh, okay. So you mean "If I fire up an xterm without changing the >> default TERM, [...]", right? >> >> Can you check whether `stty size' does return the correct numbers? That >> way we can determine if it's a problem in xterm, your shell (or maybe >> the kernel). Thanks! > > I'll run that in the next window I find that's acting funky. > Unfortunately my system is behaving properly right now. > Thanks for the tip :)! Here's an example: # Increased the window size here. [gcooper@fallout ~]$ uname -a FreeBSD fallout.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226332M: Wed Oct 12 22:48:55 PDT 2011 root@fallout.local:/usr/obj/usr/src/sys/FALLOUT amd64 [gcooper@fallout ~]$ stty size 60 156 [gcooper@fallout ~]$ exit Connection to fallout.local closed. [gcooper@bayonetta ~]$ uname -a FreeBSD bayonetta.local 9.0-BETA2 FreeBSD 9.0-BETA2 #0 r225653M: Tue Sep 20 08:36:49 PDT 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 [gcooper@bayonetta ~]$ stty size 60 156 # Line was wrapping in above uname -a. [gcooper@bayonetta ~]$ ssh starr-wireless # Increased the window size here from the default. starr:~ gcooper$ uname -a Darwin starr.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 starr:~ gcooper$ echo $TERM xterm starr:~ gcooper$ logout Connection to starr-wireless.local closed. [gcooper@bayonetta ~]$ uname -a FreeBSD bayonetta.local 9.0-BETA2 FreeBSD 9.0-BETA2 #0 r225653M: Tue Sep 20 08:36:49 PDT 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 ssh'ing in to a remote terminal and resizing it is an example I could think of that's semi-deterministic. It seems like it's an application bug or OS caveat; I'm not sure if anything can really be done about it because the signal might be masked in ssh when it connects to the other side -- would have to check to be sure. Thanks, -Garrett