From owner-freebsd-arch@FreeBSD.ORG Fri Feb 21 19:14:40 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BDFF4DB for ; Fri, 21 Feb 2014 19:14:40 +0000 (UTC) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0FBB128D for ; Fri, 21 Feb 2014 19:14:39 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id ma3so1206726pbc.30 for ; Fri, 21 Feb 2014 11:14:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Gko0uBJCnRlEFu41BCoMKrehMYS04gbt4roy7IP26Rw=; b=SlREFHgS79QaBLJ3erHXGmQIusv4oDb2Fq5fmgVWBE6KUwBt2uwhzdD1dCGpEOXI2f AJZzdmFoErZJU/k4m7vzA8ss+O6DkvR3c5vaRQMnSraBFscJ6W82C7/6+FsVZmU16a2G rPw2xlmOQGWKgZ87PnriY3KP/AkpTPi73d0W4vPIcVqnmZOnkE1mGnQ3qbDGLhaXADrO CecoNqV7SWdkaf7Aw2E1C2XcI0JTo0O9NMt/njNBASbn61b6+OUwn9yeUICLyGBHft3S hS8nlLUwDIHeKe3ggSHyqOoC+xTM8sbhCuoStygjfa3mTBR3zyH1DBc+vT00we8PMl+O C1Rw== X-Gm-Message-State: ALoCoQnV5xQI/iON1DBSetTuF3P09QQo6qY6MgxtjViFahl2WzkeOFKNLX+j3ftJD4RAVrn1DSEj X-Received: by 10.69.0.39 with SMTP id av7mr11024102pbd.4.1393010078988; Fri, 21 Feb 2014 11:14:38 -0800 (PST) Received: from macmini.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id cz3sm23907917pbc.9.2014.02.21.11.14.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 11:14:37 -0800 (PST) Subject: Re: terminfo Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1392997589.1145.91.camel@revolution.hippie.lan> Date: Fri, 21 Feb 2014 12:14:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5304A0CC.5000505@FreeBSD.org> <1392997589.1145.91.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: Ed Schouten , Bryan Drewery , arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:14:40 -0000 On Feb 21, 2014, at 8:46 AM, Ian Lepore wrote: > On Fri, 2014-02-21 at 13:05 +0100, Ed Schouten wrote: >> Hi Bryan, >>=20 >> On 19 February 2014 13:17, Bryan Drewery = wrote: >>> Why do we not use terminfo? Our termcap is quite aged and missing a = lot >>> of modern terminals/clients. >>=20 >> It is true that our termcap is quite aged, but the fact is, once you >> add entries for a certain terminal, there's little need to update it >> after that. ncurses itself is not really a moving target. What kind = of >> modern terminals/clients are missing? >>=20 >>> Using terminfo would allow us to use the already well maintained = database from ncurses. Is it just a matter of someone doing the work or = are there other reasons? >>=20 >> It's just a matter of someone doing the work. It would be nice if we >> ever made this change. >>=20 >> On the other hand, I might have a radical point of view here: maybe = we >> could consider taking the approach of sticking to termcap and >> installing /etc/termcap.small as the system's default termcap. Or >> maybe patch up our termcap routines to just hardcode the sequences. >>=20 >> I won't deny that termcap was really useful at one point in time, but >> let's be honest: the variety of terminals out there has massively >> dropped over time. Terminal emulation has become a solved problem. As >> of FreeBSD 9, syscons supports all the sequences described in >> xterm-256color, though it isn't able to print more than 8 colours, >> which is why we use TERM=3Dxterm. Tools like screen, tmux, etc., they >> use a different TERM type, but this is mainly used to detect whether >> the process is running inside of screen or tmux. It does not strongly >> affect the kinds of sequences that are being emitted. They work >> perfectly fine if you just set TERM to xterm or xterm-256color. >>=20 >> I suspect the following logic would be sufficient for at least 99.5% >> of our users: >>=20 >> if $TERM contains 256 >> use xterm-256color >> else >> use xterm >>=20 >> It's a shame I am so short on time nowadays, but I think it would = make >> so much sense to just come up with some kind of document that >> standardizes the intersection of the features supported by most = common >> terminal emulators and get it rubber stamped by the maintainers of >> various terminal emulators. If it turns out some kind of terminal >> emulator does something in a non-standard way, we can just slap this >> document in the author's face. That would not only benefit FreeBSD, >> but also most of the other flavours of UNIX. >>=20 >> $TERM should die. >>=20 >=20 > All of that seems to assume that every terminal actually being used in > the world today is either xterm or something that emulates it. Try > using vi on a serial console on an embedded ARM board and you'll get a > quick frustrating lesson in how not-xterm a serial console is. I've = yet > to find a combo of serial comms program and TERM setting that actually > works well and lets you edit a file with vi. I'd go so far as to say that no such subset actually exists. There's = nothing wrong with TERM, and it has abstracted away all the differences = for many, many years. I've had good luck with TERM=3Dvt100 in those situations, but I use tip = and apart from eating ^P it does a good job of being transparent = enough... Let's not kill $TERM... There seems to be no benefit, and lots of pain. Warner=