EOF

[ruben]

Is EOF is a signal, how is it propagated though the OS?

[Lew Pitcher]

On Wednesday January 27 2016 11:15, in comp.unix.shell, "ruben" <c...@iran.gov>
wrote:

> Is EOF is a signal,

In the POSIX/Unix sense of the word "signal", no.

> how is it propagated though the OS?

As information stored in, or derived from, the kernel's open file descriptor
table(s).

--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[Keith Thompson]

ruben <c...@iran.gov> writes:
> Is EOF is a signal, how is it propagated though the OS?

In C, EOF is a macro, defined in <stdio.h>, that expands to "an
integer constant expression, with type int and a negative value,
that is returned by several functions to indicate end-of-file,
that is, no more input from a stream".

Its value is typically -1. A typical definition is

#define EOF (-1)

The term "EOF" is also used to refer to other things. If you're
not asking about the C macro, please clarify your question.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Barry Margolin]

In article <vilain-E8B125....@news.individual.net>,
Michael Vilain <vil...@NOspamcop.net> wrote:

> In article <n8aqei$g7q$1...@reader1.panix.com>, ruben <c...@iran.gov>

> wrote:
>
> > Is EOF is a signal, how is it propagated though the OS?
>

> The suspicious person in me wonders if this is an interview question or
> a homework question or the poster is a newbie.
>
> I've never heard this asked this way. This assumes that reading or
> writing past the End Of a File marker is a implemented as a signal when
> that's strictly up to the implementation.

Since he posted this in c.u.shell, I suspect he's asking about how
typing Control-d works to send EOF. He wonders if it's similar to the
way Control-c sends an interrupt signal.

Here's how it works (a bit simplified).

Normally, when the program calls read() on a terminal in "cooked" mode,
it doesn't return until the user types Return. But it also returns
immediately when the user types the EOF character (Control-d by default).

The way that programs tell when they've reached EOF on any stream is
that read() returns 0 characters. Because otherwise read() would stay
blocked until there's something available to return. But since the EOF
character forces read() to return immediately, typing it at the
beginning of the line will return 0 characters, and the application
interprets this as EOF.

A little known fact about this is that you can also type Control-d
anywhere on the line. That will cause the line to be sent to the
application, but it won't be treated as EOF. If the application is
reading whole lines, it should just buffer this partial line and call
read() again, because it doesn't consider a line to be input until it
gets a newline character. In particular, if read() was called because
the program uses stdio and called fgets(), stdio will do the buffering
and wait for the newline.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Sven Mascheck]

Barry Margolin wrote:

> A little known fact about this is that you can also type Control-d
> anywhere on the line. That will cause the line to be sent to the
> application, but it won't be treated as EOF. If the application is
> reading whole lines, it should just buffer this partial line and call
> read() again, because it doesn't consider a line to be input until it
> gets a newline character.

Actually, nice. That's why
while read line; do :; done
terminates even upon typing "text^D^D".

After explaining that cool stuff we could try to reconfuse the OP a bit
again by mentioning that typing ^D generates the EOT character at first
(which sounds quite similar to EOF) and then usually is translated into
the EOF condition by the terminal driver.

[Popping mad]

On Wed, 27 Jan 2016 10:46:46 -0800, Michael Vilain wrote:

> The suspicious person in me wonders if this is an interview question or
> a homework question or the poster is a newbie.
>
> I've never heard this asked this way. This assumes that reading or
> writing past the End Of a File marker is a implemented as a signal when
> that's strictly up to the implementation.
>

> It's either a large red sign or a traffic light with the red light on
> top and the green light below and yellow in the middle. Except in snowy
> areas, where the lights are horizontal instead of vertical.
>
> Seriously, wouldn't this be in the read() code of the OS? And depending
> on the way the program is accessing the file (directly via calling the
> OS or waiting for another process on the remote system to access the
> file and pass the result back to the calling process).



this is an example of a way not to answer a technical question. Why
would you waste time writing this.

I posted the question because the best Unix engineers seem to be here and
the answer is not obvious. I can send it with CTL D or it just shows up
when I get to the end of the file or stream I am reading, but I don't
know how.

In order to send it a process needs to be interupted and put on the wait
cue.

[Janis Papanagnou]

On 17.02.2016 14:31, Popping mad wrote:
> On Wed, 27 Jan 2016 10:46:46 -0800, Michael Vilain wrote:
>

>> [...]

>
> this is an example of a way not to answer a technical question. Why
> would you waste time writing this.

Maybe to avoid wasting time figuring out what you need to know based on
what knowledge you have.

Previous response is certainly not a way to reply to a clearly formulated
technical question. In the same way as your posting is an example of how
to not ask a technical question. The multitude of different replies might
have given you a clue on that.

>
> I posted the question because the best Unix engineers seem to be here and
> the answer is not obvious. I can send it with CTL D or it just shows up
> when I get to the end of the file or stream I am reading, but I don't
> know how.

Now this gives us a better hint what you want to know. You've got answers
already.

>
> In order to send it a process needs to be interupted and put on the wait
> cue.

Not sure what you are thinking here. You seem to be confusing signals (that
may interrupt a process) with with an end-of-file condition that a read()
Unix system call delivers. Or maybe you mean the EOF "character" that you
can created by typing ^D and that may lead to an end-of-file condition in
interactive input during a read() system call?

Janis