Out_File , excess line

Out_File , excess line

[comicfanzine]

Hi ,

I noticed that when i open a file ( empty or full ) in Out_file mode , an extra line is created .

Normally , on my system , when you open maually a file , there is one empty line by default .

But , when i open this same file in Ada with Out_file Mode , and then manually , a second line appear .

How fix this ?

Re: Out_File , excess line

[AdaMagica]

See RM A.10.5.

Close of an out file calls New_Page, which in turn writes a line terminator.

For more info, read the RM.

Re: Out_File , excess line

[comicfanzine]

I haven't even close the file .

I just opened it .
Quote ARM :

" For the procedures Create and Open: After a file with mode Out_File or Append_File is opened, the page length and line length are unbounded (both have the conventional value zero). After a file (of any mode) is opened, the current column, current line, and current page numbers are set to one. "


So , if i want that when i open the file manually , the current line be set to 1 ( which is actually 2 ) , how to proceed ?

Re: Out_File , excess line

[comicfanzine]

I haven't close the file .

The RM is right concerning the position :

" For the procedures Create and Open: After a file with mode Out_File or Append_File is opened, the page length and line length are unbounded (both have the conventional value zero). After a file (of any mode) is opened, the current column, current line, and current page numbers are set to one. "

But after this , why is there a second line , when i open the file manually ?

See yourself :  http://pix.toile-libre.org/upload/original/1453298185.png

I don't think it's a OS problem , because when i create a file ( In , Out or In-Out mode) without Ada , there is never 2 lines when i open it after ( manually ) , but only 1 .


Thanks .

Re: Out_File , excess line

[Dmitry A. Kazakov]

On 2016-01-20 15:03, comicfanzine@gmail.com wrote:
>
> I don't think it's a OS problem , because when i create a file ( In
> ,  Out or In-Out mode) without Ada , there is never 2 lines when i open it
> after ( manually ) , but only 1 .

It is an OS problem. Popular OSes do not enforce text file conventions 
they have. Ada's Text_IO implementations try to follow these 
conventions, alas they are disregarded by most, if not all, other tools.

Ergo, do not use Ada.Text_IO, do not use Get_Line if you expect your 
program working with *broken* text files and going to produce *broken* 
text files as well.

There is Streams.Stream_IO for this kind of job. Do manual recognition 
of line ends in a way appropriate to your needs, e.g. compatible with 
other tools.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Out_File , excess line

[AdaMagica]

There is not really a second line.
Let's say, <EoF> is the end of file indicator, <LF> the line feed, and let's forget about end of page indicators.

When you open an empty file with your editor (you call it "open manually"), it sees <EoF>, and thus shows
1|

When you create a file without contents with Ada.Text_IO and close it again, your editor sees <LF><EoF>, and thus shows
1|
2

The reason is the <LF> written by Ada according to RM.

Re: Out_File , excess line

[comicfanzine]

AdaMagica ,

I haven't created a file with Ada , but manually in a file manager .

Then , i just opened it in Out_file with Ada , and then manually .

I haven't closed the file neither .

So , i understand your explanation , but it doesn't match .

Re: Out_File , excess line

[Jacob Sparre Andersen]

comicfanzine@gmail.com writes:

> Then , i just opened it in Out_file with Ada , and then manually .
>
> I haven't closed the file neither .

When an Ada program terminates, all open files are closed.

/Jacob
-- 
recursive, adj.; see recursive

Re: Out_File , excess line

[AdaMagica]

Am Donnerstag, 21. Januar 2016 11:27:17 UTC+1 schrieb Jacob Sparre Andersen:
> comicfanzine@gmail.com writes:
> 
> > Then , i just opened it in Out_file with Ada , and then manually .
> >
> > I haven't closed the file neither .
> 
> When an Ada program terminates, all open files are closed.
> 
> /Jacob
> -- 
> recursive, adj.; see recursive

