From owner-freebsd-current@FreeBSD.ORG Fri Oct 21 06:40:06 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 993BE106564A for ; Fri, 21 Oct 2011 06:40:06 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2A28FC1B for ; Fri, 21 Oct 2011 06:40:06 +0000 (UTC) Received: by ywm3 with SMTP id 3so4586584ywm.13 for ; Thu, 20 Oct 2011 23:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=iDLWmETLtjxCNQCwm33RdN913CA/Q0wJzkJuLt2Gfwc=; b=QNJ4Ib2agfR0fMkjiBLU+aUtAe9bylNTOWrWUK9+rNT9Mu6mZ0ixLruebs9AHkkKBP +AM3tqpZf3E/lAwrfYN++E3SMvWYEionFKTvKuMIB7nJMVZQrPo2kXMtriKnUsYSp7Td 1bPcauI3/NkOkjX/zUS8V2vn+dQ5jqhz3BEDs= MIME-Version: 1.0 Received: by 10.182.36.36 with SMTP id n4mr842509obj.16.1319179205521; Thu, 20 Oct 2011 23:40:05 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Thu, 20 Oct 2011 23:40:05 -0700 (PDT) Date: Thu, 20 Oct 2011 23:40:05 -0700 Message-ID: From: Garrett Cooper To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: 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 06:40:06 -0000 If I fire up an xterm without setting TERM={ansi,vt100,xterm}, etc, xterm wraps my command output to 80 columns, even if I resize the window to something larger, issue reset (which I thought was supposed to fix the console settings by rescanning the window size, etc). I thought that SIGWINCH was also supposed to force a proper rescan if the terminal application had a handler installed. This isn't new (I've been seeing it since 8.x or 9.x, but it's just gotten to the point where it irritates me enough that I thought I should check around first). Example output of the column wrapping is something like: [gcooper@bayonetta ~]$ aaaaaaaaaaaaaaaata ~]$ echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa It doesn't happen all of the time, but it happens frequently -- sometimes the result of me reading a unicode encoded locale file using standard utilities like less (this really forks xterm, the shell, etc), or by just printing it out on the console via svn diff; other times it just seems to happen for no apparent reason in newly created xterms (which is befuddling). Doing: export TERM=vt100 export TERM=ansi export TERM=xterm in one xterm seems to have remedied the problem when I tried it, but I'm not sure why. The way I currently do things when I log in interactively is I exec from sh to bash (bash has a history built-in, which I use extensively). More details are provided below. My questions are: 1. Has anyone else seen this? 2. If so, do you have a reproducible testcase that isolates this behavior? Thanks! -Garrett 1. My login shell is /bin/sh. 2. Relevant blurbs from /etc/ttys are as follows: ttyv0 "/usr/libexec/getty Pc" xterm on secure ttyv1 "/usr/libexec/getty Pc" xterm on secure ttyv2 "/usr/libexec/getty Pc" xterm on secure ttyv3 "/usr/libexec/getty Pc" xterm on secure ttyv4 "/usr/libexec/getty Pc" xterm on secure ttyv5 "/usr/libexec/getty Pc" xterm on secure ttyv6 "/usr/libexec/getty Pc" xterm on secure ttyv7 "/usr/libexec/getty Pc" xterm on secure ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure 3. I haven't modified /etc/termcap* at all. 4. Relevant blurb from .profile: # set ENV to a file invoked each time sh is started for interactive use. ENV=$HOME/.shrc; export ENV 5. Relevant blurb from .shrc: BASH=/usr/local/bin/bash if [ -x $BASH -a "$SHELL" != "$BASH" ] ; then # bash won't set this var if it's already set in the env. export SHELL=$BASH $BASH -c true && exec $BASH fi