By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,631 Members | 892 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,631 IT Pros & Developers. It's quick & easy.

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

P: n/a
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
Nov 14 '05 #1
Share this Question
Share on Google+
29 Replies


P: n/a
to**@kh.refer.org (Tola) wrote in
news:db**************************@posting.google.c om:
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.

--
- Mark ->
--
Nov 14 '05 #2

P: n/a
Tola <to**@kh.refer.org> spoke thus:
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.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #3

P: n/a
"Mark A. Odell" <no****@embeddedfw.com> wrote:
# to**@kh.refer.org (Tola) wrote in
# news:db**************************@posting.google.c om:
#
# > 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");

--
Derk Gwen http://derkgwen.250free.com/html/index.html
You hate people.
But I love gatherings. Isn't it ironic.
Nov 14 '05 #4

P: n/a
Derk Gwen <de******@HotPOP.com> wrote in
news:vu************@corp.supernews.com:
# > 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.

--
- Mark ->
--
Nov 14 '05 #5

P: n/a
"Mark A. Odell" <no****@embeddedfw.com> wrote:
# Derk Gwen <de******@HotPOP.com> wrote in
# news:vu************@corp.supernews.com:
#
# > # > 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.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
So....that would make Bethany part black?
Nov 14 '05 #6

P: n/a
Tola wrote:
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.

Nov 14 '05 #7

P: n/a
Derk Gwen <de******@HotPOP.com> wrote in
news:vu************@corp.supernews.com:
# > # > 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.

--
- Mark ->
--
Nov 14 '05 #8

P: n/a
"Mark A. Odell" <no****@embeddedfw.com> wrote in
news:Xn********************************@130.133.1. 4:

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

^^^
now

--
- Mark ->
--
Nov 14 '05 #9

P: n/a
# > 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.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
GERBILS
GERBILS
GERBILS
Nov 14 '05 #10

P: n/a
Derk Gwen <de******@HotPOP.com> wrote in
news:vu************@corp.supernews.com:
# > 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.

--
- Mark ->
--
Nov 14 '05 #11

P: n/a
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.

--
Für Google, Tux und GPL!
Nov 14 '05 #12

P: n/a
Alexander Bartolich <al*****************@gmx.at> wrote:
# 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.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
I think that's kinda of personal; I don't think I should answer that.
Nov 14 '05 #13

P: n/a
Derk Gwen <de******@HotPOP.com> wrote in
news:vu************@corp.supernews.com:

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.

--
- Mark ->
--
Nov 14 '05 #14

P: n/a

On Wed, 24 Dec 2003, Derk Gwen wrote:

Alexander Bartolich <al*****************@gmx.at> wrote:
# 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!
You miss the subtle difference between the standard function "fopen"
and any interpretation of its first argument.


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.

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.


:-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).

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?


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
Nov 14 '05 #15

P: n/a
Derk Gwen wrote:
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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Nov 14 '05 #16

P: n/a
Arthur J. O'Dwyer wrote:
On Wed, 24 Dec 2003, Derk Gwen wrote:

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?


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

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Nov 14 '05 #17

P: n/a
nrk
Kevin Goodsell wrote:
Arthur J. O'Dwyer wrote:
On Wed, 24 Dec 2003, Derk Gwen wrote:

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?


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.
-Kevin


Nov 14 '05 #18

P: n/a
># > 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)

--
Jan Engelhardt
Nov 14 '05 #19

P: n/a
nrk
Jan Engelhardt wrote:
# > 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)


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

-nrk.
Nov 14 '05 #20

P: n/a
"Mark A. Odell" <no****@embeddedfw.com> wrote in message news:<Xn********************************@130.133.1 .4>...
Derk Gwen <de******@HotPOP.com> wrote in
news:vu************@corp.supernews.com:
# > # > I found that I had to used open the file on the other machine?
# > #
# > # You can't do this with standard C.
# >
# > 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!


No reason why they should need to use extensions as such. They would
need to depend on implementation-defined functionality.
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".


It neither supports them nor doesn't support them, just the same as
for files on the local machine.

You can write a program to access remote files in Standard C as Derk
has shown. What you can't do in Standard C is know or control whether
or not the file is remote. You have to rely on implementation-defined
behaviour of the Standard C library, which may or may not implement
that functionality and may do so in different ways on different
environments.

You cannot write a 'strictly conforming program' in Standard C to
access a file on another machine. You can write a 'conforming
program' in Standard C without any extensions to access a file on
another machine; it would be non-portable and would require that the
implementation of the Standard C library provided the functionality.
Nov 14 '05 #21

P: n/a
On 24 Dec 2003 15:06:41 GMT, in comp.lang.c , Alexander Bartolich
<al*****************@gmx.at> wrote:
To my knowledge file names of the classic 8+3 form can be used on
most systems.


that assumption might well bite you on the *ss on either VMS or MVS.
Or MacOs. :-)

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #22

P: n/a
begin followup to Mark McIntyre:
On 24 Dec 2003 15:06:41 GMT, in comp.lang.c , Alexander Bartolich
<al*****************@gmx.at> wrote:


Did you ever wonder why "attribution line" is singular?
To my knowledge file names of the classic 8+3 form can be used on
most systems.


that assumption might well bite you on the *ss on either VMS or MVS.
Or MacOs. :-)


Is there any special reason why you did not see my example of VMS vs.
UNIX, directly following the two lines you quoted from my posting?

Anyway, a file name like "hello.txt" does work on MacOS.

--
Für Google, Tux und GPL!
Nov 14 '05 #23

P: n/a
In article <en********************************@4ax.com> Mark McIntyre <ma**********@spamcop.net> writes:
On 24 Dec 2003 15:06:41 GMT, in comp.lang.c , Alexander Bartolich
<al*****************@gmx.at> wrote:
To my knowledge file names of the classic 8+3 form can be used on
most systems.


that assumption might well bite you on the *ss on either VMS or MVS.
Or MacOs. :-)


Urm. MacOs allows 8+3 filenames. Unless one of the characters is a
colon. In Classic MacOs filenames are 31 characters, and you can
chose what you want except the colon.

BTW, in Unix filenames are a number of characters, and you can chose
what you want except the slash. The number of characters allowed
varies with the Unix version you use. (From 14 in Unix V5 to 1024
in some later versions.)

Moreover, the "extension" has *no* inherent meaning in either MacOs
or Unix. It is only some programs that require a specific "extension".
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 14 '05 #24

P: n/a
Derk Gwen wrote:
[snip]
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".


<supplementary>
FWIW, the IBM C-Set compiler accepts filename strings in the form of
"A.B.C.D" for access to the file named A.B.C.D
and
"DD:DDNAME" for access to the JCL DD named DDNAME, which will contain an
indirection to the /real/ name of the file (//DDNAME DD DSN=A.B.C.D )

The C standard doesn't define /how/ the filesystems are to interpret the name
given to fopen(), and a filename that's legal on one system may be completely
illegal on another.
</supplementary>

--
Lew Pitcher

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

Nov 14 '05 #25

P: n/a
On 25 Dec 2003 00:29:03 GMT, in comp.lang.c , Alexander Bartolich
<al*****************@gmx.at> wrote:
begin followup to Mark McIntyre:
On 24 Dec 2003 15:06:41 GMT, in comp.lang.c , Alexander Bartolich
<al*****************@gmx.at> wrote:


Did you ever wonder why "attribution line" is singular?


did you ever wonder why you're a plonker?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #26

P: n/a
On 25 Dec 2003 00:29:03 GMT, in comp.lang.c , Alexander Bartolich
<al*****************@gmx.at> wrote:

(I wrote)
that assumption might well bite you on the *ss on either VMS or MVS.
Or MacOs. :-)
Is there any special reason why you did not see my example of VMS vs.
UNIX, directly following the two lines you quoted from my posting?


Its more that I ignored it as it was incorrect. Plus lets remember I'm
agreeing with you.
Anyway, a file name like "hello.txt" does work on MacOS.


For some definition of "work". Its also true that "hello.txt;45" works
on MacOs, Unix and VMS, but it has rather different effects on the
three.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #27

P: n/a
On Thu, 25 Dec 2003 01:48:01 GMT, in comp.lang.c , "Dik T. Winter"
<Di********@cwi.nl> wrote:
In article <en********************************@4ax.com> Mark McIntyre <ma**********@spamcop.net> writes:
On 24 Dec 2003 15:06:41 GMT, in comp.lang.c , Alexander Bartolich
<al*****************@gmx.at> wrote:
To my knowledge file names of the classic 8+3 form can be used on
most systems.
that assumption might well bite you on the *ss on either VMS or MVS.
Or MacOs. :-)


Urm. MacOs allows 8+3 filenames.

(snip)Moreover, the "extension" has *no* inherent meaning in either MacOs
or Unix. It is only some programs that require a specific "extension".


thats my point.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #28

P: n/a
begin followup to Mark McIntyre:
did you ever wonder why you're a plonker?


http://cgi.peak.org/~jeremy/retort.cgi?British=plonker

In my wildest dreams I cannot imagine coming on par with
your apparent mastership on this line of thinking, Sir.

But given the neighborhood I consider it a noble choice.
Surrounded by balls, in direct opposition to an asshole.

--
Für Google, Tux und GPL!
Nov 14 '05 #29

P: n/a
On 26 Dec 2003 01:54:06 GMT, in comp.lang.c , Alexander Bartolich
<al*****************@gmx.at> wrote:
begin followup to Mark McIntyre:
did you ever wonder why you're a plonker?
http://cgi.peak.org/~jeremy/retort.cgi?British=plonker


most excellent that you found a dictionary definition. I was however
commenting on the fact that I've never heard anyone call it a singilar
attribution line before, and that you persist in posting bad english,
despite having enough grasp of the language to write the below.
In my wildest dreams I cannot imagine coming on par with
your apparent mastership on this line of thinking, Sir.

But given the neighborhood I consider it a noble choice.
Surrounded by balls, in direct opposition to an asshole.


Thats a big swinging d*ck, which you certainly aint.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #30

This discussion thread is closed

Replies have been disabled for this discussion.