See RM A.7(6) The language does not define what happens to external files after the completion of the main program and all the library tasks (in particular, if corresponding files have not been closed). The effect of input-output for access types is unspecified.

I guess the OP is using GNAT, and this friendly compiler seems to properly close the files upon leaving the scope of a file object.

Re: Out_File , excess line

[G.B.]

On 21.01.16 11:56, AdaMagica wrote:
> Am Donnerstag, 21. Januar 2016 11:27:17 UTC+1 schrieb Jacob Sparre Andersen:
>> comicfanzine@gmail.com writes:
>>
>>> Then , i just opened it in Out_file with Ada , and then manually .
>>>
>>> I haven't closed the file neither .
>>
>> When an Ada program terminates, all open files are closed.
>>
>> /Jacob
>> --
>> recursive, adj.; see recursive
>
> See RM A.7(6) The language does not define what happens to external files after the completion of the main program and all the library tasks (in particular, if corresponding files have not been closed). The effect of input-output for access types is unspecified.
>
> I guess the OP is using GNAT, and this friendly compiler seems to properly close the files upon leaving the scope of a file object.
>

On Windows, that did not seem to be the case.
Always closing files is helpfully reflecting
the intent of the programmer.

Re: Out_File , excess line

[Dmitry A. Kazakov]

On 2016-01-21 12:57, G.B. wrote:
> On 21.01.16 11:56, AdaMagica wrote:
>>
>> I guess the OP is using GNAT, and this friendly compiler seems to
>> properly close the files upon leaving the scope of a file object.
>
> On Windows, that did not seem to be the case.

Even if the process does not close the file Windows does this upon 
process termination. However the file end is not set if not closed 
"normally", e.g. per Close call.

> Always closing files is helpfully reflecting
> the intent of the programmer.

Yes.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Out_File , excess line

[AdaMagica]

Am Donnerstag, 21. Januar 2016 15:42:58 UTC+1 schrieb Dmitry A. Kazakov:
> On 2016-01-21 12:57, G.B. wrote:
> > On 21.01.16 11:56, AdaMagica wrote:
> >>
> >> I guess the OP is using GNAT, and this friendly compiler seems to
> >> properly close the files upon leaving the scope of a file object.
> >
> > On Windows, that did not seem to be the case.
> 
> Even if the process does not close the file Windows does this upon 
> process termination. However the file end is not set if not closed 
> "normally", e.g. per Close call.

Hm, I tried leaving the program with and without closing the file. The result (on Windows) was both the same, a CR and LF written.
While the file is still open, a dir command shows the file with 0 bytes, after leaving the program, with two bytes (13 10).
Since Windows surely does not add the line terminator, it must be friendly Gnat who's closing the file implicitly.

Re: Out_File , excess line

[Dennis Lee Bieber]

On Thu, 21 Jan 2016 08:23:38 -0800 (PST), AdaMagica
<christ-usch.grein@t-online.de> declaimed the following:

>Am Donnerstag, 21. Januar 2016 15:42:58 UTC+1 schrieb Dmitry A. Kazakov:
>> On 2016-01-21 12:57, G.B. wrote:
>> > On 21.01.16 11:56, AdaMagica wrote:
>> >>
>> >> I guess the OP is using GNAT, and this friendly compiler seems to
>> >> properly close the files upon leaving the scope of a file object.
>> >
>> > On Windows, that did not seem to be the case.
>> 
>> Even if the process does not close the file Windows does this upon 
>> process termination. However the file end is not set if not closed 
>> "normally", e.g. per Close call.
>
>Hm, I tried leaving the program with and without closing the file. The result (on Windows) was both the same, a CR and LF written.
>While the file is still open, a dir command shows the file with 0 bytes, after leaving the program, with two bytes (13 10).
>Since Windows surely does not add the line terminator, it must be friendly Gnat who's closing the file implicitly.

	Or could it be that the directory entry is not updated until the file
is closed/flushed -- which could be by the OS... after all, if the OS is
buffering I/O, a two-byte Ada line marker might not be written to disk
until an explicit flush operation.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Out_File , excess line

