Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #68612 > unrolled thread

fprintf with /r/n outputs only one line

Back to article view | Back to comp.lang.c

Contents

  fprintf with /r/n outputs only one line Dale <dale@dalekelly.org> - 2015-08-28 23:08 -0400
    Re: fprintf with /r/n outputs only one line Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-28 21:25 -0600
      Re: fprintf with /r/n outputs only one line Dale <dale@dalekelly.org> - 2015-08-28 23:56 -0400
    Re: fprintf with /r/n outputs only one line James Kuyper <jameskuyper@verizon.net> - 2015-08-28 23:34 -0400
      Re: fprintf with /r/n outputs only one line Dale <dale@dalekelly.org> - 2015-08-29 00:02 -0400
        Re: fprintf with /r/n outputs only one line Johann Klammer <klammerj@NOSPAM.a1.net> - 2015-08-29 06:51 +0200
          Re: fprintf with /r/n outputs only one line Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-08-29 07:30 +0000
          Re: fprintf with /r/n outputs only one line Keith Thompson <kst-u@mib.org> - 2015-08-29 01:23 -0700
        Re: fprintf with /r/n outputs only one line James Kuyper <jameskuyper@verizon.net> - 2015-08-29 11:22 -0400
          Re: fprintf with /r/n outputs only one line glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-29 16:59 +0000
        Re: fprintf with /r/n outputs only one line Geoff <geoff@invalid.invalid> - 2015-08-30 11:40 -0700
          Re: fprintf with /r/n outputs only one line Keith Thompson <kst-u@mib.org> - 2015-08-30 15:17 -0700
            Re: fprintf with /r/n outputs only one line Geoff <geoff@invalid.invalid> - 2015-08-30 16:21 -0700
              Re: fprintf with /r/n outputs only one line James Kuyper <jameskuyper@verizon.net> - 2015-08-30 19:45 -0400
    Re: fprintf with /r/n outputs only one line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-29 14:51 +0100
      Re: fprintf with /r/n outputs only one line Ayan <selfjam@gmail.com> - 2015-08-29 10:24 -0400
        Re: fprintf with /r/n outputs only one line James Kuyper <jameskuyper@verizon.net> - 2015-08-29 11:27 -0400
        Re: fprintf with /r/n outputs only one line Ayan <selfjam@gmail.com> - 2015-08-29 14:31 -0400
        Re: fprintf with /r/n outputs only one line Keith Thompson <kst-u@mib.org> - 2015-08-29 13:31 -0700
      Re: fprintf with /r/n outputs only one line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-29 16:03 +0100
        Re: fprintf with /r/n outputs only one line Ike Naar <ike@iceland.freeshell.org> - 2015-08-29 16:50 +0000
          Re: fprintf with /r/n outputs only one line Ike Naar <ike@iceland.freeshell.org> - 2015-08-29 17:05 +0000
            Re: fprintf with /r/n outputs only one line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-29 19:39 +0100
              Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-29 14:05 -0700
                Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-29 22:46 +0100
                  Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-29 15:59 -0700
                    Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-30 00:31 +0100
                      Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-30 10:25 +0100
                      Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-30 13:22 +0100
                        Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 03:18 -0700
                          Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-31 11:58 +0100
                            Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-31 13:38 +0100
                              Re: fprintf with /r/n outputs only one line glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-04 04:18 +0000
                                Re: fprintf with /r/n outputs only one line "Charles Richmond" <numerist@aquaporin4.com> - 2015-09-04 05:09 -0500
                                  Re: fprintf with /r/n outputs only one line Robert Wessel <robertwessel2@yahoo.com> - 2015-09-04 05:19 -0500
                                  Re: fprintf with /r/n outputs only one line raltbos@xs4all.nl (Richard Bos) - 2015-09-04 16:33 +0000
                Re: fprintf with /r/n outputs only one line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-30 02:17 +0100
                  Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-29 23:43 -0700
                    Re: fprintf with /r/n outputs only one line Geoff <geoff@invalid.invalid> - 2015-08-30 11:47 -0700
                      Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-30 13:18 -0700
                        Re: fprintf with /r/n outputs only one line Geoff <geoff@invalid.invalid> - 2015-08-30 16:04 -0700
                Re: fprintf with /r/n outputs only one line Ike Naar <ike@iceland.freeshell.org> - 2015-08-30 07:20 +0000
                Re: fprintf with /r/n outputs only one line Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 15:17 -0700
                  Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 16:36 -0700
                    Re: fprintf with /r/n outputs only one line Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 23:19 -0700
                      Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-08 02:50 -0700
              Re: fprintf with /r/n outputs only one line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-30 02:14 +0100

Page 1 of 3  [1] 2 3  Next page →

#68612 — fprintf with /r/n outputs only one line

thanks in advance for any assistance

I am using Ubuntu/Gnome/gcc

when I use this line inside three for loops, I get only one line of 
output instead of 3*3*3, in gnome terminal and in gedit and in emacs

fprintf(fp, "%d %d %d/r/n", i, j, k);

all the data is there, but /r/n is at the end of the line, I tried /r, 
/n, and /n/r   in each case the slash and letter is still in the line 
and there is only one line of output

