By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,820 Members | 1,142 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,820 IT Pros & Developers. It's quick & easy.

EOF (novice)

P: n/a


--
Alan C this post ends with w
q

From K&R:

#include <stdio.h>

main()

/* copy input to output */

{

int c;

c = getchar();
while (c != EOF) {

putchar(c);
c = getchar();

}

}
If I am reading the text correctly, this program should
terminate when I enter -1 (EOF as defined on my system,
Linux).

But it doesn't. Just keeps right on trucking.

What gives?

AC
Nov 13 '05 #1
Share this Question
Share on Google+
76 Replies


P: n/a
When you enter -1, you enter two characters '-' and '1'. Neither equals -1.
Maybe you should enter Ctrl-D(?), which will produce a EOF.

"Alan Connor" <zz****@xxx.yyy> дʼ
news:Fi****************@newsread2.news.pas.earthli nk.net...


--
Alan C this post ends with w
q

From K&R:

#include <stdio.h>

main()

/* copy input to output */

{

int c;

c = getchar();
while (c != EOF) {

putchar(c);
c = getchar();

}

}
If I am reading the text correctly, this program should
terminate when I enter -1 (EOF as defined on my system,
Linux).

But it doesn't. Just keeps right on trucking.

What gives?

AC

Nov 13 '05 #2

P: n/a
Alan Connor <zz****@xxx.yyy> wrote:

Absolutely nothing.

Also,

"And sigs are limited to the four lines immediately below the delimiter.

Killfiled for 30 days.

Clean up your act."
Alan Connor, comp.lang.c, Nov 14, 2003.

Alex

Nov 13 '05 #3

P: n/a
On Wed, 19 Nov 2003 01:30:57 -0000, Seesaw <ma*******@hotmail.com> wrote:


When you enter -1, you enter two characters '-' and '1'. Neither equals -1.
Maybe you should enter Ctrl-D(?), which will produce a EOF.


Ctrl-c works just fine. But absolutely nothing was said about this
in K&R or the FAQ.

There isn't a single clue to be found.

Yet a large number of people here keep saying that K&R is for
beginners.
AC

Nov 13 '05 #4

P: n/a
Alan Connor wrote:
On Wed, 19 Nov 2003 01:30:57 -0000, Seesaw <ma*******@hotmail.com> wrote:
When you enter -1, you enter two characters '-' and '1'. Neither equals -1.
Maybe you should enter Ctrl-D(?), which will produce a EOF.


Ctrl-c works just fine. But absolutely nothing was said about this
in K&R or the FAQ.

There isn't a single clue to be found.

Yet a large number of people here keep saying that K&R is for
beginners.


Alan...

The mechanism for causing an end-of-file condition to be
recognized varies from platform to platform, from OS to OS, and
sometimes from implementation to implementation. There isn't a
single right answer that could've been included in the FAQ or in K&R.

Usually (but not always), not being able to find some piece of
information in both the FAQ and K&R is a clue that the
information sought will depend on either the platform, OS or
implementation.

But thanks for remembering to check the FAQ before posting.
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

Nov 13 '05 #5

P: n/a
On Tue, 18 Nov 2003 21:01:36 -0600, Morris Dovey <mr*****@iedu.com> wrote:


Alan Connor wrote:
On Wed, 19 Nov 2003 01:30:57 -0000, Seesaw <ma*******@hotmail.com> wrote:
When you enter -1, you enter two characters '-' and '1'. Neither equals -1.
Maybe you should enter Ctrl-D(?), which will produce a EOF.


Ctrl-c works just fine. But absolutely nothing was said about this
in K&R or the FAQ.

There isn't a single clue to be found.

Yet a large number of people here keep saying that K&R is for
beginners.


Alan...

The mechanism for causing an end-of-file condition to be
recognized varies from platform to platform, from OS to OS, and
sometimes from implementation to implementation. There isn't a
single right answer that could've been included in the FAQ or in K&R.

Usually (but not always), not being able to find some piece of
information in both the FAQ and K&R is a clue that the
information sought will depend on either the platform, OS or
implementation.

But thanks for remembering to check the FAQ before posting.


And the above is EXACTLY what should be in both K&R and the FAQ, as
well as clues such as offered by Seesaw.

Otherwise you have a novice with a program that just won't stop.

and not a clue as to what to do about it.

Thanks much, Morris.

AC

Nov 13 '05 #6