[Dennis Lee Bieber]

On Wed, 20 Jan 2016 20:50:23 -0800 (PST), comicfanzine@gmail.com declaimed
the following:

>AdaMagica ,
>
>I haven't created a file with Ada , but manually in a file manager .
>
>Then , i just opened it in Out_file with Ada , and then manually .
>
	On most OS, opening a file in an output only mode will result in
creating a new file, or at the least, wiping out whatever contents the file
used to have. So -- your "manual" creation outside of the program isn't
really a factor. On some, opening output only when the file already exists
may produce an error condition.

	And looking at the file in some text editor may be misleading. As has
been described, the Ada text file is somewhat record-oriented, with a
record ending (line terminator). Note the word: terminator -- not line
separator. (The standard doesn't define what the terminator is -- if the OS
supports records with a record-length field at the beginning, that is valid
for an implementation to use). Most likely, the system is using a line-feed
(or carriage return/line-feed pair in Windows) as the terminator.

	Most C/Unix influenced systems will treat a line-feed as a separator,
and a text editor will move the cursor to the beginning of the next line.
Only by dumping the file in hex can one see what is really contained.

	If I interpret the standard, it is possible that just opening and
closing a text file in Ada results in a file containing:

<lf><ff><eof>

Though I think most systems let <eof> get handled by the file system
directory information on the length of the file. Haven't really seen a
new-page code either.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Out_File , excess line

[comicfanzine]

It's definetely a Out_file mode issue .

When i use the In_file or Append_file mode , there is no excess line when i open the file manually after program's end .

Re: Out_File , excess line

[comicfanzine]

Do you know how to solve this ?

Re: Out_File , excess line

[Brian Drummond]

On Thu, 21 Jan 2016 09:30:47 -0800, comicfanzine wrote:

> It's definetely a Out_file mode issue .
> 
> When i use the In_file or Append_file mode , there is no excess line
> when i open the file manually after program's end .

Perhaps it's not just an Out_File issue but specifically an Ada.Text_IO 
Out_File issue.

If you Create/Close a file using one of the other IO packages, Direct_IO 
or Sequential_IO for example, what happens? I see no reason why either of 
these would add text to the end of a file.

If that gives you the desired behaviour, perhaps you can work around by 
re-opening for Append with the Ada.Text_IO package?


-- Brian

Re: Out_File , excess line

[comicfanzine]

I'm working with a text file .

Now , i use the package Ada.Text_IO.Unbounded_IO for text in Unbounded_Strings .

If i use the package Ada.Streams.Stream_IO , instead of Ada.Text_IO , for text handling , there is some changes to do :

Is there a Unbounded_String package for Stream_IO  ?

Or a another simplier way ?
-----------------------
WITH Ada.Text_IO.Unbounded_IO ; USE Ada.Text_IO.Unbounded_IO ;
WITH Ada.Strings.Unbounded ;    USE Ada.Strings.Unbounded ;
WITH Ada.Text_IO  ;             USE Ada.Text_IO  ;

Procedure count_nb_lines is

  this_file , test_file : File_type ;

  count : integer := 0 ;

Begin

    Open
     (File => this_file ,
      Mode => In_file ,
      Name => "count_nb_lines.adb");

   loop exit when End_Of_File( this_file );
     skip_line( this_file );
     count := count + 1 ;
   end loop ;

   Open
     (File => test_file ,
      Mode => Out_File ,
      Name => "test.adb");

   declare

   Type Tableau_lines_file is array( 1 .. count) of Unbounded_String;

   case_array : Tableau_lines_file ;

   begin

   Reset( this_file );

    Loop exit when End_Of_File( this_file );
        for i in 1..case_array'Length loop
         case_array(i) := get_line(this_file);
       end loop ;
   End loop;

    for j in 1..case_array'Length loop
      put_line( test_file , case_array(j) );
   end loop;

    end;