I tried printf directly to gnome terminal and get the same result

here is my line of output

0 0 0/r/n0 0 1/r/n0 0 2/r/n0 0 3/r/n0 1 0/r/n0 1 1/r/n0 1 2/r/n0 1 
3/r/n0 2 0/r/n0 2 1/r/n0 2 2/r/n0 2 3/r/n0 3 0/r/n0 3 1/r/n0 3 2/r/n0 3 
3/r/n1 0 0/r/n1 0 1/r/n1 0 2/r/n1 0 3/r/n1 1 0/r/n1 1 1/r/n1 1 2/r/n1 1 
3/r/n1 2 0/r/n1 2 1/r/n1 2 2/r/n1 2 3/r/n1 3 0/r/n1 3 1/r/n1 3 2/r/n1 3 
3/r/n2 0 0/r/n2 0 1/r/n2 0 2/r/n2 0 3/r/n2 1 0/r/n2 1 1/r/n2 1 2/r/n2 1 
3/r/n2 2 0/r/n2 2 1/r/n2 2 2/r/n2 2 3/r/n2 3 0/r/n2 3 1/r/n2 3 2/r/n2 3 
3/r/n3 0 0/r/n3 0 1/r/n3 0 2/r/n3 0 3/r/n3 1 0/r/n3 1 1/r/n3 1 2/r/n3 1 
3/r/n3 2 0/r/n3 2 1/r/n3 2 2/r/n3 2 3/r/n3 3 0/r/n3 3 1/r/n3 3 2/r/n3 3 
3/r/n

here is my program

#include <stdio.h>


int main()
{

	FILE * fp;
	fp = fopen ("ijk.txt", "w");

	int i;
	int j;
	int k;

	for(i=0; i <= 3; i++)
	{
		for(j=0; j <= 3; j++)
		{

			for(k=0; k <= 3; k++)
			{

			fprintf(fp, "%d %d %d/r/n", i, j, k);

			}
		
		}
	
	}

	fclose(fp);
	return(0);

}





-- 
Dale

[toc] | [next] | [standalone]

#68613

Dale <dale@dalekelly.org> writes:

> thanks in advance for any assistance
>
> I am using Ubuntu/Gnome/gcc
>
> when I use this line inside three for loops, I get only one line of
> output instead of 3*3*3, in gnome terminal and in gedit and in emacs
>
> fprintf(fp, "%d %d %d/r/n", i, j, k);
>
> all the data is there, but /r/n is at the end of the line, I tried /r,
> /n, and /n/r   in each case the slash and letter is still in the line
> and there is only one line of output
>
> I tried printf directly to gnome terminal and get the same result
>
> here is my line of output
>
> 0 0 0/r/n0 0 1/r/n0 0 2/r/n0 0 3/r/n0 1 0/r/n0 1 1/r/n0 1 2/r/n0 1
> 3/r/n0 2 0/r/n0 2 1/r/n0 2 2/r/n0 2 3/r/n0 3 0/r/n0 3 1/r/n0 3 2/r/n0
> 3 3/r/n1 0 0/r/n1 0 1/r/n1 0 2/r/n1 0 3/r/n1 1 0/r/n1 1 1/r/n1 1
> 2/r/n1 1 3/r/n1 2 0/r/n1 2 1/r/n1 2 2/r/n1 2 3/r/n1 3 0/r/n1 3 1/r/n1
> 3 2/r/n1 3 3/r/n2 0 0/r/n2 0 1/r/n2 0 2/r/n2 0 3/r/n2 1 0/r/n2 1
> 1/r/n2 1 2/r/n2 1 3/r/n2 2 0/r/n2 2 1/r/n2 2 2/r/n2 2 3/r/n2 3 0/r/n2
> 3 1/r/n2 3 2/r/n2 3 3/r/n3 0 0/r/n3 0 1/r/n3 0 2/r/n3 0 3/r/n3 1
> 0/r/n3 1 1/r/n3 1 2/r/n3 1 3/r/n3 2 0/r/n3 2 1/r/n3 2 2/r/n3 2 3/r/n3
> 3 0/r/n3 3 1/r/n3 3 2/r/n3 3 3/r/n
>
> here is my program
>
> #include <stdio.h>
>
>
> int main()
> {
>
> 	FILE * fp;
> 	fp = fopen ("ijk.txt", "w");
>
> 	int i;
> 	int j;
> 	int k;
>
> 	for(i=0; i <= 3; i++)
> 	{
> 		for(j=0; j <= 3; j++)
> 		{
>
> 			for(k=0; k <= 3; k++)
> 			{
>
> 			fprintf(fp, "%d %d %d/r/n", i, j, k);
>
> 			}
> 		
> 		}
> 	
> 	}
>
> 	fclose(fp);
> 	return(0);
>
> }

Try \ instead of /

[toc] | [prev] | [next] | [standalone]

#68615