P: n/a
Alan Connor wrote:
On Tue, 18 Nov 2003 21:01:36 -0600, Morris Dovey <mr*****@iedu.com> wrote:
<snip>
Usually (but not always), not being able to find some piece of
information in both the FAQ and K&R is a clue that the
information sought will depend on either the platform, OS or
implementation.

And the above is EXACTLY what should be in both K&R and the FAQ, as
well as clues such as offered by Seesaw.

Otherwise you have a novice with a program that just won't stop.

and not a clue as to what to do about it.


Aha! You've just discovered the value of usenet! :-)

A document that answered all possible questions would be
impossibly large - too large to be generally useful. Steve's FAQ
is actually a really good compendium of the /most/ Frequently
Asked Questions (particularly so when we consider that it's free
and the product of donated - but none the less valuable - time
and effort.)

K&R attempts (and succeeds) in providing a /succinct/
presentation of the language. Messrs Kernighan and Ritchie
/don't/ spoon feed the reader; they expect us to read with our
brains fully engaged. It's a different mode of presentation than
used by most authors; and it demands more of the reader. Don't
let yourself be put off just because they're not condescending.

--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

Nov 13 '05 #7

P: n/a
On Tue, 18 Nov 2003 22:39:09 -0600, Morris Dovey <mr*****@iedu.com> wrote:
K&R attempts (and succeeds) in providing a /succinct/
presentation of the language. Messrs Kernighan and Ritchie
/don't/ spoon feed the reader; they expect us to read with our
brains fully engaged.


That's a strange way to put it: "spoon feed".

It is a book written for people who already know how to
program and want to learn C.

No amount of "brain engaging" could EVER have arrived at
the use of Ctrl-c or Ctrl-d for that program.

There was not a single clue that could possibly lead ANYONE
to those keybindings.

(and I studied the header files too)

Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

You seem to attach some sort of stigma to novices, as if
you weren't one yourself at some point.

You were. There was a time when you thought a pointer was
a kind of domestic dog.

--
Alan C this post ends with w
q
Nov 13 '05 #8

P: n/a

On Wed, 19 Nov 2003, Alan Connor wrote:

On Tue, 18 Nov 2003 22:39:09 -0600, Morris Dovey <mr*****@iedu.com> wrote:

K&R attempts (and succeeds) in providing a /succinct/
presentation of the language. Messrs Kernighan and Ritchie
/don't/ spoon feed the reader; they expect us to read with our
brains fully engaged.
That's a strange way to put it: "spoon feed".

It is a book written for people who already know how to
program and want to learn C.

No amount of "brain engaging" could EVER have arrived at
the use of Ctrl-c or Ctrl-d for that program.


That's because K&R is a book about *C*, not *Unix*. You
wanna learn Unix, go buy a book about Unix. You wanna learn
MS-DOS, go buy a book about MS-DOS. You wanna learn VMS...
well, you get the idea.
There was not a single clue that could possibly lead ANYONE
to those keybindings.
Bring it up with Ken Thompson next time you see him.
Personally, I like DOS's Ctrl-Z convention better than
Unix's Ctrl-D, 'cause Z "looks like" EOF in that they're
both ends of things (alphabet and file, respectively).
But that's just not the way your operating system works.
(and I studied the header files too)

Unless they already knew at least a high-level language like
sh (that's me).
Good for you. So, knowing sh, and running a Linux
machine, surely you should have used 'cat' once or twice
from the command line, right? If so, you have no excuse.
If not, well, okay, just go back up and read that paragraph
advising you to learn *nix from a *nix book.
And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."


<OT>
Ctrl-C, in Unix, *is* an "emergency out."
Ctrl-D is an EOF "marker" of sorts.
Ctrl-Z will halt the current process.
There are some other Ctrl-[key] combinations that
work on my machine, but they're also off-topic here.
</OT>

HTH,
-Arthur
Nov 13 '05 #9

P: n/a
"Alan Connor" <zz****@xxx.yyy> wrote in message
news:Kf*****************@newsread2.news.pas.earthl ink.net...
On Tue, 18 Nov 2003 22:39:09 -0600, Morris Dovey <mr*****@iedu.com> wrote:
K&R attempts (and succeeds) in providing a /succinct/
presentation of the language. Messrs Kernighan and Ritchie
/don't/ spoon feed the reader; they expect us to read with our
brains fully engaged.
That's a strange way to put it: "spoon feed".

It is a book written for people who already know how to
program and want to learn C.

No amount of "brain engaging" could EVER have arrived at
the use of Ctrl-c or Ctrl-d for that program.


Because neither of those 'keystrokes' (or any others)
are defined by the language. They're defined by the
host operating system.

There was not a single clue that could possibly lead ANYONE
to those keybindings.
Because C does not have any 'key bindings'. Nor is there
any requirement that standard input be connected to a keyboard
at all.

(and I studied the header files too)

Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

You seem to attach some sort of stigma to novices, as if
you weren't one yourself at some point.
I don't think he does. I think Morris does a fine job
of helping novices with C.

You were. There was a time when you thought a pointer was
a kind of domestic dog.


False context. Shame, shame. :-)