End count_nb_lines ;

Re: Out_File , excess line

[comicfanzine]

I figured out how to use the package ?

The code compile , and is launchable too .

But , when we try to open the file manually , the text editor print :

" This is not a text file . Type unknown . "

Same information for the file manager( Thunar ) .

??

---------------
WITH Ada.Text_IO.Unbounded_IO ; USE Ada.Text_IO.Unbounded_IO ;
WITH Ada.Strings.Unbounded ;    USE Ada.Strings.Unbounded ;
WITH Ada.Text_IO  ;             USE Ada.Text_IO  ;
WITH Ada.Streams.Stream_IO ;

Procedure count_nb_lines is

  this_file : File_type ;

  count_line : integer := 0 ;

Begin

    Open
     (File => this_file ,
      Mode => In_file ,
      Name => "count_nb_lines.adb");

   loop exit when End_Of_File( this_file );
     skip_line( this_file );
     count_line := count_line + 1 ;
   end loop ;


   declare

   Type Tableau_file is array( 1 .. count_line) of Unbounded_String ;

   case_array : Tableau_file ;


   PACKAGE ST_IO RENAMES Ada.Streams.Stream_IO ;

   test_file : ST_IO.File_type ;

   Input_Stream : ST_IO.Stream_Access ;

   begin

   Reset( this_file );

    Loop exit when End_Of_File( this_file );
        for i in 1..case_array'Length loop
         case_array(i) := get_line(this_file);
       end loop ;
   End loop;

   ST_IO.Create( File => test_file ,
               Mode => ST_IO.Out_File ,
               Name => "test" );

    Input_Stream := ST_IO.Stream( test_file );

    for j in 1..case_array'Length loop
      Unbounded_String'Write( Input_Stream , case_array(j) );
   end loop;

    end;
End count_nb_lines ;

Re: Out_File , excess line

[Simon Wright]

comicfanzine@gmail.com writes:

> But , when we try to open the file manually , the text editor print :
>
> " This is not a text file . Type unknown . "
>    PACKAGE ST_IO RENAMES Ada.Streams.Stream_IO ;
>
>    test_file : ST_IO.File_type ;
>
>    Input_Stream : ST_IO.Stream_Access ;
[...]
>    ST_IO.Create( File => test_file ,
>                Mode => ST_IO.Out_File ,
>                Name => "test" );
>
>     Input_Stream := ST_IO.Stream( test_file );
>
>     for j in 1..case_array'Length loop
>       Unbounded_String'Write( Input_Stream , case_array(j) );
>    end loop;

'Input_Stream' is a very odd name for a stream you're going to *output*
to.