On 08/28/2015 11:25 PM, Joe Pfeiffer wrote:
> Dale <dale@dalekelly.org> writes:
>
>> thanks in advance for any assistance
>>
>> I am using Ubuntu/Gnome/gcc
>>
>> when I use this line inside three for loops, I get only one line of
>> output instead of 3*3*3, in gnome terminal and in gedit and in emacs
>>
>> fprintf(fp, "%d %d %d/r/n", i, j, k);
>>
>> all the data is there, but /r/n is at the end of the line, I tried /r,
>> /n, and /n/r   in each case the slash and letter is still in the line
>> and there is only one line of output
>>
>> I tried printf directly to gnome terminal and get the same result
>>
>> here is my line of output
>>
>> 0 0 0/r/n0 0 1/r/n0 0 2/r/n0 0 3/r/n0 1 0/r/n0 1 1/r/n0 1 2/r/n0 1
>> 3/r/n0 2 0/r/n0 2 1/r/n0 2 2/r/n0 2 3/r/n0 3 0/r/n0 3 1/r/n0 3 2/r/n0
>> 3 3/r/n1 0 0/r/n1 0 1/r/n1 0 2/r/n1 0 3/r/n1 1 0/r/n1 1 1/r/n1 1
>> 2/r/n1 1 3/r/n1 2 0/r/n1 2 1/r/n1 2 2/r/n1 2 3/r/n1 3 0/r/n1 3 1/r/n1
>> 3 2/r/n1 3 3/r/n2 0 0/r/n2 0 1/r/n2 0 2/r/n2 0 3/r/n2 1 0/r/n2 1
>> 1/r/n2 1 2/r/n2 1 3/r/n2 2 0/r/n2 2 1/r/n2 2 2/r/n2 2 3/r/n2 3 0/r/n2
>> 3 1/r/n2 3 2/r/n2 3 3/r/n3 0 0/r/n3 0 1/r/n3 0 2/r/n3 0 3/r/n3 1
>> 0/r/n3 1 1/r/n3 1 2/r/n3 1 3/r/n3 2 0/r/n3 2 1/r/n3 2 2/r/n3 2 3/r/n3
>> 3 0/r/n3 3 1/r/n3 3 2/r/n3 3 3/r/n
>>
>> here is my program
>>
>> #include <stdio.h>
>>
>>
>> int main()
>> {
>>
>> 	FILE * fp;
>> 	fp = fopen ("ijk.txt", "w");
>>
>> 	int i;
>> 	int j;
>> 	int k;
>>
>> 	for(i=0; i <= 3; i++)
>> 	{
>> 		for(j=0; j <= 3; j++)
>> 		{
>>
>> 			for(k=0; k <= 3; k++)
>> 			{
>>
>> 			fprintf(fp, "%d %d %d/r/n", i, j, k);
>>
>> 			}
>> 		
>> 		}
>> 	
>> 	}
>>
>> 	fclose(fp);
>> 	return(0);
>>
>> }
>
> Try \ instead of /
>

worked, thanks a lot


-- 
Dale
http://www.dalekelly.org

[toc] | [prev] | [next] | [standalone]

#68614

On 08/28/2015 11:08 PM, Dale wrote:
> thanks in advance for any assistance
> 
> I am using Ubuntu/Gnome/gcc
> 
> when I use this line inside three for loops, I get only one line of 
> output instead of 3*3*3, in gnome terminal and in gedit and in emacs
> 
> fprintf(fp, "%d %d %d/r/n", i, j, k);

The escape sequence for a new line character is "\n", "/n" just codes
for a forward slash following by an 'n'.

> all the data is there, but /r/n is at the end of the line, I tried /r, 
> /n, and /n/r   in each case the slash and letter is still in the line 
> and there is only one line of output

On Unix-like systems, newlines are indicated by a single character,
'\n'. On other systems, they may be indicated by "\r\n" or "\n\r". On
more exotic systems, lines of output may be stored in fixed-sized
blocks. The end of the line might be indicated by a counter at the
beginning of the block or by having everything past the end of the line
padded with blanks (' ') or nulls ('\0'). Other possibilities are also
allowed, those are just the more common ones that I'm familiar with.

If you open a file in binary mode by adding "b" to the fopen() mode,
then you will have to worry about all of those details, and deal with
them yourself. However, since you opened your file in text mode, you
don't have to worry how the end of the line is represented on disk. When
you write "\n" to a file, the appropriate line-ending for the system
you're using will be created. When you read the end of a line on input,
it will be converted into "\n" by the C standard library's I/O routines.

This can cause problems if the system where a file was created uses a
different method of indicating the end of the line than that used on the
system where the file is read. That's why some people recommend always
opening files in binary mode, but in general those people are unwilling
to deal with the full range of possible methods for indicating the end
of a line. The right solution to this problem is to have a utility
routine that can be used to convert a file so that line-endings are
marked in the appropriate way for the current system.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#68616