-Mike
Nov 13 '05 #10

P: n/a
Alan Connor wrote:

On Tue, 18 Nov 2003 22:39:09 -0600, Morris Dovey <mr*****@iedu.com> wrote:
K&R attempts (and succeeds) in providing a /succinct/
presentation of the language. Messrs Kernighan and Ritchie
/don't/ spoon feed the reader; they expect us to read with our
brains fully engaged.
That's a strange way to put it: "spoon feed".

It is a book written for people who already know how to
program and want to learn C.


And that is what it does.
No amount of "brain engaging" could EVER have arrived at
the use of Ctrl-c or Ctrl-d for that program.

Well, it used to be CTRL-Y for BASIC prgams on HP minis. Mighta
worked for other languages, don't remember.

It's a pseudo-standard.
There was not a single clue that could possibly lead ANYONE
to those keybindings.

(and I studied the header files too)

Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

You seem to attach some sort of stigma to novices, as if
you weren't one yourself at some point.

We all were, but the sign helps folks know how best to
help people.
You were. There was a time when you thought a pointer was
a kind of domestic dog.
Nuh uh. A sister. Hot, boinin, doin tha neutron dance...

--
Alan C this post ends with w
q

--
Les Cargill
Nov 13 '05 #11

P: n/a
Mac
On Wed, 19 Nov 2003 02:02:27 +0000, Alan Connor wrote:
On Wed, 19 Nov 2003 01:30:57 -0000, Seesaw <ma*******@hotmail.com> wrote:


When you enter -1, you enter two characters '-' and '1'. Neither equals -1.
Maybe you should enter Ctrl-D(?), which will produce a EOF.


Ctrl-c works just fine. But absolutely nothing was said about this
in K&R or the FAQ.

There isn't a single clue to be found.

Yet a large number of people here keep saying that K&R is for
beginners.
AC


At the risk of telling you what you already know (in which case lets just
say its for the lurkers) Ctrl-c and Ctrl-d do two very different things.
Ctrl-d is the console's way of saying end of file during interactive
sessions. Ctrl-c raises a signal which, causes naive programs to terminate.

Mac
--
Nov 13 '05 #12

P: n/a
Alan Connor wrote:


Thanks, Alan, for this beautifully clear article, with its admirable brevity
and, in a complete turn-about from your normal style, its scintillating
charm and wit.

Oh, by the way, we have a guy round here, a Mr Connor, who is very big on
netiquette, and especially sig block sizes. Please keep your sig block to
four lines or below in future. 30+ lines is just not acceptable.

Thanks.

(Alan's sig block was trimmed from this reply by my newsreader, so I don't
actually know what it says without digging it out from the original, so I
guess his C question, if he had one, will have to go swing.)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #13

P: n/a
Thanks for the insight and the good humor from:

Arthur

Les

Mike

Mac

-----------------

I guess I had better follow Morris's advice and "fully engage
my brain".

Now: If I could just remember where I put it. Kinda squishy, right?
Maybe the size of a cantaloupe? 8-)

AC

Nov 13 '05 #14

P: n/a
Alan Connor wrote:
On Tue, 18 Nov 2003 22:39:09 -0600, Morris Dovey
<mr*****@iedu.com> wrote:
K&R attempts (and succeeds) in providing a /succinct/
presentation of the language. Messrs Kernighan and Ritchie
/don't/ spoon feed the reader; they expect us to read with
our brains fully engaged.
That's a strange way to put it: "spoon feed".


??? That may be a "midwesternism" (USA central region) for being
given information in (small) measured amounts so as to not
overwhelm the recipient.
It is a book written for people who already know how to
program and want to learn C.
True. Doesn't that describe you?
No amount of "brain engaging" could EVER have arrived at the
use of Ctrl-c or Ctrl-d for that program.
True. The keyboard mechanism isn't part of the language. The
standard provides a mechanism to recognize the end-of-file
condition for a /stream/ without requiring that there even /be/ a
keyboard associated with any of those streams.

