Reading Text Files

[Keith Thompson]

You are apparently treating a shell as part of the OS. You're not
alone, it's very common amongst DOS-heads, for example, but it's
a view that no-one I know who actually works on operating systems
shares.

MS Paint came with MS Windows. Does that make MS Paint part of the
OS too, in your eyes?

The question was:

| Please elucidate. In what cases will the use of '/' fail?

How is the question of whether the shell is part of the OS relevant to
that question?

Whether cmd.com (or MS Paint) is part of the Windows OS might be
an interesting question to some, but it's not relevant either to
this newsgroup or to this discussion. The point (which is only
peripherally relevant to comp.lang.c) is that there are cases under
Windows where using '/' as a directory separator can cause problems;
I showed an example using the standard C system() function. If
you want to argue that the OS itself doesn't care whether you
use / or \, I won't disagree -- but it does matter in the context
of a C implementation.

 

[Phil Carmody]

The question was:

| Please elucidate. In what cases will the use of '/' fail?

How is the question of whether the shell is part of the OS relevant to
that question?

I just inserted the text 'c:/a.txt' into a MS Paint image, but
MS Paint didn't open the file. Therefore we have another example
of where '/' fails! Maybe I should have used a heavier font?

Oh no, how silly of me - MS Paint isn't the operating system,
MS Paint is just a user space program.


Now let's see if the 'type' program opens the file 'c:/a.txt'.
It doesn't. So finally we have an actual example of '/' failing.

But of course, it's only a valid example because 'type' is part
of the operating system and MS Paint isn't.

That's apparently that's your stance. Strangely you seem so proud
of it that you're prepared to repeat it.

But back to your question - why is the distinction important -
because the only thing that matters when it comes to the results
of an fopen is the interface defined by the OS, and not the
interfaces and behaviour of external programs such as the shell,
type, and MS Paint.

This is such a black and white issue, I'm perturbed you can't see
the distinction. Maybe too much DOS or Symbian has rotted your brain,
or something.

Whether cmd.com (or MS Paint) is part of the Windows OS might be
an interesting question to some, but it's not relevant either to
this newsgroup or to this discussion. The point (which is only
peripherally relevant to comp.lang.c) is that there are cases under
Windows where using '/' as a directory separator can cause problems;
I showed an example using the standard C system() function. If
you want to argue that the OS itself doesn't care whether you
use / or \, I won't disagree -- but it does matter in the context
of a C implementation.

That's a completely stupid argument. You were using a "spawn a
user-space process with malformed parameters" example to try
and say something about the OS. You were called on it, and now
all you can do is say that on this newsgroup the difference
between what's the OS and what's a user-space process is irrelevant.
Sorry to burst your bubble, but it's absolutely 100% relevant.
One is opening a file with fopen(), the other is spawning a
user-space process which can do whatever it likes when parsing
the arguments given to it.

Imagine if Chuck said something like "strcmp is just grep",
you'd be down on him like a ton of bricks. But you've just said
something equally fatuous, wrong, and misleading to those who
wish to learn C.

Phil

 

[Kenny McCormack]

Phil Carmody <[email protected]> berated Officer
Keith Thompson well and soundly, leading up to:
....

Imagine if Chuck said something like "strcmp is just grep",
you'd be down on him like a ton of bricks. But you've just said
something equally fatuous, wrong, and misleading to those who
wish to learn C.

Well, it looks to me that this marriage cannot be saved.

