Reading Text Files

[Mike]

Hi,

I'm trying to create a C function that will read a text file but I keep
getting fopen() = NULL

I've tried my own code and when that didn't work I tried code off various
websites and they keep giving the same result.

The file was created in notepad, saved as a .txt and contains only "abcd"
without quotes.

Only thing I can think of is that the program doesn't have rights to access
the file....possibly because it's Vista? But nothing turns up after
searching.

The code is written:

FILE *fp;
fp = fopen( "C:\Users\<Username>\Documents\R.txt", "r" );

Is there anyway to find out why it can't open the file?

Cheers,

Mike

 

[Willem]

Mike wrote:
) The code is written:
)
) FILE *fp;
) fp = fopen( "C:\Users\<Username>\Documents\R.txt", "r" );
)
) Is there anyway to find out why it can't open the file?

Yes, print the error code:

perror("Error opening C:\Users\<Username>\Documents\R.txt");

And then all will hopefully become clear.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Antoninus Twink]

fp = fopen( "C:\Users\<Username>\Documents\R.txt", "r" );

Is there anyway to find out why it can't open the file?

You need to escape backslashes in string literals: try
fp = fopen( "C:\\Users\\<Username>\\Documents\\R.txt", "r" );

I believe Windows will also accept forward slashes in pathnames, which
would mean you don't need to do any escaping at all.

 

[Mike]

Backslash is an escape character, so you probably want to replace all
the backslashes with \\

-- Richard

Yup thanks,

I called perror() and it returned a string without quotes.

Cheers,

 

[Richard Tobin]

fp = fopen( "C:\Users\<Username>\Documents\R.txt", "r" );

Backslash is an escape character, so you probably want to replace all
the backslashes with \\

-- Richard

 

[Rich Webb]

Mike wrote:
) The code is written:
)
) FILE *fp;
) fp = fopen( "C:\Users\<Username>\Documents\R.txt", "r" );
)
) Is there anyway to find out why it can't open the file?

Yes, print the error code:

perror("Error opening C:\Users\<Username>\Documents\R.txt");

And then all will hopefully become clear.

For this alone, Bill G should spend eternity in Hades cleaning the
Augean stables with a teaspoon...

 

[Bartc]

Yup thanks,

I called perror() and it returned a string without quotes.

I believe you can also use / instead of \, when programming anyway. This
makes life a bit easier.

 

[Richard]

For this alone, Bill G should spend eternity in Hades cleaning the
Augean stables with a teaspoon...

That would hard since the Stables were not in Hades but in Greece.

 

[Kaz Kylheku]

For this alone, Bill G should spend eternity in Hades cleaning the
Augean stables with a teaspoon...

Forward slashes work just fine Microsoft operating systems going back all the
way to MS-DOS, where ``just fine'' excludes parts of the command interpreter
and applications.

In fact, before version 2, MS-DOS only had forward slash path separation.

So when Billy is cleaning those stables, he deserves help from the developers
of COMMAND.COM and CMD.EXE, plus everyone other application developer who has
failed to properly use and support forward slashes on DOS and Windows,
including morons who write backslashes in C string literals intended to
represent paths.

 

[Keith Thompson]

I believe you can also use / instead of \, when programming
anyway. This makes life a bit easier.

<OT>
Yes, you can do that, but it can cause confusion if the path is
displayed to a Windows user who doesn't know that / is a valid
directory separator. It can also cause problems in the command shell,
which doesn't permit / as a directory separator. IMHO it's safer
to stick to the "native" \ delimiter.

Of course the C standard says nothing about this.
</OT>

 

[Keith Thompson]

For this alone, Bill G should spend eternity in Hades cleaning the
Augean stables with a teaspoon...

<OT>
There were valid reasons for using \ rather than /. For one thing,
MS-DOS already used / to introduce command-line options.
Interoperability with Unix was not thought to be an important issue;
that turned out to be a bad assumption, but it wasn't completely
unreasonable at the time.
</OT>

 

[Keith Thompson]

Forward slashes work just fine Microsoft operating systems going
back all the way to MS-DOS, where ``just fine'' excludes parts of
the command interpreter and applications.

In fact, before version 2, MS-DOS only had forward slash path
separation.

[...]

Are you sure? My understanding is that MS-DOS version 1 didn't have
directory delimiters at all, since it didn't support directories.

 

[Bartc]

<OT>
Yes, you can do that, but it can cause confusion if the path is
displayed to a Windows user who doesn't know that / is a valid
directory separator. It can also cause problems in the command shell,
which doesn't permit / as a directory separator. IMHO it's safer
to stick to the "native" \ delimiter.

