EOF (novice)

[Kevin Bracey]

In message <[email protected]>

You probably won't find it in either of those manuals. You'll likely find
the doc on how to generate the EOF signal in whatever RISC OS 'user'
manuals are out there. Since the EOF condition is something that the OS
reports to the runtime/application, its generation will be specific to the
OS (although the mechanism that the OS uses to signal EOF to the runtime
may be discussed in the documentation for the runtime). How the OS
determines EOF will be documented in the OS documentation.

I think you might have missed a bit of this thread.

For RISC OS, it's not an OS function; it's a function of the C library. On a
Unix system, that would be a rather fine distinction, but RISC OS didn't have
the shared C library as part of the core OS for the first 4 years of its
life, and most of the core system components (filing systems, kernel, shell
etc) aren't written in C.

So Ctrl-D is for RISC OS in no way part of its "standard" interface. It
performs an entirely different function at the normal command line. Only
programs written in C using the Acorn C library interpret it as EOF. And I'm
not aware of any C programs using terminal input being supplied with the OS
at all. I'm also not even sure whether programs compiled with the GNU C
Library function the same way. Which goes back to my original point - I was
providing a counter-example to those saying that how to generate EOF is an
"OS" feature. For RISC OS it's just a C implementation feature.

Terminal input EOF is a C concept, alien to this particular operating system,
and maybe others. Which is why I wouldn't be adverse to it getting a mention
in the FAQ, pointing out that it is a feature C inherits from Unix, and
saying something like "if your OS doesn't have terminal EOF, the C library
implementors may have used Ctrl-D or Ctrl-Z; check your implementation's
documentation".

 

[James Hu]

For RISC OS, it's not an OS function; it's a function of the C
library. On a Unix system, that would be a rather fine distinction,
but RISC OS didn't have the shared C library as part of the core
OS for the first 4 years of its life, and most of the core system
components (filing systems, kernel, shell etc) aren't written in C.

A casual perusal of the web on RISC OS leads me to believe it was
developed specifically as an embedded OS that provides nice looking
on screen displays. The use of RISC OS as a desktop environment is
something relatively recent. Until it got on the desktop, interactive
text I/O wasn't even on the radar for the OS. I would characterize
the system as esoteric, not typical.

So Ctrl-D is for RISC OS in no way part of its "standard"
interface. It performs an entirely different function at the normal
command line.

This is true of Ctrl-Z in MS-DOS as well. You actually have to hit

Only programs written in C using the Acorn C library
interpret it as EOF. And I'm not aware of any C programs using
terminal input being supplied with the OS at all. I'm also not even
sure whether programs compiled with the GNU C Library function the
same way. Which goes back to my original point - I was providing a
counter-example to those saying that how to generate EOF is an "OS"
feature. For RISC OS it's just a C implementation feature.

By "OS" feature, I take it to mean by convention. Ctrl-D is simply
a common Unix convention for generating EOF. It can be mapped to
any key. On some Unix systems, it was mapped to <delete>.

If RISC OS lacks a convention for doing this, it simply speaks to its
esoteric beginnings as a GUI framework rather than a general purpose OS.
Until a CLI shell was developed for it, and hosted C implementation was
created for it, interactive text I/O was a non-issue. If the CLI shell
existed for a long time prior to the hosted C implementation, perhaps
a convention would have been developed for signalling interactively the
end of input.

Your discussion seems to indicate RISC OS never had such a convention,
so the hosted C implementation adopted the Unix convention. I don't
see a problem there.

Terminal input EOF is a C concept, alien to this particular operating
system, and maybe others.

I wouldn't say it is a C concept. C doesn't really have a concept of
"terminal". It really only has a concept of an I/O stream, which can be
either text or binary. Every input stream producer must have a way of
telling the consumer when the stream is done. Every OS that supports
the notion of an open ended input stream must have a mechanism of
detecting the end of the stream.

Which is why I wouldn't be adverse to it
getting a mention in the FAQ, pointing out that it is a feature C
inherits from Unix, and saying something like "if your OS doesn't
have terminal EOF, the C library implementors may have used Ctrl-D or
Ctrl-Z; check your implementation's documentation".

I don't think it qualifies as a FAQ. Users who have some familiarity
with their OS should either already understand its conventions, or know
where to look for answers.

Note that the use of Ctrl-Z to denote end of input predates Unix.

-- James

 

[Joe Wright]

[ snip ]

Note that the use of Ctrl-Z to denote end of input predates Unix.

Indeed? I first saw the 0x1A on CP/M systems of the late 1970's. CP/M
defined a file as a number of 128-byte records. The ^Z was written to
the end of a text file so that the exact length of the text could be
known. This was necessary in order to concatenate text files
successfully. I don't recall whether ^Z had any effect as console input.
It's been awhile..

 

[James Hu]

[ snip ]