On 08/28/2015 11:34 PM, James Kuyper wrote:
> On 08/28/2015 11:08 PM, Dale wrote:
>> thanks in advance for any assistance
>>
>> I am using Ubuntu/Gnome/gcc
>>
>> when I use this line inside three for loops, I get only one line of
>> output instead of 3*3*3, in gnome terminal and in gedit and in emacs
>>
>> fprintf(fp, "%d %d %d/r/n", i, j, k);
>
> The escape sequence for a new line character is "\n", "/n" just codes
> for a forward slash following by an 'n'.
>
>> all the data is there, but /r/n is at the end of the line, I tried /r,
>> /n, and /n/r   in each case the slash and letter is still in the line
>> and there is only one line of output
>
> On Unix-like systems, newlines are indicated by a single character,
> '\n'. On other systems, they may be indicated by "\r\n" or "\n\r". On
> more exotic systems, lines of output may be stored in fixed-sized
> blocks. The end of the line might be indicated by a counter at the
> beginning of the block or by having everything past the end of the line
> padded with blanks (' ') or nulls ('\0'). Other possibilities are also
> allowed, those are just the more common ones that I'm familiar with.
>
> If you open a file in binary mode by adding "b" to the fopen() mode,
> then you will have to worry about all of those details, and deal with
> them yourself. However, since you opened your file in text mode, you
> don't have to worry how the end of the line is represented on disk. When
> you write "\n" to a file, the appropriate line-ending for the system
> you're using will be created. When you read the end of a line on input,
> it will be converted into "\n" by the C standard library's I/O routines.
>
> This can cause problems if the system where a file was created uses a
> different method of indicating the end of the line than that used on the
> system where the file is read. That's why some people recommend always
> opening files in binary mode, but in general those people are unwilling
> to deal with the full range of possible methods for indicating the end
> of a line. The right solution to this problem is to have a utility
> routine that can be used to convert a file so that line-endings are
> marked in the appropriate way for the current system.
>

yes, I read about this while trying to google my problem, didn't seem 
too difficult, think it was a combination of \r and \n
http://www.thecodingforums.com/threads/carriage-return-and-fprintf.647887/

the link says unix/linus uses just \n, but \r\n seems to work

I don't know how to pull the operating system identification so I can 
use the appropriate code to end the line and start a new one

thanks a lot

-- 
Dale
http://www.dalekelly.org

[toc] | [prev] | [next] | [standalone]

#68617

On 08/29/2015 06:02 AM, Dale wrote:
> On 08/28/2015 11:34 PM, James Kuyper wrote:
[...]
> 
> yes, I read about this while trying to google my problem, didn't seem too difficult, think it was a combination of \r and \n
> http://www.thecodingforums.com/threads/carriage-return-and-fprintf.647887/
> 
> the link says unix/linus uses just \n, but \r\n seems to work
> 
> I don't know how to pull the operating system identification so I can use the appropriate code to end the line and start a new one
> 
> thanks a lot
> 
For application portability they say you're supposed to fopen the stream with "r+t" so you'll get newline translation on the 
windows boxes and Linux ignores the t flag. You then can terminate the line with \n always and get the correct result. 

You may want to output explicit \r when you need to generate those files on a Linux box, for use in wine, DOSbox or 
an actual M$ OS.

[toc] | [prev] | [next] | [standalone]

#68619

On Sat, 2015-08-29, Johann Klammer wrote:
> On 08/29/2015 06:02 AM, Dale wrote:
>> On 08/28/2015 11:34 PM, James Kuyper wrote:
> [...]
>> 
>> yes, I read about this while trying to google my problem, didn't seem too difficult, think it was a combination of \r and \n
>> http://www.thecodingforums.com/threads/carriage-return-and-fprintf.647887/
>> 
>> the link says unix/linus uses just \n, but \r\n seems to work
>> 
>> I don't know how to pull the operating system identification so I can use the appropriate code to end the line and start a new one

> For application portability they say you're supposed to fopen the
> stream with "r+t" so you'll get newline translation on the 
> windows boxes and Linux ignores the t flag. You then can terminate
> the line with \n always and get the correct result. 

What does 't' do?  It's non-standard to I cannot easily check.

I also don't understand the problem.  If you use fopen() and so on, and
don't ask to do I/O in binary mode, whatever line endings the OS uses
are converted so your code only sees \n.  It Just Works.

> You may want to output explicit \r when you need to generate those
> files on a Linux box, for use in wine, DOSbox or > an actual M$ OS.

You need to emit actual CR-LF when you're implementing Internet
protocols like HTTP.  Generating text files on Unix for use in Windows
... certainly that too, but it seems like a rare use case.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#68621

Johann Klammer <klammerj@NOSPAM.a1.net> writes:
> On 08/29/2015 06:02 AM, Dale wrote:
>> On 08/28/2015 11:34 PM, James Kuyper wrote:
> [...]
>> 
>> yes, I read about this while trying to google my problem, didn't seem
>> too difficult, think it was a combination of \r and \n
>> http://www.thecodingforums.com/threads/carriage-return-and-fprintf.647887/
>> 
>> the link says unix/linus uses just \n, but \r\n seems to work
>> 
>> I don't know how to pull the operating system identification so I can
>> use the appropriate code to end the line and start a new one

The whole point is that you don't need to.

> For application portability they say you're supposed to fopen the
> stream with "r+t" so you'll get newline translation on the windows
> boxes and Linux ignores the t flag. You then can terminate the line
> with \n always and get the correct result.

The 't' is non-standard.  To open a file for writing in text mode, use "w".
To open a file for writing in binary mode, use "wb".

