From: Rosario on
In data Sun, 18 Nov 2007 14:00:27 -0800 (PST), �ar�nas Kazlauskas
scrisse:

>... or how do you know you've reached the end of txt file?

in the little i know there is not "ascii symbols" for EOF[end of file]

i know that the file is end, when fgetc or getc return -1 that is in a
macro called "EOF"
From: Terence on
On Nov 20, 12:45 pm, Phil Carmody <thefatphil_demun...(a)yahoo.co.uk>
wrote:

> Ctrl-Z in the ASCII standard in use when CP/M and DOS
> were being designed is the SUB (substitute) character,
> used to indicate that the character was read/received
> with some kind of error (e.g. parity error), and this
> is a placeholder. There were plenty of "end of <blah>"
> characters in ASCII, but 26 wasn't one of them.

Ctrl-Z is in fact the correct code to indicate end-of-text from the
keyboard.
It still works in current MS operating systems and is hunted for in
the processing of input from the keyboard when using service calls for
keyboard input.

NAK is also #1a in asynchronous RS232C protocol, and #11 is ACK.
From: Phil Carmody on
Charles Crayne <ccrayne(a)crayne.org> writes:
> On 20 Nov 2007 03:45:39 +0200
> Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote:
>
> > Ctrl-Z in the ASCII standard in use when CP/M and DOS
> > were being designed is the SUB (substitute) character,
> > used to indicate that the character was read/received
> > with some kind of error (e.g. parity error), and this
> > is a placeholder. There were plenty of "end of <blah>"
> > characters in ASCII, but 26 wasn't one of them.
>
> The Dos 2.00 reference manual has this to say about that:
>
> "Combining files is normally performed in text (or ASCII) mode. That
> is, the first Ctrl-A (hex 1A) character in the file is interpreted as
> an end-of-file mark."

My point was that this was not an ASCII definition of
the meaning of the character. Lots of people are throwing
the initialism around as if it were pertinent somehow,
it's not.

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration
From: Wolfgang Kern on

Phil Carmody wrote:

>>> Ctrl-Z in the ASCII standard in use when CP/M and DOS
>>> were being designed is the SUB (substitute) character,
>>> used to indicate that the character was read/received
>>> with some kind of error (e.g. parity error), and this
>>> is a placeholder. There were plenty of "end of <blah>"
>>> characters in ASCII, but 26 wasn't one of them.

>> The Dos 2.00 reference manual has this to say about that:

>> "Combining files is normally performed in text (or ASCII) mode. That
>> is, the first Ctrl-A (hex 1A) character in the file is interpreted as
>> an end-of-file mark."

> My point was that this was not an ASCII definition of
> the meaning of the character. Lots of people are throwing
> the initialism around as if it were pertinent somehow,
> it's not.

Yes, both defininitions for ascii-control and unicode are conform
and specifiy char(03h) as EOT 'end of text',
while ctrl-A (01h) is SOH 'start of header'.
I've seen many variants of text end-marks starting with a single
00h until a bit7-set literally "EOT/EOF" (c5,d0,d4/c6).
M$-formats may have changed too often, so my latest text-editor
seem to use just the file size to tell the end.

__
wolfgang



From: H. Peter Anvin on
Terence wrote:
> On Nov 20, 12:45 pm, Phil Carmody <thefatphil_demun...(a)yahoo.co.uk>
> wrote:
>
>> Ctrl-Z in the ASCII standard in use when CP/M and DOS
>> were being designed is the SUB (substitute) character,
>> used to indicate that the character was read/received
>> with some kind of error (e.g. parity error), and this
>> is a placeholder. There were plenty of "end of <blah>"
>> characters in ASCII, but 26 wasn't one of them.
>
> Ctrl-Z is in fact the correct code to indicate end-of-text from the
> keyboard.
> It still works in current MS operating systems and is hunted for in
> the processing of input from the keyboard when using service calls for
> keyboard input.
>
> NAK is also #1a in asynchronous RS232C protocol, and #11 is ACK.

RS-232 is a stream of bytes (not necessarily 8-bit ones); it doesn't
have any of these kind of symbols.

In ASCII, NAK is 0x15, and ACK is 0x06.

-hpa