BTW, on one of my systems Ctrl-Z generates EOF; and on another
Ctrl-X has the same effect. A number of the machines I've
programmed in C have no keyboard at all.

The point you're missing is that the mechanism for *generating*
an EOF condition from a keyboard is /not/ a C language issue and
should be described in other, probably OS, documentation.
*Testing* for the condition within a C program /is/ a C language
issue and should be described in C language documentation.
There was not a single clue that could possibly lead ANYONE to
those keybindings.
Appropriate, if not convenient. The key bindings aren't
determined by (or relevant to) the C standard. BTW, one of the
advantages of becoming familiar with the standard is knowing what
/is/ and what is /not/ part of the language. I'm sorry you had
difficulties.
(and I studied the header files too)
This is evidence that my comment about bindings is accurate.
Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

You seem to attach some sort of stigma to novices, as if you
weren't one yourself at some point.
No, I really don't attach any sort of stigma to any stage of
development. Actually, I'm pleased that you're interested in at
least one of the same things that I find fascinating; and I'm at
least a bit envious that you have free access to the human
resources (via the web and usenet) that weren't available to me
when I began. Strange as it may sound, I'd been programming in C
for more than two years before I met another C programmer - and
for more than a decade before I ever heard of usenet.
You were. There was a time when you thought a pointer was a
kind of domestic dog.


:-) Actually, I'd been programming in a number of assembly
languages (and a number of high-level languages) for more than
ten years before I started with C. /Addresses/ were actually a
pretty basic concept, and most of the machines I programmed had
/indirect/ addressing modes - which made pointers and
pointers-to-pointers fairly natural to me.

--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

Nov 13 '05 #15

P: n/a
On Wed, 19 Nov 2003 01:35:47 -0600, Morris Dovey <mr*****@iedu.com> wrote:

<snip>
No amount of "brain engaging" could EVER have arrived at the
use of Ctrl-c or Ctrl-d for that program.


True. The keyboard mechanism isn't part of the language. The
standard provides a mechanism to recognize the end-of-file
condition for a /stream/ without requiring that there even /be/ a
keyboard associated with any of those streams.


You are missing my point: The program as written in K&R *doesn't
work*. Or it seems not to.

That part of the book is POORLY WRITTEN. Lame.

BTW, on one of my systems Ctrl-Z generates EOF; and on another
Ctrl-X has the same effect. A number of the machines I've
programmed in C have no keyboard at all.
That's bizarre, but why not? The KB is only *standard* input.

The point you're missing is that the mechanism for *generating*
an EOF condition from a keyboard is /not/ a C language issue and
should be described in other, probably OS, documentation.
*Testing* for the condition within a C program /is/ a C language
issue and should be described in C language documentation.
There was not a single clue that could possibly lead ANYONE to
those keybindings.
Appropriate, if not convenient. The key bindings aren't
determined by (or relevant to) the C standard. BTW, one of the
advantages of becoming familiar with the standard is knowing what
/is/ and what is /not/ part of the language. I'm sorry you had


difficulties.


Kind of you.
(and I studied the header files too)


This is evidence that my comment about bindings is accurate.
Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

You seem to attach some sort of stigma to novices, as if you
weren't one yourself at some point.


No, I really don't attach any sort of stigma to any stage of
development. Actually, I'm pleased that you're interested in at
least one of the same things that I find fascinating; and I'm at
least a bit envious that you have free access to the human
resources (via the web and usenet) that weren't available to me
when I began. Strange as it may sound, I'd been programming in C
for more than two years before I met another C programmer - and
for more than a decade before I ever heard of usenet.
You were. There was a time when you thought a pointer was a
That's pretty hardcore.
kind of domestic dog.


:-) Actually, I'd been programming in a number of assembly
languages (and a number of high-level languages) for more than
ten years before I started with C. /Addresses/ were actually a
pretty basic concept, and most of the machines I programmed had
/indirect/ addressing modes - which made pointers and
pointers-to-pointers fairly natural to me.


I am finding that assembly language is very helpful in understanding
C, which can be just too damned abstract.

Thanks a lot, Morris. Seen any corn lately :-|

AC

Nov 13 '05 #16

P: n/a
On Wed, 19 Nov 2003 01:35:47 -0600, Morris Dovey <mr*****@iedu.com> wrote:

<snip>
No amount of "brain engaging" could EVER have arrived at the
use of Ctrl-c or Ctrl-d for that program.


True. The keyboard mechanism isn't part of the language. The
standard provides a mechanism to recognize the end-of-file
condition for a /stream/ without requiring that there even /be/ a
keyboard associated with any of those streams.