In text mode, print a single '\n' (no '\r') to mark the end of each
line.  This will print the appropriate end-of-line sequence for whatever
system your program is running on.

> You may want to output explicit \r when you need to generate those
> files on a Linux box, for use in wine, DOSbox or an actual M$ OS.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#68635

On 08/29/2015 12:02 AM, Dale wrote:
> On 08/28/2015 11:34 PM, James Kuyper wrote:
...
>> On Unix-like systems, newlines are indicated by a single character,
>> '\n'. On other systems, they may be indicated by "\r\n" or "\n\r". On
>> more exotic systems, lines of output may be stored in fixed-sized
>> blocks. The end of the line might be indicated by a counter at the
>> beginning of the block or by having everything past the end of the line
>> padded with blanks (' ') or nulls ('\0'). Other possibilities are also
>> allowed, those are just the more common ones that I'm familiar with.
>>
>> If you open a file in binary mode by adding "b" to the fopen() mode,
>> then you will have to worry about all of those details, and deal with
>> them yourself. However, since you opened your file in text mode, you
>> don't have to worry how the end of the line is represented on disk. When
>> you write "\n" to a file, the appropriate line-ending for the system
>> you're using will be created. When you read the end of a line on input,
>> it will be converted into "\n" by the C standard library's I/O routines.
>>
>> This can cause problems if the system where a file was created uses a
>> different method of indicating the end of the line than that used on the
>> system where the file is read. That's why some people recommend always
>> opening files in binary mode, but in general those people are unwilling
>> to deal with the full range of possible methods for indicating the end
>> of a line. The right solution to this problem is to have a utility
>> routine that can be used to convert a file so that line-endings are
>> marked in the appropriate way for the current system.
>>
> 
> yes, I read about this while trying to google my problem, didn't seem 
> too difficult, think it was a combination of \r and \n
> http://www.thecodingforums.com/threads/carriage-return-and-fprintf.647887/
> 
> the link says unix/linus uses just \n, but \r\n seems to work

Not really: The '\n' works to mark the line, and the '\r' just sits at
the end of the line, where it might or might not be visible, depending
upon how you're viewing the file, and where it might or might not cause
problems, depending upon what you do with the file.

> I don't know how to pull the operating system identification so I can 
> use the appropriate code to end the line and start a new one

There is no standard way to determine which operating system your code
is running on (there's a wide variety non-standard ways, none of which
works universally). That's why the best approach is to use text mode, so
that you don't have to worry about which method is used to mark the end
of the line. Just let the C standard library take care of it for you.

[toc] | [prev] | [next] | [standalone]

#68643

James Kuyper <jameskuyper@verizon.net> wrote:
> On 08/29/2015 12:02 AM, Dale wrote:
>> On 08/28/2015 11:34 PM, James Kuyper wrote:

>>> On Unix-like systems, newlines are indicated by a single character,
>>> '\n'. On other systems, they may be indicated by "\r\n" or "\n\r". On
>>> more exotic systems, lines of output may be stored in fixed-sized
>>> blocks. The end of the line might be indicated by a counter at the
>>> beginning of the block or by having everything past the end of the line
>>> padded with blanks (' ') or nulls ('\0'). Other possibilities are also
>>> allowed, those are just the more common ones that I'm familiar with.

(snip) 
 
>> the link says unix/linus uses just \n, but \r\n seems to work
 
> Not really: The '\n' works to mark the line, and the '\r' just sits at
> the end of the line, where it might or might not be visible, depending
> upon how you're viewing the file, and where it might or might not cause
> problems, depending upon what you do with the file.

Reasonably often, programs reading files will ignore the '\r'.
Most unix compilers will ignore them.

But when you start doing comparisons between lines, or fields on
a line, funny things happen.

Even more, when you print them out the '\r' can take effect
on the terminal and cause very confusing results.

-- glen

[toc] | [prev] | [next] | [standalone]

#68710

On Sat, 29 Aug 2015 00:02:08 -0400, Dale <dale@dalekelly.org> wrote:

>On 08/28/2015 11:34 PM, James Kuyper wrote:
>> On 08/28/2015 11:08 PM, Dale wrote:
>>> thanks in advance for any assistance
>>>
>>> I am using Ubuntu/Gnome/gcc
>>>
>>> when I use this line inside three for loops, I get only one line of
>>> output instead of 3*3*3, in gnome terminal and in gedit and in emacs
>>>
>>> fprintf(fp, "%d %d %d/r/n", i, j, k);
>>
>> The escape sequence for a new line character is "\n", "/n" just codes
>> for a forward slash following by an 'n'.
>>
>>> all the data is there, but /r/n is at the end of the line, I tried /r,
>>> /n, and /n/r   in each case the slash and letter is still in the line
>>> and there is only one line of output
>>
>> On Unix-like systems, newlines are indicated by a single character,
>> '\n'. On other systems, they may be indicated by "\r\n" or "\n\r". On
>> more exotic systems, lines of output may be stored in fixed-sized
>> blocks. The end of the line might be indicated by a counter at the
>> beginning of the block or by having everything past the end of the line
>> padded with blanks (' ') or nulls ('\0'). Other possibilities are also
>> allowed, those are just the more common ones that I'm familiar with.
>>
>> If you open a file in binary mode by adding "b" to the fopen() mode,
>> then you will have to worry about all of those details, and deal with
>> them yourself. However, since you opened your file in text mode, you
>> don't have to worry how the end of the line is represented on disk. When
>> you write "\n" to a file, the appropriate line-ending for the system
>> you're using will be created. When you read the end of a line on input,
>> it will be converted into "\n" by the C standard library's I/O routines.
>>
>> This can cause problems if the system where a file was created uses a
>> different method of indicating the end of the line than that used on the
>> system where the file is read. That's why some people recommend always
>> opening files in binary mode, but in general those people are unwilling
>> to deal with the full range of possible methods for indicating the end
>> of a line. The right solution to this problem is to have a utility
>> routine that can be used to convert a file so that line-endings are
>> marked in the appropriate way for the current system.
>>
>
>yes, I read about this while trying to google my problem, didn't seem 
>too difficult, think it was a combination of \r and \n
>http://www.thecodingforums.com/threads/carriage-return-and-fprintf.647887/
>
>the link says unix/linus uses just \n, but \r\n seems to work
>
>I don't know how to pull the operating system identification so I can 
>use the appropriate code to end the line and start a new one
>
>thanks a lot

Standard fopen is supposed to be OS agnostic. On Windows, the default
mode of fopen() is "text mode", equivalent to FILE *fp =
fopen("newfile.txt", "t"); therefore fopen("somefile", "w") as you
wrote in your example and your source is portable and "\n" will be
handled correctly for Windows and Linux. Windows will accept the line
ending and output "\r\n" to the file itself, Linux will write "\n".

The text file itself will NOT be portable across Linux and Windows
since the files contain different line endings. The Linux-generated
text file won't be line wrapped when displayed on typical (dumb)
Windows apps like Notepad and the Windows-generated text file will be
double-spaced on Linux editors although newer editors on both
platforms are getting better at handling this mess.

The "t" mode is non-standard. On Linux, a file is opened in text mode
by default unless it's opened with the "b" flag.

[toc] | [prev] | [next] | [standalone]

#68727

Geoff <geoff@invalid.invalid> writes:
[...]
> Standard fopen is supposed to be OS agnostic. On Windows, the default
> mode of fopen() is "text mode", equivalent to FILE *fp =
> fopen("newfile.txt", "t"); therefore fopen("somefile", "w") as you
> wrote in your example and your source is portable and "\n" will be
> handled correctly for Windows and Linux. Windows will accept the line
> ending and output "\r\n" to the file itself, Linux will write "\n".
>
> The text file itself will NOT be portable across Linux and Windows
> since the files contain different line endings. The Linux-generated
> text file won't be line wrapped when displayed on typical (dumb)
> Windows apps like Notepad and the Windows-generated text file will be
> double-spaced on Linux editors although newer editors on both
> platforms are getting better at handling this mess.

Text files with "\r\n" line endings are not typically double-spaced when
viewed on Linux.  The '\r' character usually just causes the cursor to
move to the beginning of the current line.  For example, if you "cat" a
Windows text file, it will usually display normally.

> The "t" mode is non-standard. On Linux, a file is opened in text mode
> by default unless it's opened with the "b" flag.

In Linux, fopen(..., "w") opens a file in text mode, as required by the
C standard.

In Windows, fopen(..., "w") opens a file in text mode, as required by
the C standard.

Which makes me wonder what the non-standard Windows-specific "t" is for.

According to <https://msdn.microsoft.com/en-us/library/yeby3zcb.aspx>,
"t" specifies text mode.  Windows lets you change the default mode to
binary by assigning a value to _fmode or by calling _set_fmode().
Apparently somebody at Microsoft thought that would be a good idea.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#68732

On Sun, 30 Aug 2015 15:17:58 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Geoff <geoff@invalid.invalid> writes:
>[...]
>> Standard fopen is supposed to be OS agnostic. On Windows, the default
>> mode of fopen() is "text mode", equivalent to FILE *fp =
>> fopen("newfile.txt", "t"); therefore fopen("somefile", "w") as you
>> wrote in your example and your source is portable and "\n" will be
>> handled correctly for Windows and Linux. Windows will accept the line
>> ending and output "\r\n" to the file itself, Linux will write "\n".
>>
>> The text file itself will NOT be portable across Linux and Windows
>> since the files contain different line endings. The Linux-generated
>> text file won't be line wrapped when displayed on typical (dumb)
>> Windows apps like Notepad and the Windows-generated text file will be
>> double-spaced on Linux editors although newer editors on both
>> platforms are getting better at handling this mess.
>
>Text files with "\r\n" line endings are not typically double-spaced when
>viewed on Linux.  The '\r' character usually just causes the cursor to
>move to the beginning of the current line.  For example, if you "cat" a
>Windows text file, it will usually display normally.
>
>> The "t" mode is non-standard. On Linux, a file is opened in text mode
>> by default unless it's opened with the "b" flag.
>
>In Linux, fopen(..., "w") opens a file in text mode, as required by the
>C standard.
>
>In Windows, fopen(..., "w") opens a file in text mode, as required by
>the C standard.
>
>Which makes me wonder what the non-standard Windows-specific "t" is for.
>
>According to <https://msdn.microsoft.com/en-us/library/yeby3zcb.aspx>,
>"t" specifies text mode.  Windows lets you change the default mode to
>binary by assigning a value to _fmode or by calling _set_fmode().
>Apparently somebody at Microsoft thought that would be a good idea.