Wonder what GH (actually, I think it was Reader's Digest) would have to say...

P.S. (For those who may not be fully conversant on this and how it all
relates to the dogma of CLC) CLC claims to be OS-neutral, but we all
know it is really the age-old "Unix vs. DOS" flamewar that animates most
of the Usenet. This thread is a nice example of this principle.

Note further that "Unix vs. DOS" is really just a wrapper around the real
conflict that motivates all of humanity, which is "quality vs. quantity".

 

[JosephKK]

Keith Thompson said:



True enough.

The context of the question is Windows, and this really is one of
those questions that has far more to do with Windows than it has
with C, and ought properly to be asked in a group such as
comp.os.ms-windows.programmer.win32. As far as C is concerned, the
first argument to fopen is a string that represents a filename on
the host system. If the string doesn't represent such a filename,
fopen cannot possibly open it, right? So it is the programmer's
responsibility to ensure that the filename is valid. Even if
Windows did support forward slashes as a path separator in all
filename contexts, embedding them in a string literal is a silly
idea if the program is to be portable. Some operating systems don't
even have a concept of "path", at least not in the same sense that
Windows does, or Unix does, or Linux does. There are other ways to
organise files than in an open tree.

Consider, for example, MVS, in which filenames consist of digits,
letters, and dots (and you can't have more than eight non-dot
characters in a row). On many sites, the dots are used as if they
were directory separators, but MVS doesn't enforce this.

Furthermore, MVS allows the creation of Partitioned Data Sets
(PDSs), which consist of multiple members, each of which can be
considered a separate file. Thus, the Partitioned Data Set
FOO.BAR.BAZ might have three members, FOO.BAR.BAZ(QUUX),
FOO.BAR.BAZ(QUUUX) and FOO.BAR.BAZ(QUUUUX). Looked at in this way,
the parentheses can be thought of as (paired) "filename
delimiters", but *only* in the context of a PDS.

A portable C program can easily deal with such a system. I know,
because I've written a great many such programs. The trick is to
avoid hard-coding "magic" filenames.

<snip>

Yep. In the early 1990s i dealt with IBM MVS and had to handle things
called generational data sets, which seem to be a variation of
partitioned data sets, whith the current version and a few to hundreds
of previous generations. I had to get special permission to load
something like 220 MB to 250 MB per week into a 5 generation data set.
A couple years later working with VAX VMS with a similar file naming
system that automatically stored backups.

 

[Dik T. Winter]

> In article <[email protected]>,

>
> Keith is, of course, correct here.

In the same way, on Unix/Linux systems "*" is a valid name for a file, but
a name that can't be used in all contexts. Try on Linux:
system("ls *");
it will not only show the file named "*". Try to show a consistent form
such that a file with the name "*" can be used both in system and in fopen.
There is none. (%)

The difference is that fopen is directly talking to the OS, while for system
it is explicitly stated that there is some intermediate program that can do
anything it wants with the arguments provided to it. Consider:
system("convertnameandtype aaaaa");
you might wish that it did something with the file "aaaaa", but you should
not be too surprised if it does something with the file "ababa". What is
supplied in system is not actually a filename, but an argument on a command
to a particular program.

 

[Rafael]

Richard Heathfield escreveu:

Rafael said:



That wouldn't fix his problem, which is that he's forgotten to
escape his backslashes.


It doesn't matter - the code is equally broken in all C compilers,
because backslashes are escape characters in ISO C.

Good point. That's probably the issue.

Mike (I guess), try:

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

 

[Keith Thompson]

I just inserted the text 'c:/a.txt' into a MS Paint image, but
MS Paint didn't open the file. Therefore we have another example
of where '/' fails! Maybe I should have used a heavier font?

Oh no, how silly of me - MS Paint isn't the operating system,
MS Paint is just a user space program.

[snip]

I think there's been some confusion of terminology in this thread.
It's quite possible that I've unintentionally contributed to it.
I'll try to summarize the facts of the matter, without necessarily
trying to analyze who made what mistake when.

The \ character can be used as a directory delimiter in Windows.
For example,
C:\foo.txt
is a valid file name, where C is the name of the drive, \ separates
the drive name from the file name (so C:\ denotes the root directory
of the C drive), and foo.txt is the name of the file (in a form
that's useful only if you know where it is).

The use of the \ character can sometimes cause confusion in
C programs. The naively obvious way to write the full name of
the file in C as a string literal is "C:\foo.txt" -- but that's
incorrect, because \ has a special meaning in C string literals.
The way to specify the name as C:\foo.txt is to double the backslash
in the string literal: "C:\\foo.txt".

It's often pointed out here that the operating system will also
accept the / character as a synonym for the \ character, so you
can avoid doubling the \ by writing "C:/foo.txt" rather than
"C:\\foo.txt".

As I understand it, this advice is valid if the string is only going
to be used as a file name to be passed to fopen(). There are other
contexts in a Windows environment, and in a C program compiled for a
Windows environment, where "C:/foo.txt" is *not* equivalent to
"C:\\foo.txt".

For example, if the name is going to be displayed to a user, the
replacement will cause the displayed text to be different, and is
likely to be confusing to Windows users who don't happen to be aware
that the OS allows /.

Another example is when the file name is incorporated into a string
passed to the system() function. system() invokes the command
processor; on Windows, this is usually cmd.exe. The / character is
treated specially by cmd.exe.

So, in my opinion, the advice to use / rather than \ as the directory
delimiter in C programs for Windows is valid *only* if the strings
containing the delimiter will be used only as arguments to fopen
(an assumption that can easily become incorrect as the program is
maintained). The better solution (again, this is just my opinion)
is to use the \ character consistently, and to deal with the fact
that \ is special in C string literals by doubling it when necessary.

There are some other issues that have come up in this discussion that,
in my opinion, are not relevant either to this discussion or to this
newsgroup:

Is cmd.exe part of the operating system?

Is cmd.exe part of Windows?

Are "Windows" and the operating system the same thing, or does the
term "Windows" refer to the OS plus other things?

These might all be interesting questions, but I don't think any of
them are relevant to the issue of a C program running in a Windows
environment. A more relevant question is whether cmd.exe is part of
the C implementation. If the implementation's system() function
invokes cmd.exe, then I would argue that yes, cmd.exe is part of the C
implementation (or at the very least that the C implementation depends
on it).

Joe Wright's question was:

Please elucidate. In what cases will the use of '/' fail?

I believe I answered that question. If the question were meant to be
limited to fopen, Joe should have said so.

Now let's see if the 'type' program opens the file 'c:/a.txt'.
It doesn't. So finally we have an actual example of '/' failing.

But of course, it's only a valid example because 'type' is part
of the operating system and MS Paint isn't.

That's apparently that's your stance. Strangely you seem so proud
of it that you're prepared to repeat it.

But back to your question - why is the distinction important -
because the only thing that matters when it comes to the results
of an fopen is the interface defined by the OS, and not the
interfaces and behaviour of external programs such as the shell,
type, and MS Paint.

Yes, it's what matters when it comes to the result of an fopen.
I wasn't aware that the discussion had been restricted to just the
fopen function.

This is such a black and white issue, I'm perturbed you can't see
the distinction. Maybe too much DOS or Symbian has rotted your brain,
or something.

[snip]

Maybe we could have a civilized discussion without personal insults.

 

[Richard Bos]

You are apparently treating a shell as part of the OS. You're not
alone, it's very common amongst DOS-heads, for example, but it's
a view that no-one I know who actually works on operating systems
shares.

That's as may be, but it's the view that most _users_ of operating
systems do share.

The car business may pretend that the tires aren't part of the car
(because, after all, you can change them if you wish), but you'd be hard
put to find a driver who disagrees.

MS Paint came with MS Windows. Does that make MS Paint part of the
OS too, in your eyes?

Certainly. It comes in the same package and you cannot avoid buying one
without the other.

Richard