You are missing my point: The program as written in K&R *doesn't
work*. Or it seems not to.

That part of the book is POORLY WRITTEN. Lame.

BTW, on one of my systems Ctrl-Z generates EOF; and on another
Ctrl-X has the same effect. A number of the machines I've
programmed in C have no keyboard at all.
That's bizarre, but why not? The KB is only *standard* input.

The point you're missing is that the mechanism for *generating*
an EOF condition from a keyboard is /not/ a C language issue and
should be described in other, probably OS, documentation.
*Testing* for the condition within a C program /is/ a C language
issue and should be described in C language documentation.
There was not a single clue that could possibly lead ANYONE to
those keybindings.
Appropriate, if not convenient. The key bindings aren't
determined by (or relevant to) the C standard. BTW, one of the
advantages of becoming familiar with the standard is knowing what
/is/ and what is /not/ part of the language. I'm sorry you had


difficulties.


Kind of you.
(and I studied the header files too)


This is evidence that my comment about bindings is accurate.
Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

You seem to attach some sort of stigma to novices, as if you
weren't one yourself at some point.


No, I really don't attach any sort of stigma to any stage of
development. Actually, I'm pleased that you're interested in at
least one of the same things that I find fascinating; and I'm at
least a bit envious that you have free access to the human
resources (via the web and usenet) that weren't available to me
when I began. Strange as it may sound, I'd been programming in C
for more than two years before I met another C programmer - and
for more than a decade before I ever heard of usenet.
You were. There was a time when you thought a pointer was a
That's pretty hardcore.
kind of domestic dog.


:-) Actually, I'd been programming in a number of assembly
languages (and a number of high-level languages) for more than
ten years before I started with C. /Addresses/ were actually a
pretty basic concept, and most of the machines I programmed had
/indirect/ addressing modes - which made pointers and
pointers-to-pointers fairly natural to me.


I am finding that assembly language is very helpful in understanding
C, which can be just too damned abstract.

Thanks a lot, Morris. Seen any corn lately :-|

AC

Nov 13 '05 #17

P: n/a
On Wed, 19 Nov 2003 08:33:49 +0000, Alan Connor wrote:
On Wed, 19 Nov 2003 01:35:47 -0600, Morris Dovey <mr*****@iedu.com> wrote:

True. The keyboard mechanism isn't part of the language. The
standard provides a mechanism to recognize the end-of-file
condition for a /stream/ without requiring that there even /be/ a
keyboard associated with any of those streams.
You are missing my point: The program as written in K&R *doesn't
work*. Or it seems not to.


That is because of the user not understanding what the program is supposed
to do.

If you thought typing '-' and then '1' would make the program stop you
need to go back and read again since the program reads one character at a
time and echoes it back. '-' and '1' would be two separate characters.
That part of the book is POORLY WRITTEN. Lame.


No, all of the book is written with the assumption that the reader is
already a programmer, and is familiar with his choice of operating system.

The alternative would be to write a book "The C Programming Language on
FOO" where FOO is an operating system, having several versions of the
book, and making a new one every time a new and "improved" version of the
OS is out.

That's the beauty of K&R since it doesn't do OS specific it doesn't get
outdated with the OS-es
BTW, on one of my systems Ctrl-Z generates EOF; and on another
Ctrl-X has the same effect. A number of the machines I've
programmed in C have no keyboard at all.


That's bizarre, but why not? The KB is only *standard* input.


How is that bizarre? A lot of things have computers in them, (microwave
ovens, dishwashers) without having a keyboard.

And the keyboard isn't standrd, standard inout is whatever the OS tells
the program it is.

An example:
cat foo | bar

Standard input for the program bar isn't the keyboard, but whatever output
comes out of "cat foo"

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

Nov 13 '05 #18

P: n/a
On 2003-11-19, Alan Connor <zz****@xxx.yyy> wrote:
No amount of "brain engaging" could EVER have arrived at
the use of Ctrl-c or Ctrl-d for that program.

There was not a single clue that could possibly lead ANYONE
to those keybindings.

Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."


The difference between delivering an interrupt signal and delivering
an "end of input" notification can be observed via an example:

#include <stdio.h>
int main(void)
{
int c;
while ((c = getchar()) != EOF) {
putchar(c);
}
puts("Done");
return 0;
}

You might even try:

