From owner-freebsd-arch@FreeBSD.ORG Sun Sep 7 00:01:53 2014 Return-Path: Delivered-To: freebsd-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 636A75A6 for ; Sun, 7 Sep 2014 00:01:53 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 05F411561 for ; Sun, 7 Sep 2014 00:01:52 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s8701ntU089040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 6 Sep 2014 18:01:49 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s8701nF0089037; Sat, 6 Sep 2014 18:01:49 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 6 Sep 2014 18:01:49 -0600 (MDT) From: Warren Block To: Warner Losh Subject: Re: Improving /etc/motd and ANSI In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 06 Sep 2014 18:01:49 -0600 (MDT) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 00:01:53 -0000 On Sat, 6 Sep 2014, Warner Losh wrote: > On Sep 6, 2014, at 5:01 PM, Warren Block wrote: > >> As an experiment, this version uses ANSI underline escape sequences: >> http://www.wonkity.com/~wblock/motd/motd.ansi >> >> That reads better, is less likely to be misunderstood, and will work on normal consoles and most terminal emulations in use today. >> >> It will not display correctly on things that do not understand VT100/VT220 or ANSI codes, but I suspect that is a vanishingly small portion of the user base. Those users are also likely to be familiar with the problem. >> >> Is there some showstopper reason not to commit this ANSI version? > > It embeds the notion that all the world is a VT100 and interprets the ANSI escape code identically. > > In years past, this definitely wasn?t the case. But in those years we had many different breeds > of terminal roaming the earth, and these terminals were all somewhat different (even at the same > installation you?d have a heterogeneous setup because different departments got different > vendors to supply their gear). These changes would break that. Well, the stock motd would not display correctly. > One of the nice things about > Unix has always been it played very nicely in a heterogeneous environment and all fancy > smancy curses action was done through a layer of indirection so it would work everywhere, > unlike VMS where things were more hard-coded and it was always hard to use non-DEC > gear. > > It also assumes that all users want to see the fancy ANSI version with underlines and such. While > rather innocuous, one needn?t look any farther than gnu?s color ls to see what madness lies not > too far down this path. This assumption was already made in the previous motd, which used troff-style single-quotes to distinguish commands. We've all seen instructions like 'Type "search terms" (without the quotes)' that manage to contradict themselves within the same sentence. > Finally, console scraping code may be affected in some minor way and you?ll wind up with > text that looks weird. Again, just for /etc/motd, unless the escape codes do bad things to some types of emulations. > None of these are huge show-stoppers. But it is a very nice camel?s nose at the moment, and > I?d hate to see the rest of the camel?[*] I agree, but the only other real out-of-band delimiters we have are whitespace. Vertical space is limited by the 24/25 lines (less prompt) of a standard terminal. (Note how I sneakily did not say that was due to the VT100...except just there, but ignore that.) As another experiment, here is a version using whitespace: http://www.wonkity.com/~wblock/motd/motd.whitespace While it's not as clear as the ANSI version, it is better than the troff-style quotes version. Still requires 7-bit ASCII, though. :)