Note that the use of Ctrl-Z to denote end of input predates Unix.

Indeed? I first saw the 0x1A on CP/M systems of the late 1970's. CP/M
defined a file as a number of 128-byte records. The ^Z was written to
the end of a text file so that the exact length of the text could be
known. This was necessary in order to concatenate text files
successfully. I don't recall whether ^Z had any effect as console input.
It's been awhile..

CP/M was influenced by the OS written for the PDP-8 (called OS8, then
later called PS/8, and then later called OS/8). The PDP-8 was first
introduced in 1965.

See the last paragraph of the following link.

http://www.faqs.org/faqs/dec-faq/pdp8/section-5.html

-- James

 

[Anuj Heer]

buddy u are entering a character that's why it doesnot work...instead
enter the 2's complement of -1...or it's binary equvivalent..i hope u
know how to do that...i will make it simpler

enter one of the following and it will work
129
or
255

 

[Joona I Palaste]

buddy u are entering a character that's why it doesnot work...instead
enter the 2's complement of -1...or it's binary equvivalent..i hope u
know how to do that...i will make it simpler

enter one of the following and it will work
129
or
255

Your answer could not be much more wrong.
Entering "129", "255", or any other input consisting of printable
characters will not work. "129", for example, will be interpreted as
the characters '1', '2' and '9', none of which equals the char value
-1.
Please learn the difference between a number and its textual
representation before giving misleading advice.
Oh, and please stop with all this "u" crap, thanks. It's "you".

 

[Richard Heathfield]

buddy u are entering a character that's why it doesnot work...instead
enter the 2's complement of -1...or it's binary equvivalent..i hope u
know how to do that...i will make it simpler
Nonsense.

enter one of the following and it will work
129
or
255

More nonsense.

 

[Chris Dollin]

A casual perusal of the web on RISC OS leads me to believe it was
developed specifically as an embedded OS that provides nice looking
on screen displays. The use of RISC OS as a desktop environment is
something relatively recent. Until it got on the desktop, interactive
text I/O wasn't even on the radar for the OS. I would characterize
the system as esoteric, not typical.

RISC OS arose as a desktop system; I used it, in its several variations,
for many years, on the progression of Acorn ARM-based machines. The first
RISC OS appeared in, mumble, the late 1980s.

It's always had interactive text input, as Arthur and the Beeb OS had
before it.

Until a CLI shell was developed for it, and hosted C implementation was
created for it, interactive text I/O was a non-issue. If the CLI shell
existed for a long time prior to the hosted C implementation, perhaps
a convention would have been developed for signalling interactively the
end of input.

Verily, RISC OS had a CLI from the begining. How else to support existing
CLI scripts?

Mind you, I can't bring to mind what the usual end-of-input character
was, or whether there was one; it just wasn't an important enough
issue to worry about, as I recall.

 

[Dan Pop]

[ snip ]

Note that the use of Ctrl-Z to denote end of input predates Unix.

Indeed? I first saw the 0x1A on CP/M systems of the late 1970's.

What DEC operating systems have you used during the late sixties and
early seventies?

CP/M
defined a file as a number of 128-byte records. The ^Z was written to
the end of a text file so that the exact length of the text could be
known. This was necessary in order to concatenate text files
successfully. I don't recall whether ^Z had any effect as console input.

It did. CP/M merely inherited it from RT-11, whose user interface it
tried to emulate, to a certain extent.

According to the ASCII specification, Ctrl-Z is a very strange choice for
the "end of console input" character. The natural choices are Ctrl-C
(END OF TEXT), Ctrl-D (END OF TRANSMISSION) and Ctrl-Y (END OF MEDIUM).

Ctrl-Z (SUBSTITUTE) is defined as:

A control character used in the place of a character that has been
found to be invalid or in error. SUB is intended to be introduced by
automatic means.

Dan

 

[Dan Pop]

Mind you, I can't bring to mind what the usual end-of-input character
was, or whether there was one; it just wasn't an important enough
issue to worry about, as I recall.

The end-of-input character is an unavoidable issue to any OS that allows
treating the system/program controlling console as a file. If, at the
OS CLI level you can do the equivalent of "copy CONDEV file" where CONDEV
is a special name assigned to the console device, you must also have a
well defined means of generating an eof condition on the console device.
If the OS is to offer a consistent interface, CONDEV can be used for the
same purpose *anywhere* a file name is required, with the same semantics.

OTOH, if the OS doesn't provide such a feature, there is no need for an
end-of-input character, either. Nevertheless, I've used even
non-interactive systems that provided a method of generating an
end-of-input condition on the program's standard input file, even when
that file was not on a medium intrinsically supporting the concept of
end of file (punch cards or paper type, where an end of medium condition
doesn't necessarily mean end of file: more cards could be fed to the
punch card reader or a single file may span more than one paper tape).