#include <stdio.h>
#include <setjmp.h>
#include <signal.h>
static jmp_buf env;
static void interrupted(int s) { longjmp(env, s-s-1); }
int main(void)
{
int c;
if (signal(SIGINT, interrupted) == SIG_ERR) {
puts("Couldn't set signal handler for SIGINT");
return 0;
}
if (setjmp(env) == 0) {
while ((c = getchar()) != EOF) {
putchar(c);
}
puts("Done");
} else {
puts("Interrupted");
}
return 0;
}

-- James
Nov 13 '05 #19

P: n/a
Nils Petter Vaskinn wrote:
On Wed, 19 Nov 2003 08:33:49 +0000, Alan Connor wrote:

.... snip ...

You are missing my point: The program as written in K&R *doesn't
work*. Or it seems not to.


That is because of the user not understanding what the program is
supposed to do.

If you thought typing '-' and then '1' would make the program stop
you need to go back and read again since the program reads one
character at a time and echoes it back. '-' and '1' would be two
separate characters.


And I doubt very much that K&R ever suggested exiting the program
by generating -1. They may well have suggested testing the input
value against EOF, which is not necessarily the value -1. The
elementary and obvious technique of looking up EOF in the index
would lead to further information which in turn makes the use of
-1 obviously foolish.

Using the above esoteric technique I found information on EOF on
page 16 of K&R2. This would appear to indicate that Mr. Connor
has not read and absorbed the first 16 pages. He is thus
eminently qualified to criticize the books usefulness as
instructive material.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #20

P: n/a


On 11/18/2003 8:02 PM, Alan Connor wrote:
On Wed, 19 Nov 2003 01:30:57 -0000, Seesaw <ma*******@hotmail.com> wrote:

When you enter -1, you enter two characters '-' and '1'. Neither equals -1.
Maybe you should enter Ctrl-D(?), which will produce a EOF.

Ctrl-c works just fine.


Typing Ctrl-D is usually, but not always, how to provide an EOF. Typing that
when manually entering input is just like if you ran your program redirecting
input from a text file instead of typing it you'd get an EOF at the end of the
input stream. Typing Ctrl-C (or "Ctrl-?" or "Del" or whatever your interrupt
keystroke happens to be) interrupts the running process just like it would if
that process were exeucting a shell script instead of a C program.

But absolutely nothing was said about this in K&R or the FAQ.


Well, no, it wouldn't be. It isn't a C issue, it's a UNIX one, and it's a
question that I've never seen asked before in this NG so it wouldn't qualify as
"Frequently Asked". It is, however, addressed in the ksh manual page:

eof End-of-file character, normally ^D, is processed
as an End-of-file.....

Regards,

Ed.
Nov 13 '05 #21

P: n/a
In message <QM*****************@newsread1.news.pas.earthlink. net>
"Mike Wahler" <mk******@mkwahler.net> wrote:
"Alan Connor" <zz****@xxx.yyy> wrote in message
news:Kf*****************@newsread2.news.pas.earthl ink.net...
On Tue, 18 Nov 2003 22:39:09 -0600, Morris Dovey <mr*****@iedu.com> wrote:
K&R attempts (and succeeds) in providing a /succinct/
presentation of the language. Messrs Kernighan and Ritchie
/don't/ spoon feed the reader; they expect us to read with our
brains fully engaged.


That's a strange way to put it: "spoon feed".

It is a book written for people who already know how to
program and want to learn C.

No amount of "brain engaging" could EVER have arrived at
the use of Ctrl-c or Ctrl-d for that program.


Because neither of those 'keystrokes' (or any others)
are defined by the language. They're defined by the
host operating system.


Not necessarily. My OS doesn't have a concept of EOF for terminal input
at all. C assumes one for trivial programs like that, so the C library
itself decides to follow the Unix Ctrl-D convention. I'd agree that this
should be in the FAQ - for many non-Unix systems, terminal EOF is a purely
"C" concept.

I'd been using C for over a year on my platform before I found out about
Ctrl-D; I'd hitherto assumed that EOF wasn't possible on stdin.

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1223 503458
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
Nov 13 '05 #22

P: n/a
Alan Connor <zz****@xxx.yyy> wrote in message news:<NV*****************@newsread2.news.pas.earth link.net>...
On Wed, 19 Nov 2003 01:35:47 -0600, Morris Dovey <mr*****@iedu.com> wrote:

<snip>
No amount of "brain engaging" could EVER have arrived at the
use of Ctrl-c or Ctrl-d for that program.


True. The keyboard mechanism isn't part of the language. The
standard provides a mechanism to recognize the end-of-file
condition for a /stream/ without requiring that there even /be/ a
keyboard associated with any of those streams.


