End_Of_File does not work as expected...

End_Of_File does not work as expected...

[Mika Fischer]

Hi!

I have a problem with a program I had to write for university.

The program is supposed to read its standard input and write it onto its
standard output.

Why does the following code not work as expected?

procedure Echo is

c: Character;

begin
	while not End_Of_File loop
		Get(c);
		Put(c);
	end loop;
end Echo;

When I compile it and invoke it like in "cat file | ./echo" it throws the
exception END_ERROR which indicates that I tried to read from a file
beyond the end of file.
So why is End_Of_File false when it should be true?

Also if I invoke the program as "./echo" and type for example "ddd" and
press the enter key, the following appears on my screen:

--<snip>--
ddd
ddd
--<snip>--

When I press Enter once more its this:

--<snip>--
ddd
ddd


--<snip>--

I also don't understand why it behaves as it does.

I'm using GNAT 3.13p-2 on Debian GNU/Linux (woody) and Linux
2.4.0-test10.

As you have certainly noticed I don't really have a clue about Ada. So my
apollogies if this question ist just too stupid :-) (And sorry for my
English...)

Thanks for any answers!

Mika

Re: End_Of_File does not work as expected...

[Mika Fischer]

Hi, Jeff!

Thanks for your reply!

In article <3A1F4ABC.AB68A5C2@acm.org>, "Jeff Carter" <jrcarter@acm.org>
wrote:
>> Why does the following code not work as expected?
> I can't tell you, since I don't know how you expected it to work. It
> probably works as I expect it to work.

OK, sorry. I tell you how I'd expect it to work.
When Get(C) has read past the last Character of the file, End_Of_File
should return true and the look shoult be left.

>> procedure Echo is
>> 
>> c: Character;
>> 
>> begin
>>         while not End_Of_File loop
>>                 Get(c); Put(c);
>>         end loop;
>> end Echo;
> 
> This code should not compile, since Get and Put are not defined. If I
> assume that the source file contains
> 
> with Ada.Text_IO; use Ada.Text_IO;
> 
> followed by the given code, it would compile. All my following
> discussion is based on this assumption.

Oh, sorry again. Of course I'm using this line :-)

>> When I compile it and invoke it like in "cat file | ./echo" it throws
>> the exception END_ERROR which indicates that I tried to read from a
>> file beyond the end of file. So why is End_Of_File false when it should
>> be true?
> 
> Without knowing the exact contents of file, including any line and page
> terminators, I cannot answer.

It's the same with every file.

> However, if you carefully read the
> descriptions of End_Of_File and Get (Character) in ARM A.10, you will
> see that there are many situations in which End_Of_File is False, yet
> Get (Character) will attempt to read past the end of the file. This is
> probably what you are encountering. You can find the ARM at
> 
> http://www.adapower.com/rm95/index.html

All I can see is this:

| function End_Of_File return Boolean;
|
| (25)
|      Operates on a file of mode In_File. Returns True if a file
|      terminator is next, or if the combination of a line, a page, and a
|      file terminator is next; otherwise returns False. 

which doesn't explain why that does not work in my program.

>> Also if I invoke the program as "./echo" and type for example "ddd" and
>> press the enter key, the following appears on my screen:
>> 
>> --<snip>--
>> ddd
>> ddd
>> --<snip>--
>> 
>> When I press Enter once more its this:
>> 
>> --<snip>--
>> ddd ddd
>> 
>> --<snip>--
>> 
>> I also don't understand why it behaves as it does.
> 
> This is expected. The first line is echoed by your operating system, and
> the second by your program. The second <Enter> is echoed by the
> operating system but not by your program.

Yeah, well. But if I read one character at once I would expect it to look
like this:
--<snip>--
dddddd

--<snip>--

Or has this got something to do with buffered output? I'll look this up.

>> As you have certainly noticed I don't really have a clue about Ada. So
>> my apollogies if this question ist just too stupid :-) (And sorry for
>> my English...)
> 
> Text_IO has a number of features that seem counter-intuitive to many
> people when they first encounter it, especially if they have not read
> the descriptions of the operations, so your question is not *too*
> stupid. For example, many people assume that Get_Line always skips a
> line terminator.
> 
> For a university course, it is probably better to ask your instructor
> before posting here.

Well, I don't know how it is in the US, but here we hear the lectures,
get our excercises and are supposed to solve them at home. We then bring
the solutions back, they are corrected and handed back to us.

But sorry if I should have bothered you.

Mika.

Re: End_Of_File does not work as expected...

[Jeff Carter]

Mika Fischer wrote:
> All I can see is this:
> 
> | function End_Of_File return Boolean;
> |
> | (25)
> |      Operates on a file of mode In_File. Returns True if a file
> |      terminator is next, or if the combination of a line, a page, and a
> |      file terminator is next; otherwise returns False.
> 
> which doesn't explain why that does not work in my program.

Thus we can see that two line terminators at the end of the file will
result in End_Of_File being False. The description of Get (Character)
explains why it will raise End_Error in this situation.

[concerning input from the console:]
> Yeah, well. But if I read one character at once I would expect it to look
> like this:
> --<snip>--
> dddddd
> 
> --<snip>--
> 
> Or has this got something to do with buffered output? I'll look this up.

Get will probably wait for an entire line of input to be read and echoed
by the OS before reading a character. If you need immediate input, you
should probably be looking at Get_Immediate.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: End_Of_File does not work as expected...

[Jeff Carter]

Mika Fischer wrote:
> Why does the following code not work as expected?

