From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id a94ce320 for ; Mon, 16 Sep 2019 22:49:03 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 44DA09BFD6; Tue, 17 Sep 2019 08:49:02 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 7BB5B9479A; Tue, 17 Sep 2019 08:48:37 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ufIyXT1v"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 5628E9479A; Tue, 17 Sep 2019 08:48:34 +1000 (AEST) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by minnie.tuhs.org (Postfix) with ESMTPS id D59D994794 for ; Tue, 17 Sep 2019 08:48:33 +1000 (AEST) Received: by mail-pg1-f181.google.com with SMTP id a24so833642pgj.2 for ; Mon, 16 Sep 2019 15:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=4qHmEEN9gvy5bcB9VyE3XrrheJYjj9Yw8ttwgCCke4U=; b=ufIyXT1vl+2iDGb7d6DkCHJJN+DvE4kCnWIAy1cCToRG8CZV8/AvoeIP4NEfWnvQxX g7aQRUN2Bm8xUiADbvruFSCKcgE8UCDsJrAyFmtow8jahbTKq/trvfTFzssF8LcGwUfx mPJoDsFfn833BHBISYd6UmCn1MPzZc2YShMhkM1gNVS0cDWvyVCVwTiZg//W04Z1BQxJ KBE3EM1sQbWnZ2VpEWVbgZIPD4oPCYShZttsK/mcxIX1HY4Ufz5JTzYlpntRf+agRwZw ALbfMkAeYeaxdwhOkvF3CWscAwZwXxn00pyN6K/AGKK5+vZaIWLPw5YLSmHKUT0KQnuK gVPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=4qHmEEN9gvy5bcB9VyE3XrrheJYjj9Yw8ttwgCCke4U=; b=WjLv+wddk3X0HGcpoyhPFR2YP8nXCtik1/qYFojcIIrF8B8CQ35Jkgg71T0jynq+c1 JTt8xuVZ41GfPUT0nK5XWLNdu/jVsxnB4FkvdU2xHP4xiSt7+aHZfVkuImB7b0AHpwoQ 6Hw//7VbpmoJDEaTCASMnIbYxZkys1B1CP1a6YkGG9mWX6nsigKwXQCyfVnzbJ8pXyKv rWV1bN5UR0A7N19IjtUNUn0g6nj6ChPYN1dklmQzUM47Jw++9oQe5cqygxOQgjV62wym goqssGvBKaCDsU5Pr4XhNIQrOAEjfmjMyRQfPW3t9tiRgg414tA+Lu6n6UtOuGeZbcqB twuA== X-Gm-Message-State: APjAAAWEtOSR4Bv+j1hksYGx0nBOCHo5Zm0++4wNGmTyPDmKUf4sWlaw A2sD7Q00WiSHEXMkIGcMEQW1xLlJ X-Google-Smtp-Source: APXvYqwuT0qPSNE7t1u4AXNbkeqbbxBw+aYB2qmPsVFmW9pZ1P0kxjiuN1xsYnmYQw64uMEM47QWNg== X-Received: by 2002:a63:358a:: with SMTP id c132mr400844pga.32.1568674112623; Mon, 16 Sep 2019 15:48:32 -0700 (PDT) Received: from localhost.localdomain ([1.129.140.90]) by smtp.gmail.com with ESMTPSA id 69sm141450pfb.145.2019.09.16.15.48.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Sep 2019 15:48:31 -0700 (PDT) Date: Tue, 17 Sep 2019 08:48:28 +1000 From: "G. Branden Robinson" To: tuhs@tuhs.org Message-ID: <20190916224825.keswxb7sh224tpky@localhost.localdomain> References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> <20190916023738.F34E81570CE9@mail.bitblocks.com> <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain> <201909162047.x8GKlSbX001635@darkstar.fourwinds.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3tnk6uehq5jkdmfp" Content-Disposition: inline In-Reply-To: <201909162047.x8GKlSbX001635@darkstar.fourwinds.com> User-Agent: NeoMutt/20180716 Subject: Re: [TUHS] better ways and termcap vs. terminfo for commentary) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --3tnk6uehq5jkdmfp Content-Type: multipart/mixed; boundary="aaedtv2rjj6n5nei" Content-Disposition: inline --aaedtv2rjj6n5nei Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable At 2019-09-16T13:47:27-0700, Jon Steinhart wrote: > G. Branden Robinson writes: > > _info_nol "> \033[46m\033[30mSTATUS:\033[0m " > > > > Why write something portable when you can be "close to the metal"? :-/ > > > > I gently steer people to better ways when the occasion presents itself. [...] >=20 > We can have an interesting discussion of the definition of "better ways". Here I think we have a layering violation. Why on earth would a CPU microarchitectural flaw detector need to know or care about the details terminal control sequences? _Anything_ that provides an abstraction of the terminal is an improvement on the above. > I see termcap as a great solution for the days in which there was > little standardization. Setting aside the specificity of "termcap", sure. Something was needed to gather up the absurd efflorescence of implementation details among hardware terminals and present programmers (and users struggling to interact with the system) something simpler and more intention-oriented. You want "bold, if the device can do it", not a giant switch statement encompassing '\033[1m', '\033ya', '\033yA', '\033<', '\2331m', '\033[1m' with a parameter after it, '\033[7m', \033[=3D15F', ... And if the device _can't_ do bold, you want to be able to decide for yourself whether you don't care if the boldness is left out, or be able to query that interface layer about it and program your own fallback (use indentation, full capitalization, an "IMPORTANT:" prefix, etc.) in the event the capability is absent. > But it's probably pretty hard to find a non-conforming terminal > nowadays so I think that it's better to avoid obfuscation. I've attached an example of the sort of thing I do. It has a lot of comments, so is inappropriate for inlining on a list full of Unix grognards. ;-) > Were it me I would have a comment that referenced the page and section > number in the standard. This is a good idea, but its benefit can be limited for ISO standards, which are often paywalled. In this case the controlling standard is ISO 6429. Fortunately it's largely parallel to ECMA-48 which is freely available. In this case you want ECMA-48, pp. 61-63[1]. > Since we like debating the merits of old technology, somebody can kick > off a termcap versus terminfo discussion :-) terminfo is better than termcap in the same way that Fortran 77 is better than Microsoft BASIC for 8-bit microcomputers--identifier length. Fortran 77, 6 characters. MS BASIC, 2. termcap, 2. terminfo, 5. Of course, that argument could be turned around rather precisely for those who prize "terseness". I reckon one of the reasons that function names in the Unix kernel were allowed to grow as long as they did--while still being limited to 6 characters for linkage reasons--was because the precious space of 1- and 2-letter external identifiers was held sacrosanct for user programs. There but for that grace would 'swtch()' have gone as 'sw()', and 'creat()' as 'cr()', perhaps. No such considerations availed in the namespace for executable programs. ;-) Regards, Branden [1] https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.= pdf --aaedtv2rjj6n5nei Content-Type: application/x-sh Content-Disposition: attachment; filename="example.sh" Content-Transfer-Encoding: quoted-printable # Set up terminal capabilities (for displaying in bold and colors).=0A#=0A#= See terminfo(5) for a list of terminal capability strings.=0A#=0A# tput re= turns an empty string (and exits with a nonzero status) for=0A# unsupported= string capabilities, and -1 for unsupported integer=0A# capablilities.=0AB= OLD=3D$(tput bold) || BOLD=3D=0ANORMAL=3D$(tput sgr0) || NORMAL=3D=0ANCOLOR= S=3D$(tput colors)=0A# If the terminal doesn't support color at all, these = will remain null.=0ARED=3D=0AGREEN=3D=0AYELLOW=3D=0A=0A# We want different = foreground color numbers if we have a terminal capable of=0A# more than 8, = because generally the contrast is bad if we use the low-numbered=0A# colors= (bold helps, but only so much). On terminals truly capable of only 8=0A# = colors, we have to rely on the implementation to provide good contrast.=0Ai= f [ -n "$NCOLORS" ]=0Athen=0A if [ $NCOLORS -gt 8 ]=0A then=0A = RED=3D$(tput setaf 9)=0A GREEN=3D$(tput setaf 10)=0A YELLOW= =3D$(tput setaf 11)=0A CYAN=3D$(tput setaf 14)=0A # This is an ex= act equality match on purpose. tput will report -1 for a=0A # truly mon= ochrome terminal and in that case we don't want to mess with=0A # the se= taf capability at all.=0A elif [ $NCOLORS -eq 8 ]=0A then=0A R= ED=3D$(tput setaf 1)=0A GREEN=3D$(tput setaf 2)=0A YELLOW=3D$= (tput setaf 3)=0A CYAN=3D$(tput setaf 6)=0A fi=0Afi=0A=0A# Emit d= iagnostic message.=0A# @params: a set of strings comprising a human-intelli= gible message=0A#=0A# Display the diagnostic message itself in bold.=0A_pri= nt () {=0A echo "${PROGNAME:-(unknown program)}: $BOLD$*$NORMAL"=0A}=0A= =0A# Emit debugging message to standard error.=0A# @params: a set of string= s comprising a human-intelligible message=0Adebug () {=0A _print "${CYAN= }debug: $*" >&2=0A}=0A=0A# Emit informational message to standard error.=0A= notice () {=0A _print "${GREEN}notice: $*" >&2=0A}=0A=0A# Emit warning m= essage to standard error.=0Awarn () {=0A _print "${YELLOW}warning: $*" >= &2=0A}=0A=0A# Emit error message to standard error.=0Afail () {=0A _prin= t "${RED}error: $*" >&2=0A}=0A --aaedtv2rjj6n5nei-- --3tnk6uehq5jkdmfp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAl2AETAACgkQ0Z6cfXEm bc6ifw//d5VGSTwLf35H+PEavVIbuDMiFliDQlU2Xnq06/CDllCtdgKvIVVZ7gQm NH+7sTvT6GvyPQGRlSDaR+ah3GJUyEZGTtBzDI20D+esbDSrZGqaikdk31l7eNhO TMGjngm7DUSxXGXP4b/zeNMTAKB4YMOcx4usfVQptKVXgDlCDWdcIrZnGTu/TGcc UW5oikN5aP7z2WnYL+HRzM8m+dr4mL58H/ghcRIbsXxfCuaPGLMK6sj3A4diAS8R 1TqdE4Mo6g7Uqs0QWdxUjXCgcB4HPGR1yH1HftrMkRsszCnpF7jkNIbE7eC9UHvH dPjY7qwpcrSFyhwdtstQJdf1fmYKlejXrUM57K0ElOZJWHE95K71XPNDsgSImp5N e+FPTYfJndDA93RRLXdxWe9+4+Nk0dPeYXJNMNnbQRrhNfJWLBWf8Dhm7sDkRrAC 9fnQ6DwUXCytKnSNgNvjdar4FrxbYcNPbCenDsFMZPkMmxoGU94A7DzmiBH37uD7 xKu9FH+lzOJarpefnt2v3QMuBc6n8h8wd1+i4ohXJKePyJoDXy8pDkq8ssSMnWor wUHOIgdJP4Ty3uTHESrpg/H7L+eWI4WLulxO1PoSgkxLl6DfKZvPEHIwbAY62nBW PPgkrU4a81Zo8ivYuKFKtkuNve1X8Bd5ut7CrYgHyVdKpaUyU/k= =Amnh -----END PGP SIGNATURE----- --3tnk6uehq5jkdmfp--