You are missing my point: The program as written in K&R *doesn't
work*. Or it seems not to.


It works *just fine*. If you generate an EOF, it will terminate. The
details of how to generate an EOF on a particular system is beyond the
scope of that particular tutorial. Sorry that got past you.

That part of the book is POORLY WRITTEN. Lame.


Maybe you'd prefer Herb Schildt? He's an excellent writer, he just
doesn't know C very well.

BTW, on one of my systems Ctrl-Z generates EOF; and on another
Ctrl-X has the same effect. A number of the machines I've
programmed in C have no keyboard at all.


That's bizarre, but why not? The KB is only *standard* input.


Except for systems where it isn't. Think about any number of embedded
controllers, modems, etc. All The World Is NOT An x86 Desktop System.

[snip rest]
Nov 13 '05 #23

P: n/a
Kevin Bracey wrote:
.... snip ...
Not necessarily. My OS doesn't have a concept of EOF for terminal
input at all. C assumes one for trivial programs like that, so the
C library itself decides to follow the Unix Ctrl-D convention. I'd
agree that this should be in the FAQ - for many non-Unix systems,
terminal EOF is a purely "C" concept.
I rather doubt that. However, nothing insists that you can
generate such a signal from the keyboard; it may require physical
destruction of something.

I'd been using C for over a year on my platform before I found out
about Ctrl-D; I'd hitherto assumed that EOF wasn't possible on
stdin.


Some systems hide the mechanism. On the HP3000 under MPE it
required ":EOF" at the prompt, after which the terminal was
useless until action was taken by the system operator or the whole
system was taken down and reinitialized. Very useful for playing
pranks. It also meant that you used something else to signal "end
of input".

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #24

P: n/a
In <d2****************@tematic.com> Kevin Bracey <ke**********@tematic.com> writes:
In message <QM*****************@newsread1.news.pas.earthlink. net>
"Mike Wahler" <mk******@mkwahler.net> wrote:
Because neither of those 'keystrokes' (or any others)
are defined by the language. They're defined by the
host operating system.
Not necessarily. My OS doesn't have a concept of EOF for terminal input
at all. C assumes one for trivial programs like that, so the C library
itself decides to follow the Unix Ctrl-D convention. I'd agree that this
should be in the FAQ - for many non-Unix systems, terminal EOF is a purely
"C" concept. ^^^^


Are there so many such systems? The concept seems to predate Unix
and C by a large margin and I've used plenty of systems, some of
them having nothing in common with Unix and not providing a C
implementation at all, but all of them had one way or another of
signaling end of file on the standard input (even the punch card
based ones). The only exceptions I can think of are micros using a BASIC
interpreter instead of an operating system.
I'd been using C for over a year on my platform before I found out about
Ctrl-D; I'd hitherto assumed that EOF wasn't possible on stdin.


Reading the implementation's documentation can be a rewarding exercise ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #25

P: n/a
On Wed, 19 Nov 2003 05:09:36 -0600, James Hu <jx*@despammed.com> wrote:

<snip>

Thanks, James.

AC

Nov 13 '05 #26

P: n/a
On Wed, 19 Nov 2003 13:04:02 GMT, CBFalconer <cb********@yahoo.com> wrote:

<snip>

Mr. Falconer. This is the third post in a row I have gotten from you that
is abusive in nature.

Stick them where the sun don't shine and get the fuck out of my life.

killfiled for 90 days.
AC

Nov 13 '05 #27

P: n/a
On Wed, 19 Nov 2003 10:08:01 -0600, Ed Morton <mo****************@lucent.com> wrote:

<snip>

Thanks, Ed. That was helpful.

AC

Nov 13 '05 #28

P: n/a
On 19 Nov 2003 09:48:39 -0800, John Bode <jo*******@my-deja.com> wrote:

<snip>

Point taken, John. Thank you.

AC

Nov 13 '05 #29

P: n/a
Alan Connor wrote:
Stick them where the sun don't shine and get the fuck out of my life.


Please don't use foul language on this newsgroup.

Thank you.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #30

P: n/a
Christopher Benson-Manica wrote:
Richard Heathfield <do******@address.co.uk.invalid> spoke thus:
Please don't use foul language on this newsgroup.


If everyone KF'ed him and no one responded, it would be a moot
point...


....and he would then be at liberty to dispense all the crap C advice he
wanted, with nobody to correct him.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #31

