EOF is not a character • Hacker News Board

Re: EOF is not a character

#41

Post by nixpulvis » Sat, Mar 14, 2020, 3:41 AM UTC

anonymousiam wrote: post #18

ChristianBundy wrote: post #14

Earlier quoted context omitted.

Maybe you can correct me if I'm wrong, but I've always considered Ctrl+C and Ctrl+D to be signals that you can send a process rather than explicit characters. You might also get some stdout for those key combinations because ???, but they should be thought of as signals rather than as characters you're sending via stdin. Hoping Cunningham's Law comes into play with this comment. :)

Control-C is part of POSIX job control. If a stream (or "cooked" tty) sends a control-C (ASCII End-Of-Text or ETX), the foreground process will be sent a SIGINT signal. If that signal is not handled, the default action is to terminate the process (SIGTERM). Control-D is just another control character and not part of POSIX job control, but in the "cooked" case above, it will be interpreted as EOF and the process doing…

I was thinking the same thing, until I read this:

> 'stty -icanon' still interprets control characters such as Ctrl-C whereas 'stty raw' disables even this and is the real raw mode.

From the very detailed link posted by rgoulter above.

Still, in raw mode, Ctrl+D will send EOT, and thus end your shell. While Ctrl+C wont.

Re: EOF is not a character

#42

Post by kylek » Sat, Mar 14, 2020, 3:41 AM UTC

_8j50 wrote: post #36

Banged my head against the wall once after trying to figure out why Ctrl+D generates some character in bash but I can't send that character in a pipe to simulate termination.

Fun fact, ctrl-v in bash sets "verbatim insert" mode for the next character, so you can type a ^D "character" by doing "ctrl-v ctrl-d".

Re: EOF is not a character

#43

Post by mark-r » Sat, Mar 14, 2020, 3:45 AM UTC

1996 wrote: post #20

\r \n (0x0a 0x0d, or just one of them, or the combination of them, depending on your OS) is EOL ^D (0x04) is EOT and 0x03 is EOText: https://www.systutorials.com/ascii-table-and-ascii-code/ So, kinda, but somehow I'm happy it never got turned into a weird combinations depending on the OS.

Those are just conventions, and they aren't consistent from one OS to another at all. ASCII tried to standardize it but failed.

Re: EOF is not a character

#44

Post by jes5199 » Sat, Mar 14, 2020, 3:48 AM UTC

guerrilla wrote: post #34

jes5199 wrote: post #24

yeah, this author doesn’t know the history. Unix I/O was defined in opposition to practices in other OSes, that no longer exist

Clearly, since they barely know the system they are talking about but could you elaborate instead of leaving it vague? Which systems?

there’s plenty of other comments that explain it, but, CP/M, VAX, teletypewriters, punch cards - all used in-band control characters rather than an external signal

Re: EOF is not a character

#45

Post by nixpulvis » Sat, Mar 14, 2020, 3:48 AM UTC

eyegor wrote: post #39

nixpulvis wrote: post #7

Earlier quoted context omitted.

What does "Procedural" vs "Functional" have to do with this? It's a choice in data type. If by procedural you mean, nonsense, then sure... I agree that a function named `getchar` returning an `int` is procedural. :P

What they mean to say is: when I was working with a language that enforced pure functions, I had to actually consider purity. It's rare to see a way to enforce purity in procedural languages, whereas most fp langs support it.

Are we talking about even roughly the same concept of functional purity [1]? Nothing is stopping a pure function from representing EOF as -1.

Implementing IO in a "pure" way, is however another discussion.

[1]: https://en.wikipedia.org/wiki/Pure_function

Re: EOF is not a character

#46

Post by Animats » Sat, Mar 14, 2020, 3:48 AM UTC

In the beginning, there was the int. In K&R C, before function prototypes, all functions returned "int". ("float" and "double" were kludged in, without checking, at some point.) So the character I/O functions returned a 16-bit signed int. There was no way to return a byte, or a "char". That allowed room for out of band signals such as EOF.

It's an artifact of that era. Along with "BREAK", which isn't a character either.

Re: EOF is not a character

#47

Post by nixpulvis » Sat, Mar 14, 2020, 3:52 AM UTC

_8j50 wrote: post #36

Banged my head against the wall once after trying to figure out why Ctrl+D generates some character in bash but I can't send that character in a pipe to simulate termination.

I think I may still be banging my head on this one. It's just an ioctl difference between my pipe and my terminal's session, right?

Re: EOF is not a character

#48

Post by nixpulvis » Sat, Mar 14, 2020, 3:57 AM UTC

anonymousiam wrote: post #16

CP/M and DOS use ^Z (0x1A) as an EOF indicator. More modern operating systems use the file length (if available). Unix/Linux will treat ^D (0x04) as EOF within a stream, but only if the source is "cooked" and not "raw". (^D is ASCII "End Of Transmission or EOT" so that seems appropriate, except in the world of unicode.)

Using the "file length" as opposed to the "EOF indicator" is like how strings can either be represented as pointer to a contiguous sequence of `char` ending with a NULL byte, or as a tuple of (length, pointer), without the needed NULL byte.

One gives a priori information the other a posteriori.

Re: EOF is not a character

#49

Post by combatentropy » Sat, Mar 14, 2020, 4:03 AM UTC

The kernel returns EOF "if k is the current file position and m is the size of a file, performing a read() when k >= m..."

So, is the length of each file stored as an integer, along with the other metadata? This reminds me of how in JavaScript the length of an array is a property, instead of a function that counts it right then, like say in PHP.

Apparently it works. I've never heard of a situation where the file size number did not match the actual file size, nor of a time when the JavaScript array length got messed up. But it seems fragile. File operations would need to be ACID-compliant, like database operations (and likewise do JavaScript array operations). It seems like you would have to guard against race conditions.

Does anyone have a favorite resource that explains how such things are implemented safely?

Re: EOF is not a character

#50

Post by 1996 » Sat, Mar 14, 2020, 4:05 AM UTC

mark-r wrote: post #43

1996 wrote: post #20

\r \n (0x0a 0x0d, or just one of them, or the combination of them, depending on your OS) is EOL ^D (0x04) is EOT and 0x03 is EOText: https://www.systutorials.com/ascii-table-and-ascii-code/ So, kinda, but somehow I'm happy it never got turned into a weird combinations depending on the OS.

Those are just conventions, and they aren't consistent from one OS to another at all. ASCII tried to standardize it but failed.

That should have been my point - I'm happy there aren't 3 standards to specify what EOFile is.