Could I open a file from another machine on the network?

T

Tola

In my case of study, my teacher gave me a project, after I analysed
the problem I found that I had to used open the file on the other
machine? Please help?
Thank you in advance.
Tola CHROUK
 
M

Mark A. Odell

(e-mail address removed) (Tola) wrote in

In my case of study, my teacher gave me a project, after I analysed
the problem I found that I had to used open the file on the other
machine? Please help?
Thank you in advance.

Your welcome.

You can't do this with standard C. Figure out what OS you are using. Then
go to a newsgroup that discusses programming in that OS environment. Your
question is off-topic here.
 
C

Christopher Benson-Manica

Tola said:
In my case of study, my teacher gave me a project, after I analysed
the problem I found that I had to used open the file on the other
machine? Please help?

(The below welcome text was originally written by Ben Pfaff)

Your question is outside the domain of comp.lang.c, which discusses
only the standard C programming language, including the standard C
library. This is a remarkably narrow topic compared to what many
people expect.

For your convenience, the list below contains topics that are not
on-topic for comp.lang.c, and suggests newsgroups for you to explore
if you have questions about these topics. Please do observe proper
netiquette before posting to any of these newsgroups. In particular,
you should read the group's charter and FAQ, if any (FAQs are
available from www.faqs.org and other sources). If those fail to
answer your question then you should browse through at least two weeks
of recent articles to make sure that your question has not already
been answered.

* OS-specific questions, such as how to clear the screen,
access the network, list the files in a directory, or read
"piped" output from a subprocess. These questions should be
directed to OS-specific newsgroups, such as
comp.os.ms-windows.programmer.misc, comp.unix.programmer, or
comp.os.linux.development.apps.

* Compiler-specific questions, such as installation issues and
locations of header files. Ask about these in
compiler-specific newsgroups, such as gnu.gcc.help or
comp.os.ms-windows.programmer.misc. Questions about writing
compilers are appropriate in comp.compilers.

* Processor-specific questions, such as questions about
assembly and machine code. x86 questions are appropriate in
comp.lang.asm.x86, embedded system processor questions may
be appropriate in comp.arch.embedded.

* ABI-specific questions, such as how to interface assembly
code to C. These questions are both processor- and
OS-specific and should typically be asked in OS-specific
newsgroups.

* Algorithms, except questions about C implementations of
algorithms. "How do I implement algorithm X in C?" is not a
question about a C implementation of an algorithm, it is a
request for source code. Newsgroups comp.programming and
comp.theory may be appropriate.

* Making C interoperate with other languages. C has no
facilities for such interoperation. These questions should
be directed to system- or compiler-specific newsgroups. C++
has features for interoperating with C, so consider
comp.lang.c++ for such questions.

* The C standard, as opposed to standard C. Questions about
the C standard are best asked in comp.std.c.

* C++. Please do not post or cross-post questions about C++
to comp.lang.c. Ask C++ questions in C++ newsgroups, such
as comp.lang.c++ or comp.lang.c++.moderated.

* Test posts. Please test in a newsgroup meant for testing,
such as alt.test.

news.groups.questions is a good place to ask about the appropriate
newsgroup for a given topic.
 
D

Derk Gwen

# (e-mail address removed) (Tola) wrote in
#
#
# > In my case of study, my teacher gave me a project, after I analysed
# > the problem I found that I had to used open the file on the other
# > machine? Please help?

# You can't do this with standard C. Figure out what OS you are using. Then

I do all the time. Things like
FILE *f = fopen("/mount/saturn/quark.tcl","r");
 
M

Mark A. Odell

# > In my case of study, my teacher gave me a project, after I analysed
# > the problem I found that I had to used open the file on the other
# > machine? Please help?

# You can't do this with standard C. Figure out what OS you are using.
Then

I do all the time. Things like
FILE *f = fopen("/mount/saturn/quark.tcl","r");

And sounds like your solution isn't very portable then, eh? I mean wonder
if you're running Windows, or DOS, or Mac OS 9? Mounted network file
systems make the remote file appear to C's fopen() as if they exist on the
local machine, it doesn't mean C can connect to a file on a remote
machine.
 
L

Lew Pitcher

Tola said:
In my case of study, my teacher gave me a project, after I analysed
the problem I found that I had to used open the file on the other
machine? Please help?
Thank you in advance.
Tola CHROUK

