* [TUHS] Seeking wisdom from Unix Greybeards @ 2020-11-25 17:14 Grant Taylor via TUHS 2020-11-25 17:22 ` Ralph Corderoy ` (3 more replies) 0 siblings, 4 replies; 14+ messages in thread From: Grant Taylor via TUHS @ 2020-11-25 17:14 UTC (permalink / raw) To: The Unix Heritage Society, cctalk [-- Attachment #1: Type: text/plain, Size: 636 bytes --] Hi, As I find myself starting yet another project that that wants to use ANSI control sequences for colorization of text, I find myself -- yet again -- wondering if there is a better way to generate the output from the code in a way that respects TERMinal capabilites. Is there a better / different control sequence that I can ~> should use for colorizing / stylizing output that will account for the differences in capabilities between a VT100 and XTerm? Can I wrap things that I output so that I don't send color control sequences to a TERMinal that doesn't support them? -- Grant. . . . unix || die [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4013 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] Seeking wisdom from Unix Greybeards 2020-11-25 17:14 [TUHS] Seeking wisdom from Unix Greybeards Grant Taylor via TUHS @ 2020-11-25 17:22 ` Ralph Corderoy [not found] ` <20201126145134.GB394251@mit.edu> 2020-11-25 17:38 ` Larry McVoy ` (2 subsequent siblings) 3 siblings, 1 reply; 14+ messages in thread From: Ralph Corderoy @ 2020-11-25 17:22 UTC (permalink / raw) To: The Unix Heritage Society Hi Grant, > wondering if there is a better way to generate the output from > the code in a way that respects TERMinal capabilites. tput setf 4; date; tput sgr0 See terminfo(5). (BTW, I don't think the question is worthy of TUHS.) -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20201126145134.GB394251@mit.edu>]
* [TUHS] Seeking wisdom from Unix Greybeards [not found] ` <20201126145134.GB394251@mit.edu> @ 2020-11-26 21:48 ` steffen 2021-02-10 18:57 ` Greg A. Woods 2020-11-26 21:59 ` dave 1 sibling, 1 reply; 14+ messages in thread From: steffen @ 2020-11-26 21:48 UTC (permalink / raw) Theodore Y. Ts'o wrote in <20201126145134.GB394251 at mit.edu>: |On Wed, Nov 25, 2020 at 05:22:55PM +0000, Ralph Corderoy wrote: |>> wondering if there is a better way to generate the output from |>> the code in a way that respects TERMinal capabilites. |> |> tput setf 4; date; tput sgr0 |> |> See terminfo(5). |> |> (BTW, I don't think the question is worthy of TUHS.) | |To make this a bit more TUHS-focused, was there anything that had |similar functionality which pre-dated Bill Joy and termcap in late |70's? | |(I'll note that in recent years, most people seem to have not bothered |with terminfo, given that all the world's a Vax^H^H^HSun^H^H^HLinux |^H^H^H^Hxterm. :-) ANSI escape sequences aka ISO 6429 came via ECMA-48 i have learned, and that appeared first in 1976 (that via Wikidpedia). I made a survey about twenty years ago over terminfo (source) entries, and found it not worth the effort to care for anything else, and not to padding, too. (My experience with hardware does not even cause a little cough in this audience, however.) | - Ted | --End of <20201126145134.GB394251 at mit.edu> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] Seeking wisdom from Unix Greybeards 2020-11-26 21:48 ` steffen @ 2021-02-10 18:57 ` Greg A. Woods 2021-02-10 22:26 ` Clem Cole 2021-02-24 22:20 ` Steffen Nurpmeso 0 siblings, 2 replies; 14+ messages in thread From: Greg A. Woods @ 2021-02-10 18:57 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 2435 bytes --] At Thu, 26 Nov 2020 22:48:25 +0100, Steffen Nurpmeso <steffen@sdaoden.eu> wrote: Subject: Re: [TUHS] Seeking wisdom from Unix Greybeards > > ANSI escape sequences aka ISO 6429 came via ECMA-48 i have > learned, and that appeared first in 1976 (that via Wikidpedia). Wikipedia is a bit misleading here. This is one case where ANSI and ECMA worked together quite closely (and another example of where ISO took the result more or less directly, though on a different schedule). As it happens one can read about it much more directly from the original sources. First we can find that FIPS-86 is "in whole" ANSI-X3.64-1979 https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub86-1981.pdf Thus giving us "free" access to the original ANSI standard in a "new" digital (PDF) form. Here's the full copy of ANSI-X3.64-1979 verbatim (including cover pages): https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub86.pdf See in particular "Appendix H" in the latter. X3.64 also gives a good list of all the people and organisations which cooperated to create this standard (though interestingly only mentions ECMA-48 in that last appendix). There is also corroborating evidence of this cooperation in the preface ("BRIEF HISTORY") to the 2nd Edition of ECMA-48: https://www.ecma-international.org/wp-content/uploads/ECMA-48_2nd_edition_august_1979.pdf Note though that the link the 1st Edition of ECMA-48 here is wrong, so as yet I've not seen if there's any history given in that 1st edition): https://www.ecma-international.org/publications-and-standards/standards/ecma-48/ As an aside, the DEC VT100 terminal was an early (it came out a year before X3.64) and relatively complete (for a video terminal application) implementation of X3.64. BTW, I would in general agree with Steffen that implementing an application to output anything but X3.64/ECMA-48/ISO-6429 is rather pointless these days, _unless_ one wants to take advantage of any particular implementation's additional "private" features, and/or work around any annoying but inevitable bugs in various implementations. Also the API provided by, e.g. libcurses, often makes for much easier programming than direct use of escape sequences, or invention and maintenance of one's own API. -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] Seeking wisdom from Unix Greybeards 2021-02-10 18:57 ` Greg A. Woods @ 2021-02-10 22:26 ` Clem Cole 2021-02-24 22:20 ` Steffen Nurpmeso 1 sibling, 0 replies; 14+ messages in thread From: Clem Cole @ 2021-02-10 22:26 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1116 bytes --] On Wed, Feb 10, 2021 at 1:57 PM Greg A. Woods <woods@robohack.ca> wrote: > As an aside, the DEC VT100 terminal was an early (it came out a year before > X3.64) Yup, It was spec'ed at least a year ahead and its the code was committed before the standard was even in a draft vote. > and relatively complete (for a video terminal application) implementation > of X3.64. > Although different from and the missing stuff was a bear. Originally, VT100 != X3.64 which has caused many issues over the years. The big issue was the lack of a proper insert/delete, it used scrolling regions instead. Kudos to Mary Ann for working through that whole mess years ago! That's why back in the day, I preferred the H19 and later the Ambassador ;-) My memory is that was ECMA that got the DEC changes/differences added/put back/made legal. But originally, there were not. At one point, I had a copy of the internal DEC documentation (which I think I got from Tom Kent who wrote much of the rom code and had been on the committee for DEC at one point, but I don't remember). Clem ᐧ ᐧ [-- Attachment #2: Type: text/html, Size: 3057 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] Seeking wisdom from Unix Greybeards 2021-02-10 18:57 ` Greg A. Woods 2021-02-10 22:26 ` Clem Cole @ 2021-02-24 22:20 ` Steffen Nurpmeso 1 sibling, 0 replies; 14+ messages in thread From: Steffen Nurpmeso @ 2021-02-24 22:20 UTC (permalink / raw) To: The Unix Heritage Society mailing list Greg A. Woods wrote in <m1l9ufi-0036urC@more.local>: |At Thu, 26 Nov 2020 22:48:25 +0100, Steffen Nurpmeso <steffen@sdaoden.eu> \ |wrote: |Subject: Re: [TUHS] Seeking wisdom from Unix Greybeards |> |> ANSI escape sequences aka ISO 6429 came via ECMA-48 i have |> learned, and that appeared first in 1976 (that via Wikidpedia). | |Wikipedia is a bit misleading here. This is one case where ANSI and |ECMA worked together quite closely (and another example of where ISO |took the result more or less directly, though on a different schedule). | |As it happens one can read about it much more directly from the original |sources. | |First we can find that FIPS-86 is "in whole" ANSI-X3.64-1979 | | https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub86-1981.pdf | |Thus giving us "free" access to the original ANSI standard in a "new" |digital (PDF) form. Here's the full copy of ANSI-X3.64-1979 verbatim |(including cover pages): | | https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub86.pdf | |See in particular "Appendix H" in the latter. Interesting that ANSI did not include the colour specifications. And that with Jimmy Carter. What is so interesting when looking at this. How typewriter output surrounded us decades ago, it was everywhere, and taken for granted (i am born in 1972), and how long that time has passed. |X3.64 also gives a good list of all the people and organisations which |cooperated to create this standard (though interestingly only mentions |ECMA-48 in that last appendix). | |There is also corroborating evidence of this cooperation in the preface |("BRIEF HISTORY") to the 2nd Edition of ECMA-48: | | https://www.ecma-international.org/wp-content/uploads/ECMA-48_2nd_editio\ | n_august_1979.pdf | |Note though that the link the 1st Edition of ECMA-48 here is wrong, so |as yet I've not seen if there's any history given in that 1st edition): | | https://www.ecma-international.org/publications-and-standards/standards/\ | ecma-48/ | |As an aside, the DEC VT100 terminal was an early (it came out a year |before X3.64) and relatively complete (for a video terminal application) |implementation of X3.64. | |BTW, I would in general agree with Steffen that implementing an |application to output anything but X3.64/ECMA-48/ISO-6429 is rather |pointless these days, _unless_ one wants to take advantage of any |particular implementation's additional "private" features, and/or work |around any annoying but inevitable bugs in various implementations. |Also the API provided by, e.g. libcurses, often makes for much easier |programming than direct use of escape sequences, or invention and |maintenance of one's own API. | |-- | Greg A. Woods <gwoods@acm.org> | |Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> |Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> --End of <m1l9ufi-0036urC@more.local> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 14+ messages in thread
* [TUHS] Seeking wisdom from Unix Greybeards [not found] ` <20201126145134.GB394251@mit.edu> 2020-11-26 21:48 ` steffen @ 2020-11-26 21:59 ` dave 1 sibling, 0 replies; 14+ messages in thread From: dave @ 2020-11-26 21:59 UTC (permalink / raw) On Thu, 26 Nov 2020, Theodore Y. Ts'o wrote: > To make this a bit more TUHS-focused, was there anything that had > similar functionality which pre-dated Bill Joy and termcap in late 70's? As I recall, one wrote code "knowing" that it was a VT-05 etc if you wanted escape sequences; I dimly recall using a getty-like file to get the terminal type. Thus, /dev/tty8 was invariably (but not always) the dreaded VT-05 (one client used a Duckwriter as the console, because he wanted a hard-copy of everything; one day, the system went berserk (a bad sector smack on the error log) and so did the hard copy, as Unix faithfully tried to record each error). -- Dave ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] Seeking wisdom from Unix Greybeards 2020-11-25 17:14 [TUHS] Seeking wisdom from Unix Greybeards Grant Taylor via TUHS 2020-11-25 17:22 ` Ralph Corderoy @ 2020-11-25 17:38 ` Larry McVoy 2020-11-25 18:00 ` Steffen Nurpmeso [not found] ` <CACYmRNAtdJu0ui=CgrEcWH6J3uikCh0=aCLNvk0+V29rypDBAg@mail.gmail.com> 3 siblings, 0 replies; 14+ messages in thread From: Larry McVoy @ 2020-11-25 17:38 UTC (permalink / raw) To: Grant Taylor; +Cc: cctalk, The Unix Heritage Society man 1 tput is what I use. On Wed, Nov 25, 2020 at 10:14:55AM -0700, Grant Taylor via TUHS wrote: > Hi, > > As I find myself starting yet another project that that wants to use ANSI > control sequences for colorization of text, I find myself -- yet again -- > wondering if there is a better way to generate the output from the code in a > way that respects TERMinal capabilites. > > Is there a better / different control sequence that I can ~> should use for > colorizing / stylizing output that will account for the differences in > capabilities between a VT100 and XTerm? > > Can I wrap things that I output so that I don't send color control sequences > to a TERMinal that doesn't support them? > > > > -- > Grant. . . . > unix || die > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] Seeking wisdom from Unix Greybeards 2020-11-25 17:14 [TUHS] Seeking wisdom from Unix Greybeards Grant Taylor via TUHS 2020-11-25 17:22 ` Ralph Corderoy 2020-11-25 17:38 ` Larry McVoy @ 2020-11-25 18:00 ` Steffen Nurpmeso 2020-11-25 20:03 ` Steffen Nurpmeso [not found] ` <CACYmRNAtdJu0ui=CgrEcWH6J3uikCh0=aCLNvk0+V29rypDBAg@mail.gmail.com> 3 siblings, 1 reply; 14+ messages in thread From: Steffen Nurpmeso @ 2020-11-25 18:00 UTC (permalink / raw) To: Grant Taylor; +Cc: cctalk, tuhs Grant Taylor wrote in <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net>: |Hi, | |As I find myself starting yet another project that that wants to use |ANSI control sequences for colorization of text, I find myself -- yet |again -- wondering if there is a better way to generate the output from |the code in a way that respects TERMinal capabilites. | |Is there a better / different control sequence that I can ~> should use |for colorizing / stylizing output that will account for the differences |in capabilities between a VT100 and XTerm? | |Can I wrap things that I output so that I don't send color control |sequences to a TERMinal that doesn't support them? color_init() { [ -n "${NOCOLOUR}" ] && return [ -n "${MAILX_CC_TEST_NO_COLOUR}" ] && return # We do not want color for "make test > .LOG"! if (command -v stty && command -v tput) >/dev/null 2>&1 && (<&1 >/dev/null stty -a) 2>/dev/null; then { sgr0=`tput sgr0`; } 2>/dev/null [ $? -eq 0 ] || return { saf1=`tput setaf 1`; } 2>/dev/null [ $? -eq 0 ] || return { saf2=`tput setaf 2`; } 2>/dev/null [ $? -eq 0 ] || return { saf3=`tput setaf 3`; } 2>/dev/null [ $? -eq 0 ] || return { b=`tput bold`; } 2>/dev/null [ $? -eq 0 ] || return COLOR_ERR_ON=${saf1}${b} COLOR_ERR_OFF=${sgr0} COLOR_WARN_ON=${saf3}${b} COLOR_WARN_OFF=${sgr0} COLOR_OK_ON=${saf2} COLOR_OK_OFF=${sgr0} unset saf1 saf2 saf3 b fi } Is what i use for a make system. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] Seeking wisdom from Unix Greybeards 2020-11-25 18:00 ` Steffen Nurpmeso @ 2020-11-25 20:03 ` Steffen Nurpmeso 0 siblings, 0 replies; 14+ messages in thread From: Steffen Nurpmeso @ 2020-11-25 20:03 UTC (permalink / raw) To: Grant Taylor; +Cc: cctalk, tuhs Steffen Nurpmeso wrote in <20201125180048.IvtOI%steffen@sdaoden.eu>: |Grant Taylor wrote in | <9c1595cc-54a1-8af9-0c2d-083cb04dd97c@spamtrap.tnetconsulting.net>: ||As I find myself starting yet another project that that wants to use ||ANSI control sequences for colorization of text, I find myself -- yet ||again -- wondering if there is a better way to generate the output from ||the code in a way that respects TERMinal capabilites. || ||Is there a better / different control sequence that I can ~> should use ||for colorizing / stylizing output that will account for the differences ||in capabilities between a VT100 and XTerm? || ||Can I wrap things that I output so that I don't send color control ||sequences to a TERMinal that doesn't support them? | | color_init() { | [ -n "${NOCOLOUR}" ] && return | [ -n "${MAILX_CC_TEST_NO_COLOUR}" ] && return | # We do not want color for "make test > .LOG"! | if (command -v stty && command -v tput) >/dev/null 2>&1 && Of course that subshell (..if it is one..) is not necessary, it could be { ..; } or x&&y&&, whatever. Must be a leftover, or whatever i have thought once i wrote this. | (<&1 >/dev/null stty -a) 2>/dev/null; then | { sgr0=`tput sgr0`; } 2>/dev/null | [ $? -eq 0 ] || return | { saf1=`tput setaf 1`; } 2>/dev/null | [ $? -eq 0 ] || return | { saf2=`tput setaf 2`; } 2>/dev/null | [ $? -eq 0 ] || return | { saf3=`tput setaf 3`; } 2>/dev/null | [ $? -eq 0 ] || return | { b=`tput bold`; } 2>/dev/null | [ $? -eq 0 ] || return | | COLOR_ERR_ON=${saf1}${b} COLOR_ERR_OFF=${sgr0} | COLOR_WARN_ON=${saf3}${b} COLOR_WARN_OFF=${sgr0} | COLOR_OK_ON=${saf2} COLOR_OK_OFF=${sgr0} | unset saf1 saf2 saf3 b | fi |} | |Is what i use for a make system. A sh(1)-based test, to be exact. Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CACYmRNAtdJu0ui=CgrEcWH6J3uikCh0=aCLNvk0+V29rypDBAg@mail.gmail.com>]
[parent not found: <71fdfa2e-1483-4985-3f55-6760b3a84ec0@gmail.com>]
[parent not found: <20201126182937.GN9589@mcvoy.com>]
* [TUHS] Seeking wisdom from Unix Greybeards [not found] ` <20201126182937.GN9589@mcvoy.com> @ 2020-11-26 23:14 ` erc 2020-11-26 23:23 ` lm 0 siblings, 1 reply; 14+ messages in thread From: erc @ 2020-11-26 23:14 UTC (permalink / raw) Larry, as was stated in the original post (and multiple times in the replies), I believe they were looking for another solution. On 11/26/20, Larry McVoy <lm at mcvoy.com> wrote: > Um, as has been stated multiple time, this is why tputs(1) exists. > Problem. Solved. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [TUHS] Seeking wisdom from Unix Greybeards 2020-11-26 23:14 ` erc @ 2020-11-26 23:23 ` lm 0 siblings, 0 replies; 14+ messages in thread From: lm @ 2020-11-26 23:23 UTC (permalink / raw) Did I miss a reason for the alternative? Because if you add a caching layer this approach has been working for me for decades. I rewrote dired in perl just because perl was everywhere and I could. I've been dragging the perl one around since at least 1990 and it worked for me on pretty much any version of Unix. I think MacOS isn't supported but I'm sure it could be. To avoid calling tput over and over again, I cached the output for each terminal and then just evaled the cache which sets a bunch of variables to the escapes I needed. It performed just fine on 20mhz SPARCstations so I'm sort of wondering why the solution for the problem isn't good enough. # Dig out all the terminal info so we know the escape chars for this terminal. sub terminal_init { local($term) = "$ENV{'HOME'}/.term/$ENV{'TERM'}"; local($i) = 0; $| = 1; @pids = (); $SIG{TERM} = sub { exit(0); }; $SIG{PIPE} = 'IGNORE'; # RedHat 5.0 seems to get this wrong somehow. #chop($tc_rows = `tput lines`); #chop($tc_cols = `tput cols`); open(STTY, "stty -a|"); while (defined($_ = <STTY>)) { last if /rows = \d/ || /\d rows/ || /rows \d/; } close(STTY); #speed 9600 baud; rows 58; columns 80; line = 0; #speed 9600 baud; 47 rows; 80 columns; #rows = 66; columns = 80 $tc_cols = 0; if (/rows (\d+); columns (\d+);/) { $tc_rows = $1; $tc_cols = $2; } elsif (/(\d+) rows; (\d+) columns;/) { $tc_rows = $1; $tc_cols = $2; } elsif (/rows = (\d+); columns = (\d+)/) { $tc_rows = $1; $tc_cols = $2; } if ($tc_cols == 0) { die "Can't get terminal settings.\n"; } $half_of_screen = int($tc_rows / 2); # it's cached, go grab it. if (-f $term) { open(T, $term); @t = <T>; close(T); eval "@t"; &ttyraw; return unless $i < $tc_rows; } print "Getting terminal info just this once and saving it..."; mkdir("$ENV{'HOME'}/.term", 0755); open(T, ">$term"); $tc_smcup = `tput smcup`; $tc_rmcup = `tput rmcup`; $tc_bold = `tput bold`; $tc_normal = `tput sgr0`; $tc_clear = `tput clear`; $tc_clreos = `tput ed`; $tc_clreol = `tput el`; if ($tc_cols < 60) { die "$0: needs 60 columns"; } if (length($tc_clreos) == 0) { die "$0: needs clear to end of screen"; } if (length($tc_clreol) == 0) { die "$0: needs clear to end of line"; } print T "\$tc_smcup = \"$tc_smcup\";\n"; print T "\$tc_rmcup = \"$tc_rmcup\";\n"; print T "\$tc_bold = \"$tc_bold\";\n"; print T "\$tc_normal = \"$tc_normal\";\n"; print T "\$tc_clear = \"$tc_clear\";\n"; print T "\$tc_clreol = \"$tc_clreol\";\n"; print T "\$tc_clreos = \"$tc_clreos\";\n"; for ($i = 0; $i < $tc_rows; ++$i) { $left[$i] = `tput cup $i 0`; print T '$left[' . "$i] = \"" . $left[$i] . "\";\n"; if ($i < $half_of_screen) { $middle[$i] = `tput cup $i 44`; print T '$middle[' . "$i] = \"" . $middle[$i] . "\";\n"; } } print T '$i = ' . "$i;\n"; close(T); print "done\n"; &ttyraw; } ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20201126183746.DD93218C087@mercury.lcs.mit.edu>]
[parent not found: <7DBB40AE-259D-494E-8ABF-2FE4D47F4052@iitbombay.org>]
* [TUHS] Seeking wisdom from Unix Greybeards [not found] ` <7DBB40AE-259D-494E-8ABF-2FE4D47F4052@iitbombay.org> @ 2020-11-26 19:02 ` lars 2020-11-26 21:56 ` steffen 1 sibling, 0 replies; 14+ messages in thread From: lars @ 2020-11-26 19:02 UTC (permalink / raw) Noel Chiappa wrote: > If the latter, there's the terminal-independent support of video > terminals in ITS; that dates to the mid-1970's (i.e. circa V5 or > so). User programs output device-independent display control codes (I > have this memory that they were called P-Codes, but that could be my > memory failing), and the OS translated them to the appropriate > screen-control characters. That's correct. Or ^P-codes, from the character that signalled a control code. It would be interesting to figure out when they were introduced. They were not present in 1972; at this point ITS only supported printing terminals, Datapoints, and Imlacs. WAITS allegedly had an even better abstration of terminal control codes. > One additional hack was that the number of terminal types supported in > the OS was limited; there was however a protocol called SUPDUP which > sent (basically) those device-independent codes over a remote login Basically, but another set of equivalent codes internal to ITS. SUPDUP means super-duper image mode, which alludes to image mode. > (originally over NCP) frm the server machine to the client. The User > SUPDUP client supported a lot more terminal types; so people with > odd-ball terminals used to log in, SUPDUP _back_ to their machine, and > away they went. See also CRTSTY. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [TUHS] Seeking wisdom from Unix Greybeards [not found] ` <7DBB40AE-259D-494E-8ABF-2FE4D47F4052@iitbombay.org> 2020-11-26 19:02 ` lars @ 2020-11-26 21:56 ` steffen 1 sibling, 0 replies; 14+ messages in thread From: steffen @ 2020-11-26 21:56 UTC (permalink / raw) Bakul Shah wrote in <7DBB40AE-259D-494E-8ABF-2FE4D47F4052 at iitbombay.org>: |RFC734 Interesting! Off-topic, but i have downloaded this via #!/bin/sh - FROM=https://www.rfc-editor.org/rfc/ #FROM=https://tools.ietf.org/rfc/ MYDIR=/x/doc/coding/rfc : ${WGET:=`command -v curl` --silent} #: ${WGET:=`command -v wget` -q -O -} ## cd "${MYDIR}" || { echo >&2 'Cannot cd to '"${MYDIR}" exit 21 } xfiles= estat=0 while [ ${#} -gt 0 ]; do RFC=${1} shift [ -f "rfc${RFC}.txt" ] && { echo 'RFC '${RFC}': a local copy of this RFC yet exists' continue } printf 'Fetching RFC %s.txt ... ' "${RFC}" if ${WGET} "${FROM}"rfc${RFC}.txt > rfc${RFC}.txt; then xfiles="${xfiles} rfc${RFC}.txt" printf 'ok\n' else printf 'failed!\n' estat=1 fi done if [ -n "${xfiles}" ]; then "${EDITOR}" INDEX.txt ${xfiles} fi exit ${estat} and the file is contaminated with NULs. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-02-24 22:20 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-25 17:14 [TUHS] Seeking wisdom from Unix Greybeards Grant Taylor via TUHS 2020-11-25 17:22 ` Ralph Corderoy [not found] ` <20201126145134.GB394251@mit.edu> 2020-11-26 21:48 ` steffen 2021-02-10 18:57 ` Greg A. Woods 2021-02-10 22:26 ` Clem Cole 2021-02-24 22:20 ` Steffen Nurpmeso 2020-11-26 21:59 ` dave 2020-11-25 17:38 ` Larry McVoy 2020-11-25 18:00 ` Steffen Nurpmeso 2020-11-25 20:03 ` Steffen Nurpmeso [not found] ` <CACYmRNAtdJu0ui=CgrEcWH6J3uikCh0=aCLNvk0+V29rypDBAg@mail.gmail.com> [not found] ` <71fdfa2e-1483-4985-3f55-6760b3a84ec0@gmail.com> [not found] ` <20201126182937.GN9589@mcvoy.com> 2020-11-26 23:14 ` erc 2020-11-26 23:23 ` lm [not found] <20201126183746.DD93218C087@mercury.lcs.mit.edu> [not found] ` <7DBB40AE-259D-494E-8ABF-2FE4D47F4052@iitbombay.org> 2020-11-26 19:02 ` lars 2020-11-26 21:56 ` steffen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).