There appear to be two reasons, one old, one not so old.

First, was due to the historical ctrl-z at the ends of text files, a
legacy of MSDOS and CP/M if I am not mistaken:

"Open in text (translated) mode. In this mode, CTRL+Z is interpreted
as an EOF character on input. In files that are opened for
reading/writing by using "a+", fopen checks for a CTRL+Z at the end of
the file and removes it, if it is possible. This is done because using
fseek and ftell to move within a file that ends with CTRL+Z may cause
fseek to behave incorrectly near the end of the file." 

Second, Unicode and the translations involved there.

"In text mode, carriage return-linefeed combinations are translated
into single linefeeds on input, and linefeed characters are translated
to carriage return-linefeed combinations on output. When a Unicode
stream-I/O function operates in text mode (the default), the source or
destination stream is assumed to be a sequence of multibyte
characters. Therefore, the Unicode stream-input functions convert
multibyte characters to wide characters (as if by a call to the mbtowc
function). For the same reason, the Unicode stream-output functions
convert wide characters to multibyte characters (as if by a call to
the wctomb function)."

[toc] | [prev] | [next] | [standalone]

#68734

On 08/30/2015 07:21 PM, Geoff wrote:
> On Sun, 30 Aug 2015 15:17:58 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
> 
>> Geoff <geoff@invalid.invalid> writes:
....
>>> The "t" mode is non-standard. On Linux, a file is opened in text mode
>>> by default unless it's opened with the "b" flag.
>>
>> In Linux, fopen(..., "w") opens a file in text mode, as required by the
>> C standard.
>>
>> In Windows, fopen(..., "w") opens a file in text mode, as required by
>> the C standard.
>>
>> Which makes me wonder what the non-standard Windows-specific "t" is for.
>>
>> According to <https://msdn.microsoft.com/en-us/library/yeby3zcb.aspx>,
>> "t" specifies text mode.  Windows lets you change the default mode to
>> binary by assigning a value to _fmode or by calling _set_fmode().
>> Apparently somebody at Microsoft thought that would be a good idea.
> 
> There appear to be two reasons, one old, one not so old.
> 
> First, was due to the historical ctrl-z at the ends of text files, a
> legacy of MSDOS and CP/M if I am not mistaken:
> 
> "Open in text (translated) mode. In this mode, CTRL+Z is interpreted
> as an EOF character on input. In files that are opened for
> reading/writing by using "a+", fopen checks for a CTRL+Z at the end of
> the file and removes it, if it is possible. This is done because using
> fseek and ftell to move within a file that ends with CTRL+Z may cause
> fseek to behave incorrectly near the end of the file." 
> 
> Second, Unicode and the translations involved there.
> 
> "In text mode, carriage return-linefeed combinations are translated
> into single linefeeds on input, and linefeed characters are translated
> to carriage return-linefeed combinations on output. When a Unicode
> stream-I/O function operates in text mode (the default), the source or
> destination stream is assumed to be a sequence of multibyte
> characters. Therefore, the Unicode stream-input functions convert
> multibyte characters to wide characters (as if by a call to the mbtowc
> function). For the same reason, the Unicode stream-output functions
> convert wide characters to multibyte characters (as if by a call to
> the wctomb function)."

Perhaps I'm missing something here - but I don't see how that resolves
the question. It explains the need for text mode - which is not what
Keith was asking about. It doesn't explain the need for two different
methods for opening a file in text mode, one of which is specified by
the C standard, and the second of which is a conforming extension to C.
Why extend C, when unextended C already had the desired functionality?

[toc] | [prev] | [next] | [standalone]

#68628

<snip>

Just because it's good to see alternatives, here is the same program but
with almost every part changed ever so slightly.  This is not better, it
just shows you some options.

  #include <stdio.h>
  #include <stdlib.h>
  
  int main(void)
  {
      FILE *fp = fopen("ijk.txt", "w");
      if (fp) {
          for(int i = 0; i <= 3; i++)
              for (int j = 0; j <= 3; j++)
          	for (int k = 0; k <= 3; k++)
          	    fprintf(fp, "%d %d %d\n", i, j, k);
          return fclose(fp) == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
      }
      return EXIT_FAILURE;
  }

The points you can accept or reject as you like are

 1. Declaring function parameters as f(void) rather than f() tells the
    compiler more and lets it spot more errors.
 2. Output looks like plain text so you only need \n to get the right
    ending on all systems.
 3. Prefer initialisation over immediate assignment.
 4. Consistency (you had "fopen (" but "fclose(").
 5. Alternate brace placement.
 6. Minimum braces.
 7. Declaring loop variables inside the for statement (modern C only).
 8. return x; rather than return(x).
 9. Don't waste an opportunity to tell the system if things worked.