I can't tell you, since I don't know how you expected it to work. It
probably works as I expect it to work.

> procedure Echo is
> 
> c: Character;
> 
> begin
>         while not End_Of_File loop
>                 Get(c);
>                 Put(c);
>         end loop;
> end Echo;

This code should not compile, since Get and Put are not defined. If I
assume that the source file contains

with Ada.Text_IO;
use Ada.Text_IO;

followed by the given code, it would compile. All my following
discussion is based on this assumption.

> When I compile it and invoke it like in "cat file | ./echo" it throws the
> exception END_ERROR which indicates that I tried to read from a file
> beyond the end of file.
> So why is End_Of_File false when it should be true?

Without knowing the exact contents of file, including any line and page
terminators, I cannot answer. However, if you carefully read the
descriptions of End_Of_File and Get (Character) in ARM A.10, you will
see that there are many situations in which End_Of_File is False, yet
Get (Character) will attempt to read past the end of the file. This is
probably what you are encountering. You can find the ARM at

http://www.adapower.com/rm95/index.html

> Also if I invoke the program as "./echo" and type for example "ddd" and
> press the enter key, the following appears on my screen:
> 
> --<snip>--
> ddd
> ddd
> --<snip>--
> 
> When I press Enter once more its this:
> 
> --<snip>--
> ddd
> ddd
> 
> --<snip>--
> 
> I also don't understand why it behaves as it does.

This is expected. The first line is echoed by your operating system, and
the second by your program. The second <Enter> is echoed by the
operating system but not by your program.

> As you have certainly noticed I don't really have a clue about Ada. So my
> apollogies if this question ist just too stupid :-) (And sorry for my
> English...)

Text_IO has a number of features that seem counter-intuitive to many
people when they first encounter it, especially if they have not read
the descriptions of the operations, so your question is not *too*
stupid. For example, many people assume that Get_Line always skips a
line terminator.

For a university course, it is probably better to ask your instructor
before posting here.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail

Re: End_Of_File does not work as expected...

[Mats Weber]

I find Jeff Carter's reply overly pedantic and paternalistic, given the
reasonable question being asked. And students are welcome to this newsgroup.

Now to the point: If you are used to C and UNIX text files, then Text_IO
is definitely something different. On some systems, (e.g. VMS) a line
terminator is not encoded as a character as it is on UNIX, but as the
end of a record. Text_IO was designed to accomodate such systems as well.

If you want to write the equivalent of UNIX's echo using Text_IO, you
must follow the complete file structure including lines and pages:

while not End_Of_File loop
   while not End_Of_Page loop
      while not End_Of_Line loop
         Get(c);
         Put(c);
      end loop;
      Skip_Line;   -- can be omitted.
      New_Line;
   end loop;
   Skip_Page;   -- can be omitted.
   New_Page;
end loop;

You can omit the page stuff if you don't need it, but you will have to
use End_Of_Line and New_Line because otherwise your output file is going
to be a single line.

Note that if you use End_Of_Page/New_Page, then you will have a page
terminator at the end of your output file even though the input file has
none. My advice: ignore pages in Text_IO.

Re: End_Of_File does not work as expected...

[Jeff Carter]

Mats Weber wrote:
> 
> I find Jeff Carter's reply overly pedantic and paternalistic, given the
> reasonable question being asked. And students are welcome to this newsgroup.

I was trying to allow the questioner to figure the answer out himself.
In my experience, information is more likely to be retained when figured
out than when given.

> If you want to write the equivalent of UNIX's echo using Text_IO, you
> must follow the complete file structure including lines and pages:

The UNIX echo command echoes its command line arguments, IIRC. The
questioner does not appear to be writing an equivalent program. I am not
sure what he is trying to accomplish.

> 
> while not End_Of_File loop
>    while not End_Of_Page loop
>       while not End_Of_Line loop
>          Get(c);
>          Put(c);
>       end loop;
>       Skip_Line;   -- can be omitted.
>       New_Line;
>    end loop;
>    Skip_Page;   -- can be omitted.
>    New_Page;
> end loop;

If the code does not skip line terminators, then it will raise
End_Error. If the file does not contain page terminators, this code will
raise End_Error. When reading from the keyboard, End_Of_File is usually
always False.

My advice would be to use a Get_Line function and Put_Line, and have a
handler for End_Error.

-- 
Jeff Carter
"Nobody expects the Spanish Inquisition!"
Monty Python's Flying Circus

Re: End_Of_File does not work as expected...

[Mats Weber]

Jeff Carter wrote:

> The UNIX echo command echoes its command line arguments, IIRC. The
> questioner does not appear to be writing an equivalent program. I am not
> sure what he is trying to accomplish.

Sorry, I meant cat, not echo.

> > while not End_Of_File loop
> >    while not End_Of_Page loop
> >       while not End_Of_Line loop
> >          Get(c);
> >          Put(c);
> >       end loop;
> >       Skip_Line;   -- can be omitted.
> >       New_Line;
> >    end loop;
> >    Skip_Page;   -- can be omitted.
> >    New_Page;
> > end loop;
> 
> If the code does not skip line terminators, then it will raise
> End_Error. If the file does not contain page terminators, this code will
> raise End_Error. When reading from the keyboard, End_Of_File is usually
> always False.

No, it won't raise End_Error in either case, because Get(Character)
starts by skipping any number of line and page terminators and returns
the first character after them. It will only raise End_Error if a file
terminator is after the sequence of line and page terminators.

> My advice would be to use a Get_Line function and Put_Line, and have a
> handler for End_Error.

Agreed.