What's happening is that (reasonably, though not as far as I can see
discussed by the standard) GNAT treats Unbounded_String'Write as if an
unbounded string is a discriminated type whose discriminants have
defaults; that is, the discriminants (the array bounds) are output to
the stream first, followed by the characters of the string. (This is
what happens for String'Output; String'Write doesn't include the bounds;
is the Unbounded_String'Write behaviour a bug or a feature?).

So, if you Unbounded_String'Write "foo", you will get
- 4 bytes containing binary 1, the first index of the content
- 4 bytes containing binary 3, the last index of the content
- 3 bytes of content, 'f' 'o' 'o'.

Which looks nothing like a text file.

You could try

  String'Write (Input_Stream, To_String (case_array (j)) & ASCII.LF);

(should be OK on Unix systems, don't know about Windows. A text
editor should be OK with LF-terminated lines, Notepad not so much.)

[1] http://www.ada-auth.org/standards/12rm/html/RM-13-13-2.html#p9.1

Re: Out_File , excess line

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> So, if you Unbounded_String'Write "foo", you will get
> - 4 bytes containing binary 1, the first index of the content
> - 4 bytes containing binary 3, the last index of the content
> - 3 bytes of content, 'f' 'o' 'o'.
>
> Which looks nothing like a text file.

The tool of choice here (on Unix systems) is 'od'; 'od -c test' shows
and interprets the file contents byte-by-byte.

Re: Out_File , excess line

[Jeffrey R. Carter]

On 01/27/2016 12:32 PM, Simon Wright wrote:
> 
> The tool of choice here (on Unix systems) is 'od'; 'od -c test' shows
> and interprets the file contents byte-by-byte.

hd test | less

is also useful. Note that piping into less is also a good idea with od.

-- 
Jeff Carter
"I feel as though somebody stepped on my tongue
with muddy feet."
Never Give a Sucker an Even Break
112

Re: Out_File , excess line

[Dmitry A. Kazakov]

On 2016-01-27 10:26, Simon Wright wrote:
> comicfanzine@gmail.com writes:
>
>> But , when we try to open the file manually , the text editor print :
>>
>> " This is not a text file . Type unknown ."
>>     PACKAGE ST_IO RENAMES Ada.Streams.Stream_IO ;
>>
>>     test_file : ST_IO.File_type ;
>>
>>     Input_Stream : ST_IO.Stream_Access ;
> [...]
>>     ST_IO.Create( File => test_file ,
>>                 Mode => ST_IO.Out_File ,
>>                 Name => "test" );
>>
>>      Input_Stream := ST_IO.Stream( test_file );
>>
>>      for j in 1..case_array'Length loop
>>        Unbounded_String'Write( Input_Stream , case_array(j) );
>>     end loop;
>
> 'Input_Stream' is a very odd name for a stream you're going to *output*
> to.
>
> What's happening is that (reasonably, though not as far as I can see
> discussed by the standard) GNAT treats Unbounded_String'Write as if an
> unbounded string is a discriminated type whose discriminants have
> defaults; that is, the discriminants (the array bounds) are output to
> the stream first, followed by the characters of the string. (This is
> what happens for String'Output; String'Write doesn't include the bounds;
> is the Unbounded_String'Write behaviour a bug or a feature?).
>
> So, if you Unbounded_String'Write "foo", you will get
> - 4 bytes containing binary 1, the first index of the content
> - 4 bytes containing binary 3, the last index of the content
> - 3 bytes of content, 'f' 'o' 'o'.
>
> Which looks nothing like a text file.
>
> You could try
>
>    String'Write (Input_Stream, To_String (case_array (j)) & ASCII.LF);

This one of many reasons why no Unbounded_String should ever be used for 
any text processing. That includes text buffers of course. Using 
standard containers of Unbounded_String is probably least efficient 
possible way to implement a text buffer.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Out_File , excess line

[comicfanzine]

Do you know where the problem is ?

Re: Out_File , excess line

[comicfanzine]

Stream_IO can be used for text files : https://en.wikibooks.org/wiki/Ada_Programming/Input_Output#Overview

So , why it doesn't work ??

Re: Out_File , excess line

[MM]

On Monday, 25 January 2016 21:54:28 UTC, comicf...@gmail.com  wrote:
> Stream_IO can be used for text files : https://en.wikibooks.org/wiki/Ada_Programming/Input_Output#Overview
> 
> So , why it doesn't work ??

Maybe the files contain the full Unlimited_string data structure instead of plain
text? Look at a hex dump of the file to see.

M

Re: Out_File , excess line

[comicfanzine]

> Maybe the files contain the full Unlimited_string data structure instead of plain
> text? Look at a hex dump of the file to see.
> 
> M

Edit:Thanks for your answer .

Look at what and how ? I don't understand that part .

Re: Out_File , excess line

[comicfanzine]

Maybe its a Unbounded_String + Stream issue .

Except the code i posted , I have no idea about using both together .

Re: Out_File , excess line

[comicfanzine]

Nobody ?

Re: Out_File , excess line

[AdaMagica]

You could try to open the file with Sequential_IO for Byte and look at the contents.

Re: Out_File , excess line

[comicfanzine]

It worked with Simon Wright 's method .


But , there is still that extra line in "test" .

Where does it come from , this time ?


It is not a test editor problem , same result with Sublime text , eclipse , geany ...

Re: Out_File , excess line

[comicfanzine]

Does it do the same on your system ?

Still looking for explanation ...

Re: Out_File , excess line

[Simon Wright]

comicfanzine@gmail.com writes:

> I noticed that when i open a file ( empty or full ) in Out_file mode ,
> an extra line is created .
>
> Normally , on my system , when you open maually a file , there is one
> empty line by default .
>
> But , when i open this same file in Ada with Out_file Mode , and then
> manually , a second line appear .

ARM A.10.2(3)[1] says

   For the procedure Close: If the file has the current mode Out_File or
   Append_File, has the effect of calling New_Page, unless the current
   page is already terminated; then outputs a file terminator.

ARM A.10.5(15)[2] says

   procedure New_Page(File : in File_Type);
   procedure New_Page;

   Operates on a file of mode Out_File or Append_File. Outputs a line
   terminator if the current line is not terminated, or if the current
   page is empty (that is, if the current column and line numbers are
   both equal to one). Then outputs a page terminator, which terminates
   the current page. Adds one to the current page number and sets the
   current column and line numbers to one.

So, if you open a file in Out_File mode, the current (empty) line is not
terminated, and when you close the file and New_Page is called (or
possibly simulated), a line terminator is added.

You would expect a page terminator (FF) to be added as well; indeed, if
you call New_Page explicitly and then close the file GNAT does. I
suspect that the reason GNAT doesn't do this in the case of just closing
a file with an unterminated line is that that would be very surprising
indeed!

See Terminate_Line in a-textio.adb.

[1] http://www.ada-auth.org/standards/12rm/html/RM-A-10-2.html#p3
[2] http://www.ada-auth.org/standards/12rm/html/RM-A-10-5.html#p15

Re: Out_File , excess line

[AdaMagica]

Am Samstag, 30. Januar 2016 10:44:26 UTC+1 schrieb Simon Wright:
> comicfanzine@gmail.com writes:

That's about what what I've pointed him to in the very first answer to his post.
Also my next posts tried to explain him the case.

There really is no second line, there only is one empty line ending in <end of line>.
 
> ARM A.10.2(3)[1] says
> 
>    For the procedure Close: If the file has the current mode Out_File or
>    Append_File, has the effect of calling New_Page, unless the current
>    page is already terminated; then outputs a file terminator.
> 
> ARM A.10.5(15)[2] says
> 
>    procedure New_Page(File : in File_Type);
>    procedure New_Page;
> 
>    Operates on a file of mode Out_File or Append_File. Outputs a line
>    terminator if the current line is not terminated, or if the current
>    page is empty (that is, if the current column and line numbers are
>    both equal to one). Then outputs a page terminator, which terminates
>    the current page. Adds one to the current page number and sets the
>    current column and line numbers to one.
> 
> So, if you open a file in Out_File mode, the current (empty) line is not
> terminated, and when you close the file and New_Page is called (or
> possibly simulated), a line terminator is added.
> 
> You would expect a page terminator (FF) to be added as well; indeed, if
> you call New_Page explicitly and then close the file GNAT does. I
> suspect that the reason GNAT doesn't do this in the case of just closing
> a file with an unterminated line is that that would be very surprising
> indeed!
> 
> See Terminate_Line in a-textio.adb.
> 
> [1] http://www.ada-auth.org/standards/12rm/html/RM-A-10-2.html#p3
> [2] http://www.ada-auth.org/standards/12rm/html/RM-A-10-5.html#p15

Re: Out_File , excess line

[Simon Wright]

AdaMagica <christ-usch.grein@t-online.de> writes:

> That's about what what I've pointed him to in the very first answer to
> his post.  Also my next posts tried to explain him the case.

Yes, so you did.

Normally I don't read his posts (Gnus score lowered), every so often I
fall for it.

Re: Out_File , excess line

[comicfanzine]

Procedure Close [...] outputs a file terminator .

Terminate_Line call new_line . 

So, for removing the excess line , i must eliminate this Terminate_Line ?

If its correct , i understand better .

How to proceed in this case ?

Is there another way ?

Re: Out_File , excess line

[Simon Wright]

comicfanzine@gmail.com writes:

> Procedure Close [...] outputs a file terminator .
>
> Terminate_Line call new_line . 
>
> So, for removing the excess line , i must eliminate this Terminate_Line ?
>
> If its correct , i understand better .
>
> How to proceed in this case ?
>
> Is there another way ?

The standard solution to copying a file would be

   with Ada.Text_IO; use Ada.Text_IO;
   procedure Fanzine is
      Input_File : File_Type;
      Output_File : File_Type;
      Lines : Natural := 0;
   begin
      Open (Input_File, Name => "fanzine.adb", Mode => In_File);
      begin
         Open (Output_File, Name => "fanzine.adb.copy", Mode => Out_File);
      exception
         when Name_Error =>
            Create (Output_File, Name => "fanzine.adb.copy");
      end;
      begin
         loop
            declare
               L : constant String := Get_Line (Input_File);
               --  raises End_Error if no more lines
            begin
               Lines := Lines + 1;
               Put_Line (Output_File, L);
            end;
         end loop;
      exception
         when End_Error => null;  -- exits the loop
      end;
      Close (Input_File);
      Close (Output_File);
      Put_Line ("there were" & Integer'Image (Lines) & " lines");
   end Fanzine;

which will only introduce an extra NL if you have an input file whose
last line isn't terminated with NL.

It's arguable that such a file isn't a "proper" text file
anyway. Neither Emacs nor vi will produce such a file unless it's
actually empty (Mac Textedit will, though).

What is your reason for worrying about this?

Re: Out_File , excess line

[Dmitry A. Kazakov]

On 2016-01-31 12:25, Simon Wright wrote:

> The standard solution to copying a file would be
>
>     with Ada.Text_IO; use Ada.Text_IO;

No, that does not copy a file. That 1) interprets a file context as a 
text file specific to the given operating system and then 2) writes the 
interpretation into another file. So it is a file conversion.