In C alone, you cannot open a file on the other machine (the C abstract machine
does not recognize the concept of an "other machine").

So, to do this, you will need C /in conjunction with/ some other support. Your
best bet would be to repost your question in one of the fora that is dedicated
to the "other support" you will need. For instance, you might want to ask in one
of the comp.os.linux or comp.os.ms-windows newsgroups for linux or
MSWindows-specific solutions. Or, you might want to ask in comp.protocols.nfs or
comp.protocols.smb for NFS or SMB specific solutions.

--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
 
D

Derk Gwen

#
#
# > # > In my case of study, my teacher gave me a project, after I analysed
# > # > the problem I found that I had to used open the file on the other
# > # > machine? Please help?
# >
# > # You can't do this with standard C. Figure out what OS you are using.
# > Then
# >
# > I do all the time. Things like
# > FILE *f = fopen("/mount/saturn/quark.tcl","r");
#
# And sounds like your solution isn't very portable then, eh? I mean wonder
# if you're running Windows, or DOS, or Mac OS 9? Mounted network file
# systems make the remote file appear to C's fopen() as if they exist on the
# local machine, it doesn't mean C can connect to a file on a remote
# machine.

Guess what, sunshine, it doesn't mean you can connect to local files, or
serial ports, or raw disk devices, or gps units, or anything else. Still
people somehow manage to do this with C.

What is outside the C standard is how the string in the fopen is used to
identify the data source, and what steps are necessary to make the source
available. There's no particular reason why a standard C library could not
(or could) accept something like "ftp://saturn/development/quark.tcl".

Moral of the story being find out what the question really is before
shooting off your mouth and/or foot.
 
M

Mark A. Odell

# > # > In my case of study, my teacher gave me a project, after I
analysed # > # > the problem I found that I had to used open the file on
the other # > # > machine? Please help?
# >
# > # You can't do this with standard C. Figure out what OS you are
using. # > Then
# >
# > I do all the time. Things like
# > FILE *f = fopen("/mount/saturn/quark.tcl","r");
#
# And sounds like your solution isn't very portable then, eh? I mean
wonder # if you're running Windows, or DOS, or Mac OS 9? Mounted network
file # systems make the remote file appear to C's fopen() as if they
exist on the # local machine, it doesn't mean C can connect to a file on
a remote # machine.

Guess what, sunshine, it doesn't mean you can connect to local files, or
serial ports, or raw disk devices, or gps units, or anything else. Still
people somehow manage to do this with C.

No, they do not use *ISO C*, the topic of this newsgroup, to do it! They
must use non-standard, off-topic, not part of C, extensions!
What is outside the C standard is how the string in the fopen is used to
identify the data source, and what steps are necessary to make the
source available. There's no particular reason why a standard C library
could not (or could) accept something like
"ftp://saturn/development/quark.tcl".

Yes, there is. The fact that ISO C does not support ftp "opens".
Moral of the story being find out what the question really is before
shooting off your mouth and/or foot.

Welcome to c.l.c, not read the FAQ and start apologizing.
 
D

Derk Gwen

# > Guess what, sunshine, it doesn't mean you can connect to local files, or
# > serial ports, or raw disk devices, or gps units, or anything else. Still
# > people somehow manage to do this with C.
#
# No, they do not use *ISO C*, the topic of this newsgroup, to do it! They
# must use non-standard, off-topic, not part of C, extensions!

So any program that opens a path string is not ISO C?

Sounds like a rather limitted language. How do you communicate with the
outside world in ISO C? Pauses of various lengths?

# > source available. There's no particular reason why a standard C library
# > could not (or could) accept something like
# > "ftp://saturn/development/quark.tcl".
#
# Yes, there is. The fact that ISO C does not support ftp "opens".

Doesn't mean an implementation cannot offer it, just means it doesn't
have to. Your desire to be nasty to anybody who upset your world
has included what purports to be your intellect.

Ta-ta, sunshine.
 
M

Mark A. Odell

# > Guess what, sunshine, it doesn't mean you can connect to local
files, or # > serial ports, or raw disk devices, or gps units, or
anything else. Still # > people somehow manage to do this with C.
#
# No, they do not use *ISO C*, the topic of this newsgroup, to do it!
They # must use non-standard, off-topic, not part of C, extensions!

