The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "John P. Linderman" <jpl.jpl@gmail.com>
To: Leah Neukirchen <leah@vuxu.org>
Cc: TUHS <tuhs@tuhs.org>
Subject: [TUHS] Re: "9 skills our grandkids won't have" - Is this a TUHS topic?
Date: Sat, 2 Jul 2022 20:22:00 -0400	[thread overview]
Message-ID: <CAC0cEp_5r=J_pcGcHQBQS15khBS_=GoZyBFo_8Ub3WEpCyhqHA@mail.gmail.com> (raw)
In-Reply-To: <874jzz8fyc.fsf@vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 3070 bytes --]

But that's a common misconception and not how Ctrl-D works on Unix.
Ctrl-D is part of the terminal discipline and causes an immediate stop

of the current read(2) syscall.  If nothing is in the input buffer,
this causes a zero-length read which is detected as end of file.


I once read a Patricia Cornwell novel in which the plot hinged around some
crooked person typing

   cat > ttya
Somebody is coming

meaning to send a message to /dev/ttya, but instead, creating a file named
"ttya".
(I almost surely have the details wrong, but I'm too lazy to go searching
for the real quote, which isn't relevant here.)

Cornwell said the ttya file was of size 18, so, being an obsessive
nit-picker, I sent her a letter saying that it could have been 18 bytes
long,
but that would imply that the sender terminated the message with CTRL-D
rather than a newline and then terminating the command,
the latter of which seemed much more plausible for a novice user. Rather
than ignoring my letter, or telling me where to shove my letter,
she sent me a gracious thank you note, and an FBI hat, which I still own.

On Sat, Jul 2, 2022 at 3:37 PM Leah Neukirchen <leah@vuxu.org> wrote:

> Clem Cole <clemc@ccc.com> writes:
>
> > On Fri, Jul 1, 2022 at 10:03 AM Steve Nickolas <usotsuki@buric.co>
> wrote:
> >
> >> On Fri, 1 Jul 2022, Nelson H. F. Beebe wrote:
> >>
> >> > Ctrl-D signifies end of transmission.  Some other O/Ses have used
> >> > Ctrl-Z for that purpose, presumably because Z is the final letter
> >> > of numerous alphabets.
> >>
> >> I thought only CP/M and its descendants did that. :o (Of course that
> >> includes DOS and Windows)
> >>
> > Steve - The social disease spread of DOS-11, RT-11, CP/M, and MS/PS-DOS
> > used ^Z as an EOF character in their text file format.  The key is that
> > they stored a block count, not a byte count in the META.   Thus the last
> > byte needs a marker to tell the OS to stop reading. [Early DEC OS's may
> > have done that also, but I never looked at their FS formats].
> >
> > Unix, of course, never made any distinction to the core OS WRT to 'type'
> > [other than Regular/Directory/Special]  and Ken stored a character count.
> > So there was no need to signal EOF with a markered stored on disk..
> >
> > A pipe or the shell on the other hand does have a need to signal the end
> of
> > a transaction, and 'End of Transmission,' as Nelson points out, is the
> > ASCII character reserved for the same.
>
> But that's a common misconception and not how Ctrl-D works on Unix.
> Ctrl-D is part of the terminal discipline and causes an immediate stop
> of the current read(2) syscall.  If nothing is in the input buffer,
> this causes a zero-length read which is detected as end of file.
>
> You can verify this e.g. by typing "foo<Ctrl-D>" into cat(1).  It will
> print "foo", but not exit.  Another Ctrl-D will then quit cat(1) due
> to the empty read.
>
> In no case, a ASCII Ctrl-D 0x4 is sent over a pipe or to a shell.
> (Over the pty, yes.)
>
> cheers,
> --
> Leah Neukirchen  <leah@vuxu.org>  https://leahneukirchen.org/
>

[-- Attachment #2: Type: text/html, Size: 4982 bytes --]

  parent reply	other threads:[~2022-07-03  0:23 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-01 13:31 Nelson H. F. Beebe
2022-07-01 14:02 ` Steve Nickolas
2022-07-01 15:01   ` Clem Cole
2022-07-01 19:22     ` Phil Budne
2022-07-01 19:53       ` Clem Cole
2022-07-02 19:36     ` Leah Neukirchen
2022-07-02 19:50       ` Clem Cole
2022-07-03  0:22       ` John P. Linderman [this message]
2022-07-01 15:50   ` Lars Brinkhoff
2022-07-01 16:20     ` Warner Losh
2022-07-01 18:18       ` Clem Cole
2022-07-01 18:09     ` Clem Cole
2022-07-01 18:45     ` Steve Nickolas
  -- strict thread matches above, loose matches on Subject: below --
2022-06-30 13:14 [TUHS] " steve jenkin
2022-06-30 13:39 ` [TUHS] " Marc Donner
2022-06-30 13:54   ` Tom Teixeira
2022-06-30 14:08   ` Marshall Conover
2022-06-30 14:15     ` Larry McVoy
2022-06-30 14:32     ` Will Senn
2022-06-30 14:42     ` Pierre DAVID
2022-06-30 15:44       ` Larry McVoy
2022-06-30 15:23   ` Clem Cole
2022-06-30 15:35     ` Clem Cole
2022-06-30 14:23 ` Michael Kjörling
2022-06-30 15:12 ` Al Kossow
2022-06-30 15:55 ` Adam Thornton
2022-06-30 16:37 ` Paul Winalski
2022-07-01 13:05   ` Ori Idan
     [not found]     ` <Yr7zs59NtbXcRCu4@mbsks.franken.de>
2022-07-01 13:17       ` Matthias Bruestle
2022-07-01 13:36         ` Angus Robinson
2022-07-01 13:58           ` Marc Donner
2022-07-01 14:05             ` Henry Bent
2022-07-01 14:37               ` Marc Donner
2022-07-01 14:41           ` Blake McBride
2022-09-16 17:04         ` Michael Parson
2022-07-02 23:01     ` Mark Sutton
2022-07-03  0:08       ` John Cowan
2022-06-30 19:24 ` Michael Huff
2022-06-30 19:56   ` Jon Steinhart
2022-06-30 20:43   ` Robert Stanford via TUHS
2022-06-30 20:49     ` Chris Pinnock via TUHS
2022-06-30 21:11       ` ron minnich
2022-06-30 21:21       ` Larry McVoy
2022-06-30 21:24         ` Marc Donner
2022-06-30 21:41           ` James Johnston
2022-06-30 21:54             ` Larry McVoy
2022-06-30 22:05               ` Dr Iain Maoileoin
2022-06-30 22:18                 ` Rik Schneider
2022-06-30 22:51                   ` Marc Donner
2022-07-01 10:48                   ` Tom Ivar Helbekkmo via TUHS
2022-06-30 21:24         ` Chris Pinnock via TUHS
2022-07-01  0:41 ` Tomasz Rola
2022-07-01  0:46   ` Larry McVoy
2022-07-01  1:13     ` Larry Stewart
2022-07-01 18:12   ` Harald Arnesen

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='CAC0cEp_5r=J_pcGcHQBQS15khBS_=GoZyBFo_8Ub3WEpCyhqHA@mail.gmail.com' \
    --to=jpl.jpl@gmail.com \
    --cc=leah@vuxu.org \
    --cc=tuhs@tuhs.org \
    /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).