P: n/a
Sheldon Simms wrote:
On Wed, 19 Nov 2003 20:02:32 +0000, Alan Connor wrote:
killfiled for 90 days.


I'm getting tired of reading your abusive posts in this newsgroup

killfiled for 30 days.

And don't talk back or I'll send you to your room for another 30 days.


He's already in his room. I doubt very much whether he's allowed downstairs
except for meals.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #32

P: n/a
In message <bp*********@sunnews.cern.ch>
Da*****@cern.ch (Dan Pop) wrote:
In <d2****************@tematic.com> Kevin Bracey <ke**********@tematic.com> writes:
I'd been using C for over a year on my platform before I found out about
Ctrl-D; I'd hitherto assumed that EOF wasn't possible on stdin.


Reading the implementation's documentation can be a rewarding exercise ;-)


I don't think it's actually in the documentation. I could be wrong though.

Any RISC OS users out there spotted it in the compiler manuals or
programmer's reference manual?

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1223 503458
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
Nov 13 '05 #33

P: n/a
Kevin Bracey wrote:
In message <bp*********@sunnews.cern.ch>
Da*****@cern.ch (Dan Pop) wrote:

In <d2****************@tematic.com> Kevin Bracey <ke**********@tematic.com> writes:

I'd been using C for over a year on my platform before I found out about
Ctrl-D; I'd hitherto assumed that EOF wasn't possible on stdin.


Reading the implementation's documentation can be a rewarding exercise ;-)

I don't think it's actually in the documentation. I could be wrong though.

Any RISC OS users out there spotted it in the compiler manuals or
programmer's reference manual?


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.


--
Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

Nov 13 '05 #34

P: n/a
In message <Ih******************@news20.bellglobal.com>
Lew Pitcher <Le*********@td.com> wrote:
Kevin Bracey wrote:
In message <bp*********@sunnews.cern.ch>
Da*****@cern.ch (Dan Pop) wrote:

In <d2****************@tematic.com> Kevin Bracey <ke**********@tematic.com> writes:
I'd been using C for over a year on my platform before I found out about
Ctrl-D; I'd hitherto assumed that EOF wasn't possible on stdin.

Reading the implementation's documentation can be a rewarding exercise ;-)


I don't think it's actually in the documentation. I could be wrong
though.

Any RISC OS users out there spotted it in the compiler manuals or
programmer's reference manual?


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".

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1223 503458
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
Nov 13 '05 #35

P: n/a
On 2003-11-21, Kevin Bracey <ke**********@tematic.com> wrote:
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
<enter> after typing Ctrl-Z to enter the character into the text
stream. But, on the command line, Ctrl-Z doesn't do anything special.
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
Nov 13 '05 #36

P: n/a
James Hu wrote:
[ 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.. :-)
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 13 '05 #37

P: n/a
On 2003-11-22, Joe Wright <jo********@earthlink.net> wrote:
James Hu wrote:

[ 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
Nov 13 '05 #38

P: n/a
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
Nov 13 '05 #39

P: n/a
Anuj Heer <hp*****@vcustomer.net> scribbled the following:
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".

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"C++ looks like line noise."
- Fred L. Baube III
Nov 13 '05 #40

P: n/a
Anuj Heer wrote:
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.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #41

P: n/a
James Hu wrote:
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.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html
Nov 13 '05 #42

P: n/a
In <3F***********@earthlink.net> Joe Wright <jo********@earthlink.net> writes:
James Hu wrote:
[ 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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #43

P: n/a
In <bp**********@murdoch.hpl.hp.com> Chris Dollin <ke**@hpl.hp.com> writes:
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #44

P: n/a
On 2003-11-24, Chris Dollin <ke**@hpl.hp.com> wrote:
James Hu wrote:
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.


[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
Nov 13 '05 #45

P: n/a
James Hu <jx*@despammed.com> wrote in message news:<1f********************@comcast.com>...
[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
Nov 13 '05 #46

P: n/a
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<bp**********@oravannahka.helsinki.fi>...
Anuj Heer <hp*****@vcustomer.net> scribbled the following:
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".

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
hp*****@vcustomer.net
Nov 13 '05 #47

P: n/a
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.

--
Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

Nov 13 '05 #48

P: n/a
hp*****@vcustomer.net (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
hp*****@vcustomer.net


What if the keyboard does not have an alt key? Do you have any idea
what this newsgroup discusses?
Nov 13 '05 #49

P: n/a
Lew Pitcher wrote:
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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #50

76 Replies

This discussion thread is closed

Replies have been disabled for this discussion.