One solution to copy a file is using Copy_File from Ada.Directories.

Another is using Ada.Streams.Stream_IO. Both are not ideal but will work 
in most cases.

E.g. your example with Ada.Streams.Stream_IO:

  with Ada.Exceptions;        use Ada.Exceptions;
  with Ada.Streams;           use Ada.Streams;
  with Ada.Streams.Stream_IO; use Ada.Streams.Stream_IO;

  with Ada.Text_IO;

  procedure Fanzine is
     Buffer_Size : constant := 1024; -- Or more
     Input_File  : File_Type;
     Output_File : File_Type;
     Buffer      : Stream_Element_Array (1..Buffer_Size);
     Last        : Stream_Element_Offset;
     Count       : Stream_Element_Count := 0;
  begin
     Open (Input_File, In_File, "fanzine.adb");
     begin
        Create (Output_File, Out_File, "fanzine.adb.copy");
        loop
           Read (Input_File, Buffer, Last);
           exit when Last < Buffer'First;
           Count := Count + Last;
           Write (Output_File, Buffer (Buffer'First..Last));
       end loop;
    exception
       when End_Error =>
          null; -- Never here
    end;
    Close (Output_File);
    Close (Input_File);
    Ada.Text_IO.Put_Line
    (  "Written" & Stream_Element_Count'Image (Count) & " elements"
    );
exception
    when Error : others =>
       Ada.Text_IO.Put_Line ("Error " & Exception_Information (Error));
end Fanzine;

It is quite simple, if necessary, to detect line ends in a manner 
compatible with both Windows and Linux systems, given fixed encoding.

(Doing that independently of the encoding would probably be impossible, 
but who cares?)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Out_File , excess line

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> No, that does not copy a file. That 1) interprets a file context as a
> text file specific to the given operating system and then 2) writes
> the interpretation into another file. So it is a file conversion.