The user display problem occurred to me just after I posted. The net result
I suppose is life is neither easier nor harder when using /.

(In another language I get round this by using a string literal prefix:
F"C:\C\C.C" which just ignores \ escapes in the string.)

 

[Kaz Kylheku]

Forward slashes work just fine Microsoft operating systems going
back all the way to MS-DOS, where ``just fine'' excludes parts of
the command interpreter and applications.

In fact, before version 2, MS-DOS only had forward slash path
separation.

[...]

Are you sure? My understanding is that MS-DOS version 1 didn't have
directory delimiters at all, since it didn't support directories.

You are right. MS-DOS 2 added directories, and support for both slashes at the
same time.

 

[CBFalconer]

.... snip ...

The code is written:

FILE *fp;
fp = fopen( "C:\Users\<Username>\Documents\R.txt", "r" );

Is there anyway to find out why it can't open the file?

Why do you want all those special characters (\U, \<, \D, \R)?

In other words, replace '\' with '/'. Doze is peculiar.

 

[Richard]

Why do you want all those special characters (\U, \<, \D, \R)?

In other words, replace '\' with '/'. Doze is peculiar.

What is Doze? Please follow you own petty net nannying and do not use
acronyms other posters are not familiar with.

 

[Barry Schwarz]

Hi,

I'm trying to create a C function that will read a text file but I keep
getting fopen() = NULL

I've tried my own code and when that didn't work I tried code off various
websites and they keep giving the same result.

The file was created in notepad, saved as a .txt and contains only "abcd"
without quotes.

Only thing I can think of is that the program doesn't have rights to access
the file....possibly because it's Vista? But nothing turns up after
searching.

The code is written:

FILE *fp;
fp = fopen( "C:\Users\<Username>\Documents\R.txt", "r" );

Did not your compiler generate some mandatory diagnostics on this
line? If not, you need to up the warning level. If yes, why did you
ignore them?

Is there anyway to find out why it can't open the file?

You could look in your reference for what the C language does with a
'\' character in a string literal.

 

[Flash Gordon]

Did not your compiler generate some mandatory diagnostics on this
line?

What mandatory diagnostic? In C90 those are all just simple escape
sequences invoking undefined behaviour. If gcc is right then \U has
special meaning in C99, but there is every chance the OP is not using C99.

If not, you need to up the warning level. If yes, why did you
ignore them?

Upping the warning level is often the way, and simply ignoring
diagnostics is never good.

You could look in your reference for what the C language does with a
'\' character in a string literal.

Definitely a good idea.

 

[Mark Wooding]

What mandatory diagnostic? In C90 those are all just simple escape
sequences invoking undefined behaviour. If gcc is right then \U has
special meaning in C99, but there is every chance the OP is not using
C99.

In C99 they're a syntax error:

6.4.5:

: string-literal:
: " s-char-sequenceopt "
: L" s-char-sequenceopt "
: s-char-sequence:
: s-char
: s-char-sequence s-char
: s-char:
: any member of the source character set except
: the double-quote ", backslash \, or new-line
: character
: escape-sequence

6.4.4.4:

: escape-sequence:
: simple-escape-sequence
: octal-escape-sequence
: hexadecimal-escape-sequence
: universal-character-name
: simple-escape-sequence: one of
: \' \" \? \\
: \a \b \f \n \r \t \v
: octal-escape-sequence:
: \ octal-digit
: \ octal-digit octal-digit
: \ octal-digit octal-digit octal-digit
: hexadecimal-escape-sequence:
: \x hexadecimal-digit
: hexadecimal-escape-sequence hexadecimal-digit

6.4.3:

: universal-character-name:
: \u hex-quad
: \U hex-quad hex-quad
: hex-quad:
: hexadecimal-digit hexadecimal-digit
: hexadecimal-digit hexadecimal-digit

6.4.4.1:

: octal-digit: one of
: 0 1 2 3 4 5 6 7
: hexadecimal-digit: one of
: 0 1 2 3 4 5 6 7 8
: a b c d e f
: A B C D E F

-- [mdw]

 

[Bartc]

....
: octal-escape-sequence:
: \ octal-digit
: \ octal-digit octal-digit
: \ octal-digit octal-digit octal-digit
: hexadecimal-escape-sequence:
: \x hexadecimal-digit
: hexadecimal-escape-sequence hexadecimal-digit

So octal numbers are up to 3 digits, while hexadecimal numbers are any
length? That seems odd. The hex escape makes more sense as:

\x hexadecimal-digit
\x hexadecimal-digit hexadecimal-digit

And matches the syntax style for octal.