Date: Sat, 6 Sep 2014 18:01:49 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arch@FreeBSD.org Subject: Re: Improving /etc/motd and ANSI Message-ID: <alpine.BSF.2.11.1409061727380.69004@wonkity.com> In-Reply-To: <B16D580C-1337-40B2-8DC2-AEF63D0A4027@bsdimp.com> References: <alpine.BSF.2.11.1409061646170.69004@wonkity.com> <B16D580C-1337-40B2-8DC2-AEF63D0A4027@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 6 Sep 2014, Warner Losh wrote: > On Sep 6, 2014, at 5:01 PM, Warren Block <wblock@wonkity.com> 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. :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.11.1409061727380.69004>