Well, you're right, but it's not that far off for most purposes, and not
far from what OP is asking about (I think ..)

Re: Out_File , excess line

[AdaMagica]

Am Sonntag, 31. Januar 2016 09:56:38 UTC+1 schrieb comicf...@gmail.com:
> Procedure Close [...] outputs a file terminator .
> 
> Terminate_Line call new_line . 
> 
> So, for removing the excess line , i must eliminate this Terminate_Line ?
> 
> If its correct , i understand better .
> 
> How to proceed in this case ?
> 
> Is there another way ?

There is no term Terminate_Line in the RM.

Any file properly written with Ada.Text_IO will be in the canonical form, i.e. each and every line will be ended with a line terminator, also empty lines.
The line terminator itself is system dependent and not defined in Ada. This is why there are subprograms dealing with lines (they abstract away the indicator) like Get_Line, New_Line.

A line thus terminated will look in some editors as though there was another line following.

Why do you care? How does this disturb your work.

Re: Out_File , excess line

[comicfanzine]

With Dimitry's method , there is no more the excess line .

However , there is neither no control for handling text by Unbounded_Strings .

Maybe it can be solved by a type conversion betwen  :
Stream_Element <--> Unbounded_String .

It can't be done with Explicit type conversion .


How to do this ?
Is there another method ?

