The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: pete@dunnington.plus.com (Pete Turnbull)
Subject: [TUHS] Control-T (was top)
Date: Thu, 31 May 2018 00:14:03 +0100	[thread overview]
Message-ID: <f4611502-eafd-5b0f-ba3d-ffa3309c0bdf@dunnington.plus.com> (raw)
In-Reply-To: <fae79614-4785-0c14-9ab8-6e81b2f2c265@update.uu.se>

On 30/05/2018 23:10, Johnny Billquist wrote:
> On 30.05.18 02:19, Clem cole wrote:

>> 1). If you grab ^s/^q from the alphabet it means you can send raw 8 
>> bit data because they are valid characters (yes you can use escape 
>> chars but it gets very bad)
> 
> But this has nothing to do with 8 bit data.
[...]
> What you are talking about is simply the problem when you have inband 
> signalling, and is a totally different problem than 8bit data.

True, but what I believe Clem meant was "binary data".  He did write 
"raw data".

> RTS/CTS signalling is certainly a part of the standard, but it is not 
> meant for flow control. It is for half duplex and the way to signal when 
> you want to change the direction of communication.
> 
> It is meant for *half duplex* communication. Not flow control.

Actually, for both, explicitly in the standard.  The standard (which I 
have in front of me, RS232C August 1969 reaffirmed June 1981) does 
indeed explain at length how to use it for half duplex turnaround but 
also indicates how to use it for flow control.  It states the use on 
one-way channels and full-duplex channels to stop transmission in a 
paragraph before the paragraph discussing half duplex.

> The AT "standard" was never actually a standard. It's only a defacto 
> standard, but is just something Hayes did, as I'm sure you know.

Except for ITU-T V.250, which admittedly is a Recommendation not a Standard.

-- 
Pete
Pete Turnbull


  reply	other threads:[~2018-05-30 23:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.1.1527559201.18622.tuhs@minnie.tuhs.org>
2018-05-29 22:45 ` Johnny Billquist
2018-05-30  0:19   ` Clem cole
2018-05-30  0:20     ` Clem cole
2018-05-30 22:10     ` Johnny Billquist
2018-05-30 23:14       ` Pete Turnbull [this message]
2018-05-30  1:10   ` Dave Horsfall
     [not found] <mailman.1.1527732002.17884.tuhs@minnie.tuhs.org>
2018-05-31 15:02 ` Johnny Billquist
2018-05-31 21:42   ` Nemo
2018-05-29 21:21 Norman Wilson
2018-05-30  9:06 ` arnold
  -- strict thread matches above, loose matches on Subject: below --
2018-05-29 18:49 Noel Chiappa
2018-05-30  1:05 ` Dave Horsfall
2018-05-29  2:55 Noel Chiappa
2018-05-29 17:10 ` Paul Winalski
2018-05-24 12:20 [TUHS] History of top Noel Chiappa
2018-05-24 14:09 ` Clem Cole
2018-05-24 14:50   ` [TUHS] Control-T (was top) Ronald Natalie
2018-05-24 15:01     ` Clem Cole
2018-05-24 15:48       ` Lars Brinkhoff
2018-05-24 15:08     ` Arthur Krewat
2018-05-28 22:32       ` Paul Winalski
2018-05-28 23:11         ` Clem cole
2018-05-28 23:32           ` Arthur Krewat
2018-05-29  1:12         ` Dave Horsfall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f4611502-eafd-5b0f-ba3d-ffa3309c0bdf@dunnington.plus.com \
    --to=pete@dunnington.plus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).