So any program that opens a path string is not ISO C?

Sounds like a rather limitted language. How do you communicate with the
outside world in ISO C? Pauses of various lengths?

# > source available. There's no particular reason why a standard C
library # > could not (or could) accept something like
# > "ftp://saturn/development/quark.tcl".
#
# Yes, there is. The fact that ISO C does not support ftp "opens".

Doesn't mean an implementation cannot offer it, just means it doesn't
have to. Your desire to be nasty to anybody who upset your world
has included what purports to be your intellect.

When was I nasty?
Ta-ta, sunshine.

You don't see me calling you names. Keep it civil and please read the FAQ.
 
A

Alexander Bartolich

begin followup to Derk Gwen:
So any program that opens a path string is not ISO C?

You miss the subtle difference between the standard function "fopen"
and any interpretation of its first argument.
Sounds like a rather limitted language. How do you communicate with
the outside world in ISO C?

The standard is well suited for any kind of batch processing, i.e.
reading data from files, doing some operation, writing to files.
For a few decades this was all that computers were about...

To be more specific: fopen is part of the standard. Interpretation
of its first argument is not. The obvious solution is to either
use stdin/stdout or pass through elements of argv[].

To my knowledge file names of the classic 8+3 form can be used on
most systems. Starting with the concept of "directory" you are
sliding fast down a slippery slope.
The (harmless) relative path

data/logging/log.txt

that is understood by *nix and DOS/Windows/NT looks like this on VMS:

[.data.logging]log.txt

Obviously square brackets are forbidden in file names, and not so
obviously directory names cannot contain a dot, while file names
can.

Then there differences in case-sensitivity, handling of character
sets (there are still systems using EBCDIC out there), and even
very subtle differences like write-once files that cannot be opened
again.
Pauses of various lengths?

This is indeed very difficult. sleep is part of POSIX, not C.
 
D

Derk Gwen

# begin followup to Derk Gwen:
# > So any program that opens a path string is not ISO C?
#
# You miss the subtle difference between the standard function "fopen"
# and any interpretation of its first argument.

Actually I do.

# > Sounds like a rather limitted language. How do you communicate with
# > the outside world in ISO C?
#
# The standard is well suited for any kind of batch processing, i.e.
# reading data from files, doing some operation, writing to files.
# For a few decades this was all that computers were about...

But you don't. ISO C doesn't restrict itself to batch processing. Nor does it
require paths can be specified with the argv.

You're expecting that some kind of paths are meaningful but others are not.

All paths are meaningless without reference to the implementation. It is the
implementation that maps the path strings to data sets, and it is the
implementation that gives the string any meaning. If the implementation
and the entire process context gives a meaning to a string that is an
accessible data source on another machine, then it is.

So you can open a file from another machine in ISO C. It really depends on
the implementation.

# To my knowledge file names of the classic 8+3 form can be used on
# most systems. Starting with the concept of "directory" you are

Not on PDP-11 systems. Cyber 170 NOS only permits 7 characters maximum.

# > Pauses of various lengths?
#
# This is indeed very difficult. sleep is part of POSIX, not C.

So now you're claiming
{int i; for (i=0; i<MAXINT; i++) ;}
is not ISO C?

Ta ta to you as well.
 
M

Mark A. Odell

All paths are meaningless without reference to the implementation. It is
the implementation that maps the path strings to data sets, and it is
the implementation that gives the string any meaning. If the
implementation and the entire process context gives a meaning to a
string that is an accessible data source on another machine, then it is.

So you can open a file from another machine in ISO C. It really depends
on the implementation.

And thus implementation specific, e.g. off-topic here.
 
A

Arthur J. O'Dwyer

# begin followup to Derk Gwen:
# > So any program that opens a path string is not ISO C?
#

War of the Childishly-Broken News Clients: "begin" versus "#"!
Who will win? Tune in next week to find out!
Actually I do.

So at least we agree on one thing. The difference is simple:
Any ISO C program can use the 'fopen' function with no repercussions.
However, no ISO C program can pass any particular string to 'fopen'
and expect it to return a non-null value. For example, the line

fp = fopen("[.data.log]log.txt", "r");

might fail on a Unix system, while

fp = fopen("somemoredata.txt", "w");