Re: Out_File , excess line

[Dmitry A. Kazakov]

On 01/02/2016 07:22, comicfanzine@gmail.com wrote:
> With Dimitry's method , there is no more the excess line .
>
> However , there is neither no control for handling text by Unbounded_Strings .
>
> Maybe it can be solved by a type conversion betwen  :
> Stream_Element <--> Unbounded_String .
>
> It can't be done with Explicit type conversion .
>
>
> How to do this ?

You cannot do that without knowing the encoding, obviously.

Considering:

1. ASCII, Latin-1, UTF-8 packed into an array of Character
2. A byte = 8-bit machine (except for some DSP it is almost any machine)

Then a Stream_Element can be converted to Character by this way:

    Character'Val (Buffer (Index))

Or, let's take

1. UCS-2, UTF-16 packed into an array of Wide_Character
2. byte = 8-bit, again
3. Big-endian code points

    Wide_Character'Val
    (  Integer (Buffer (Index)) * 256
    +  Integer (Buffer (Index + 1))
    )

For text processing you must consider how do you keep Unicode texts. 
There is basically two reasonable approaches:

1. String with the text stored in UTF-8
2. Wide_Wide_String or an array of code points declared as an integer type.

The second method is rarely used because it wastes memory and 
performance while the advantage of having directly indexed characters is 
negligible for text processing. The first method assumes re-coding if 
the source is not UTF-8.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Out_File , excess line

[comicfanzine]

Encoding is UTF-8 .

So , at the end , it would be :

Stream_Element --> To Characters --> To String or Unbounded_String  .

Is there a shorter method than this kind of type conversion , for not having the excess line and copy-paste all the lines ?

Re: Out_File , excess line

[Dmitry A. Kazakov]

On 2016-02-09 16:07, comicfanzine@gmail.com wrote:
> Encoding is UTF-8 .
>
> So , at the end , it would be :
>
> Stream_Element --> To Characters --> To String or Unbounded_String  .

No. Technically Unicode characters are not String characters. It would be

Stream_Element -> Octet (Character'Val (Octet)) -> String UTF-8 encoded

Once Unicode character encoded as a chain of Ada's Character.

> Is there a shorter method than this kind of type conversion , for
> not  having the excess line and copy-paste all the lines ?

It is as short as it can be. You can deploy some tricks assuming 
Storage_Element and arrays representation same as for String, but it 
would not be a great idea.

Why do you need it shorter? If you are going to use Unbounded_String for 
text processing that will be much a bigger performance and memory hit 
than just one string copy.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de