10. Always test function calls that can fail.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#68631

On 08/29/2015 09:51 AM, Ben Bacarisse wrote:
<snip>
>
> The points you can accept or reject as you like are
>
>   1. Declaring function parameters as f(void) rather than f() tells the
>      compiler more and lets it spot more errors.\

But that's not applicable for main(). main() has a prototype of either

int main(int argc, char **argv)

or, you can just implement main() as:

int main()

>   6. Minimum braces.

That's just coding style issues. Some prefers explicit braces. Check 
Allman style for example.


-- 
Ayan

[toc] | [prev] | [next] | [standalone]

#68636

On 08/29/2015 10:24 AM, Ayan wrote:
> On 08/29/2015 09:51 AM, Ben Bacarisse wrote:
> <snip>
>>
>> The points you can accept or reject as you like are
>>
>>   1. Declaring function parameters as f(void) rather than f() tells the
>>      compiler more and lets it spot more errors.\
> 
> But that's not applicable for main(). main() has a prototype of either
> 
> int main(int argc, char **argv)
> 
> or, you can just implement main() as:
> 
> int main()

Declarations equivalent to those are allowed, and int main(void) is
equivalent for that purpose. If any part of your code calls main()
(which is rarely done, but permitted), then using a prototype for main()
that matches the way it was defined will improve the safety of your code.

[toc] | [prev] | [next] | [standalone]

#68645

On 08/29/2015 10:32 AM, Stefan Ram wrote:
> Ayan <selfjam@gmail.com> writes:
>> But that's not applicable for main(). main() has a prototype of either
>> int main(int argc, char **argv)
>> or, you can just implement main() as:
>> int main()
>
>        »5.1.2.2.1 Program startup« ...
>        »It shall be defined with a return type of int and with
>        no parameters:
>        int main(void) { /* ... */ }
>        or with two parameters« ...
>        »or equivalent; or in some other implementation-defined manner.«
>
Ah! I did not know this. Thanks for pointing that out.

-- 
Ayan

[toc] | [prev] | [next] | [standalone]

#68652

Ayan <selfjam@gmail.com> writes:
> On 08/29/2015 09:51 AM, Ben Bacarisse wrote:
> <snip>
>>
>> The points you can accept or reject as you like are
>>
>>   1. Declaring function parameters as f(void) rather than f() tells the
>>      compiler more and lets it spot more errors.\
>
> But that's not applicable for main().

Yes, it is.

>                                       main() has a prototype of either
>
> int main(int argc, char **argv)
>
> or, you can just implement main() as:
>
> int main()

The standard says

    int main(void)

It's legal (but generallyl a bad idea) to call main, so adding the
explicit "void" improves error-checking.  In any case, `int main(){}`
is an old-style definition, which is an obsolescent feature.
There's no good reason not to include the void keyword, even if you're
never going to call main.

http://the-flat-trantor-society.blogspot.com/2014/02/c-standard-quibbles.html

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#68634

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>Just because it's good to see alternatives, here is the same program but
>
>   I also do not claim that the following is better, 
>   it is just another option!
>
> #include <stdio.h>  // fopen, fprintf, fclose
> #include <stdlib.h> // EXIT_SUCCESS, EXIT_FAILURE
>
> static inline int write_to( FILE * const file )
> { for( int i = 0; i <= 3; ++i )
>   for( int j = 0; j <= 3; ++j )
>   for( int k = 0; k <= 3; ++k )
>   if( 0 > fprintf( file, "%d %d %d\n", i, j, k ))
>   return EXIT_FAILURE;
>   return EXIT_SUCCESS; }
>
> static inline int use_and_close_valid_file( FILE * const file )
> { int const result = write_to( file );
>   return fclose( file )? EXIT_FAILURE : result; }
>
> static inline int use_and_close_file( FILE * const file )
> { return file ? use_and_close_valid_file( file ): EXIT_FAILURE; }

I am not keen on mixing the meanings here.  The two standard EXIT types
are for main, and you've added some complexity just to use them as
status returns for function that could equally be used in other
situations.

Hence I'd make all the helper function return bool:

  static bool write_to(FILE *file)
  {
      for (  int i = 0; i <= 3; ++i)
          for (int j = 0; j <= 3; ++j)
              for (int k = 0; k <= 3; ++k)
                  if (fprintf(file, "%d %d %d\n", i, j, k) < 0)
                      return false;
      return true;
  }
 
  static bool use_and_close_valid_file(FILE *file)
  {
      const bool wrote_it = write_to(file);
      return fclose(file) && write_it;
  }
 
  static bool use_and_close_file(FILE *file)
  {
      return file && use_and_close_valid_file(file);
  }

Only in main would the exit status appear:

 int main(void)
 {
    return use_and_close_file(fopen("xyzzy.txt", "w"))[
           (bool []){ EXIT_FAILURE, EXIT_SUCCESS }
    ];
 }

(the use of a compound literal is a joke.  I don't want this to be taken
too seriously!)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web