might fail on another [hypothetical] machine. These are still
legal C programs. But they are not portable C programs, and they
are not strictly conforming C programs (as they rely on implementation-
defined behavior). The latter conclusion is not very important in
the big scheme of things; the former means that discussion of "what
does fopen do with such-and-such a filename?" is off-topic in
comp.lang.c.

But you don't.

:-D Antecedent, please?!
ISO C doesn't restrict itself to batch processing.

True. But ISO C, as Alexander says, *is* well suited for any
kind of batch processing.
Nor does it
require paths can be specified with the argv.

Whatever you meant to say, I'm sure it was correct yet irrelevant.
Remember that if you hardcode a pathname, you're killing portability.
And if you don't hardcode pathnames, then you have to get them from
somewhere -- and argv and stdin are your only sources of input that
are even semi-guaranteed to work cross-platform.
You're expecting that some kind of paths are meaningful but others are not.

All paths are meaningless without reference to the implementation. It is the
implementation that maps the path strings to data sets, and it is the
implementation that gives the string any meaning. If the implementation
and the entire process context gives a meaning to a string that is an
accessible data source on another machine, then it is.

So you can open a file from another machine in ISO C. It really depends on
the implementation.

You can launch nuclear warheads in ISO C, depending on the
implementation. That doesn't make warheads on-topic for comp.lang.c,
nor does it make warheads terribly portable (although we're getting
there, unfortunately).

So now you're claiming
{int i; for (i=0; i<MAXINT; i++) ;}
is not ISO C?

Of course it is! Depending on the value and type of MAXINT,
it's either an infinite loop, an invocation of implementation-defined
behavior, or a no-op. But is it relevant to the discussion at
hand?
[Moral: Optimizers are smarter than you think, and not all the
world's a Commodore 64.]


-Arthur
 
K

Kevin Goodsell

Derk said:
All paths are meaningless without reference to the implementation. It is the
implementation that maps the path strings to data sets, and it is the
implementation that gives the string any meaning. If the implementation
and the entire process context gives a meaning to a string that is an
accessible data source on another machine, then it is.

You're golden up to this point.
So you can open a file from another machine in ISO C. It really depends on
the implementation.

But this doesn't even make sense. Implementation-dependent things are,
by definition, not standard. The C abstract machine doesn't support the
concept of "another machine" in any way.
# To my knowledge file names of the classic 8+3 form can be used on
# most systems. Starting with the concept of "directory" you are

Not on PDP-11 systems. Cyber 170 NOS only permits 7 characters maximum.

# > Pauses of various lengths?
#
# This is indeed very difficult. sleep is part of POSIX, not C.

So now you're claiming
{int i; for (i=0; i<MAXINT; i++) ;}
is not ISO C?

Sure it is, but it's not required to pause or delay in any way.

-Kevin
 
K

Kevin Goodsell

Arthur said:
Of course it is! Depending on the value and type of MAXINT,
it's either an infinite loop, an invocation of implementation-defined
behavior, or a no-op. But is it relevant to the discussion at
hand?

Actually, overflowing a [signed] integer is undefined behavior, not
implementation-defined.

-Kevin
 
N

nrk

Kevin said:
Arthur said:
Of course it is! Depending on the value and type of MAXINT,
it's either an infinite loop, an invocation of implementation-defined
behavior, or a no-op. But is it relevant to the discussion at
hand?

Actually, overflowing a [signed] integer is undefined behavior, not
implementation-defined.

Yes, just what I wanted to point out. However, if MAXINT is a different
type integer type than int, the behavior could well be implementation
dependent, as illustrated by Chris Torek in his recent brilliant post on
unsigned short getting promoted to either signed int or unsigned int
depending on USHRT_MAX and INT_MAX.

-nrk.
 
J

Jan Engelhardt

# > I do all the time. Things like
# > FILE *f = fopen("/mount/saturn/quark.tcl","r");
#
# And sounds like your solution isn't very portable then, eh? I mean wonder
# if you're running Windows...

I'd try fopen("\\\\SATURN\\share\\quark.tcl"); :) (will probably NOT work)
 
N

nrk

Jan said:
I'd try fopen("\\\\SATURN\\share\\quark.tcl"); :) (will probably NOT
work)

Most definitely won't work, as you seem to be missing the mode argument in
the fopen call :)

-nrk.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top