Dan

 

[James Hu]

RISC OS arose as a desktop system; I used it, in its several variations,
for many years, on the progression of Acorn ARM-based machines. The first
RISC OS appeared in, mumble, the late 1980s.

[NB: followup set to alt.folklore.computers]

I see, it was a competitor to Apple's MacOS and Commodore's AmigaOS.

It's always had interactive text input, as Arthur and the Beeb OS had
before it.

It had a command line interface from the scant bits of history I have
read, but how it worked is still a bit sketchy. Are you sure it wasn't
a programming environment like the old BASIC environments?

Verily, RISC OS had a CLI from the begining. How else to support existing
CLI scripts?

I am not sure if RISC OS really had a traditional native command shell.
POSIX support seems to have been an afterthought.

Mind you, I can't bring to mind what the usual end-of-input character
was, or whether there was one; it just wasn't an important enough
issue to worry about, as I recall.

Perhaps it was like most of the other iconic based user interfaces of
its day, where shell programming was a feature shoehorned into the
system rather than part of the integrated environment. I believe
AmigaOS was one of the few early exceptions.

-- James

 

[Safalra]

[snip] Commodore's AmigaOS.

It was called Workbench at the time. It only became AmigaOS in its
'recent' (has it been five years already?) resurrection (see
http://os.amiga.com/).

--- Stephen Morley ---
http://www.safalra.com

 

[Anuj Heer]

Your answer could not be much more wrong.
Entering "129", "255", or any other input consisting of printable
characters will not work. "129", for example, will be interpreted as
the characters '1', '2' and '9', none of which equals the char value
-1.
Please learn the difference between a number and its textual
representation before giving misleading advice.
Oh, and please stop with all this "u" crap, thanks. It's "you".

oops!!! i am sorry for the mistake and thaks for pointing it out to
me...i was actually reffering to the binary eqvivalent of the
charachters...just press down the alt key while typing the
numbers...that should work for "u"
anuj
(e-mail address removed)

 

[Lew Pitcher]

Anuj Heer wrote:
[snip]

oops!!! i am sorry for the mistake and thaks for pointing it out to
me...i was actually reffering to the binary eqvivalent of the
charachters...just press down the alt key while typing the
numbers...that should work for "u"

Gosh, I can /do/ that on my 3277 display terminal connected to my employers
OS/390 system? Funny, but the IBM manuals don't mention it anywhere.

 

[Debashish Chakravarty]

(e-mail address removed) (Anuj Heer) wrote in message

oops!!! i am sorry for the mistake and thaks for pointing it out to
me...i was actually reffering to the binary eqvivalent of the
charachters...just press down the alt key while typing the
numbers...that should work for "u"
anuj
(e-mail address removed)

What if the keyboard does not have an alt key? Do you have any idea
what this newsgroup discusses?

 

[CBFalconer]

Anuj Heer wrote:
[snip]

oops!!! i am sorry for the mistake and thaks for pointing it
out to me...i was actually reffering to the binary eqvivalent
of the charachters...just press down the alt key while typing
the numbers...that should work for "u"

Gosh, I can /do/ that on my 3277 display terminal connected to
my employers OS/390 system? Funny, but the IBM manuals don't
mention it anywhere.

He appears to be attempting to join Trollsdale and Schildt in
their unique niches of fatuous C instruction. We need a filter
that simply stamps a big fat watermark "Bovine Excrement" over
their works.

 

[Joona I Palaste]

(e-mail address removed) (Anuj Heer) wrote in message

What if the keyboard does not have an alt key? Do you have any idea
what this newsgroup discusses?

Not only that, what if the system doesn't have a *keyboard*?

 

[Dan Pop]

Not only that, what if the system doesn't have a *keyboard*?

Then, the issue of generating an eof condition from the keyboard becomes
moot. Are you sure you have engaged the brain before posting?

Dan

 

[Joona I Palaste]

Then, the issue of generating an eof condition from the keyboard becomes
moot. Are you sure you have engaged the brain before posting?

Well, one could assume that then the issue from generating EOF from
*another* input device would arise.
But I have to admit that since either Anuj or Debashish snipped away
the original question, I forgot what it was. Sorry about that.

 

[Dan Pop]

Well, one could assume that then the issue from generating EOF from
*another* input device would arise.

Well, you don't have to bother for most other input devices: they generate
an eof condition by themselves.

And, BTW, in C, EOF is a macro defined in <stdio.h>, you don't have
to generate it at all. The remark may seem pedantic, but plenty of
newbies get confused when EOF is used in an overloaded manner.

But I have to admit that since either Anuj or Debashish snipped away
the original question, I forgot what it was. Sorry about that.

It was a newbie having a problem with one of the first programs from K&R2.
The program reads one character from stdin and writes it to stdout,
terminating when an eof condition is detected.

Dan