How to write to a file including full directory in C under Unix?

[Hongyu]

Dear all:

I am trying to write to a file with full directory name and file name
specified (./outdir/mytestout.txt where . is the current directory)
in
C programming language and under Unix, but got errors of Failed to
open file ./outdir/mytestout.txt. Below is the code:
#include <stdio.h>
int main(void)
{
FILE *fp;
char fname[30];
char pathname[30];
strcpy(fname,"./outdir/mytestout.txt");
fp=fopen(fname, "w");
if (fp == NULL)
{
printf("Failed to open file %s\n", fname);
}
else
{
fprintf(fp, "This is just a test only");
}
fclose(fp);
return 0;

}
I also try to write filename and directory with ,".\outdir
\mytestout.txt", or ,".//outdir//mytestout.txt" or ",".\\outdir\
\mytestout.txt", or even ,".///outdir///mytestout.txt" etc, and I
also
tried to specify the whole directory with the current directory .
(dot) replaced by the real directory name, but all failed. I searched
on the internet and only found one relevant that said to specify
filename with full path, but how to specify full path in C under
Unix?
Please help me.

Thanks for the help in advance.
Hongyu

[Chris Torek]

In article <fc**********************************@k7g2000hsd.g ooglegroups.com>
Hongyu <ho*******@yahoo.comwrote:

if(mkdir(fpath,S_IRWXU | S_IRWXG | S_IROTH | S_IXOTH) != 0)

This is off-topic here (the discussion is on-topic in comp.unix.programmer)
but it is worth mentioning that these are almost always the wrong
permission bits. (Almost always, either 0700 or 0777 are the
correct set of bits, because of the thing called the "umask". For
more complex applications, the permissions should be configurable.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: gmail (figure it out) http://web.torek.net/torek/index.html

[James Kuyper]

CBFalconer wrote:
....

You don't seem to pick up too quickly. No, the simple thing is for
the user to have a suitable directory structure in existance before
running the program (assuming the system has directories). This
totally removes any urge to have/use a mkdir function.

Why should someone who's willing to restrict the portability of his
program to POSIX systems (not exactly a severe limitation - I haven't
written a program for a non-POSIX system in the last 14 years) forgo the
option of controlling directory creation from within his program? I
haven't needed this capability - I work in an environment where our
delivered code is prohibited from calling mkdir() - but I can easily
imagine contexts where it would be entirely reasonable to use it.

[Hongyu]

On Aug 12, 8:15*pm, Ben Bacarisse <[e-mail]:

Hongyu <[e-mail]:

<snip>

... For some unknown reasons, my questioning post was not
appeared in the unix.programmer group discussion board.

For your information: one question did appear in comp.unix.programmer
and got three replies and a clarification. *You asked a specific
question that got answered. *A more open question might have got
better answers.

--
Ben.

Thanks. I will check there too to see what they said.

[Kenny McCormack]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
....

>I'd love to see CBF try to write code in the real world...

Customer: I see the code we contracted you for is finished.
CBF: Yes sir. It's 100% portable.
Cust: It doesn't meet our specification, though.
CBF: No sir, that would have meant using a POSIX function.
Cust: But the spec is what we wanted, damn it.
CBF: This code will run inside your portable travel radio too! It's
portable!
Cust: But it doesn't do what we wanted.
CBF: That's the price you pay for portability.
Cust: But having the code do what I wanted is more important to me than
portability.
CBF: You're mistaken. There's nothing more important than portability.
Cust: ?*#!
CBF: Why don't you write a shell script to do half the stuff my program
was meant to do, and make sure you run it before my program? After all,
my program needs to be in ISO C or else the ISO Standard makes no
guarantees about it.
Cust: ?*#?*#?*#?*#?*#!!!!!?*#!

Excellent! Absolutely dead-on.

I'm imagining this scene playing out, and the really funny thing is the
realization that it's just not a stretch at all.

To go one step further, most of us know that "the customer is always
right" (well, at least I hope that most of us do - I would imagine more
than one clc reg thinks otherwise), but the clc regs need to realize
that, in a very real sense, the student is always right, too. I.e., the
student (in clc, that means the newbie questioner) knows what he needs
to know, and isn't pleased when the clc reg tells him otherwise (that
is, redefines his question into something that the clc reg can answer).

[Hongyu]

On Aug 13, 4:20*am, Chris Torek <[e-mail]:

In article <[e-mail]>

Hongyu *<[e-mail]:

* * *if(mkdir(fpath,S_IRWXU | S_IRWXG | S_IROTH | S_IXOTH) != 0)

This is off-topic here (the discussion is on-topic in comp.unix.programmer)
but it is worth mentioning that these are almost always the wrong
permission bits. *(Almost always, either 0700 or 0777 are the
correct set of bits, because of the thing called the "umask". *For
more complex applications, the permissions should be configurable.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) *[phone]
email: gmail (figure it out) * * *http://web.torek.net/torek/index.html

Thanks and good to know this.

[Dik T. Winter]

In article <g7***********@pc-news.cogsci.ed.ac.ukri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <K5********@cwi.nl>, Dik T. Winter <Di********@cwi.nlwrote:

Very unlikely - do you know of any operating system where that is
true?

Original System V Unix.

Ok, let's say "any current operating system".

I do not know. But your other remark was clearly wrong:

And the system() version is just as unportable as the mkdir()
version, because you have to know what the operating system's command
for creating directories is. If you can find that out, you can find
out what the function is.

You may be able to find out what the function is but not be able to use
it in your program.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Joachim Schmitz]

Keith Thompson wrote:

There's nothing in the standard that says
an implementation *can't* create a directory as a side effect of
creating a file.

(I'm not aware of any actual implementation that does this.)

I am. NonStop Kernel.

Bye, Jojo

[CBFalconer]

James Kuyper wrote:

CBFalconer wrote:
...

>You don't seem to pick up too quickly. No, the simple thing is for
the user to have a suitable directory structure in existance before
running the program (assuming the system has directories). This
totally removes any urge to have/use a mkdir function.

Why should someone who's willing to restrict the portability of his
program to POSIX systems (not exactly a severe limitation - I haven't
written a program for a non-POSIX system in the last 14 years) forgo the
option of controlling directory creation from within his program? I
haven't needed this capability - I work in an environment where our
delivered code is prohibited from calling mkdir() - but I can easily
imagine contexts where it would be entirely reasonable to use it.

Then use it. It may be well to isolate these things to a
particular file, thus easing future porting.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Walter Roberson]

In article <g7**********@news.xmission.com>,
Kenny McCormack <ga*****@xmission.xmission.comwrote:

>but the clc regs need to realize
that, in a very real sense, the student is always right, too. I.e., the
student (in clc, that means the newbie questioner) knows what he needs
to know, and isn't pleased when the clc reg tells him otherwise (that
is, redefines his question into something that the clc reg can answer).

I have been posting in technical groups for many years, and my
experience is that -most- of the time, "the student" does NOT know
what he or she needs to know; a lot of time ends up spent in questions
of clarification, and in showing why the "student"'s conceptions
of the scope of the problem are not adequate for the situations.

Over the last year or so in particular, I have noticed an increasing
trend of "students" refusing to learn anything beyond what they -think-
will solve the problem, and an even larger increasing trend of "students"
refusing to learn anything at all and instead expecting that someone
will "urgently" send them complete source code for what were structurally
intended to be final-year projects -- or even masters projects in some
cases. Complete code to solve problems that decades of research have
gone into, and they often haven't even bothered to google to find
prior work on the subject. :(

--
"When we all think alike no one is thinking very much."
-- Walter Lippmann

[Walter Roberson]

In article <FDzok.704$EL2.457@trnddc01>,
James Kuyper <ja*********@verizon.netwrote:

>Why should someone who's willing to restrict the portability of his
program to POSIX systems (not exactly a severe limitation - I haven't
written a program for a non-POSIX system in the last 14 years)

Most versions of MS Windows are not POSIX. And I'm not just speaking
historically: there is no POSIX available for XP Home, Vista Starter,
Vista Home, Vista Home Premium, or Vista Business.
--
"I was very young in those days, but I was also rather dim."
-- Christopher Priest

[jameskuyper]

Walter Roberson wrote:

In article <FDzok.704$EL2.457@trnddc01>,
James Kuyper <ja*********@verizon.netwrote:

Why should someone who's willing to restrict the portability of his
program to POSIX systems (not exactly a severe limitation - I haven't
written a program for a non-POSIX system in the last 14 years)

Most versions of MS Windows are not POSIX. And I'm not just speaking
historically: there is no POSIX available for XP Home, Vista Starter,
Vista Home, Vista Home Premium, or Vista Business.

Well, I've never had to write a program for any of those platforms.
The last time I had to write a Windows program was for Windows 3.1,
and as I said, that was more than 14 years ago. Sure, there's a huge
market for Windows software, but the market for POSIX software, while
admittedly smaller, isn't exactly tiny.

As a matter of fact, I think my C code probably can be ported to
Windows machines without too much effort, though I haven't tried it -
but I don't know where I could find a machine to try it on. The
programs I've been working on over these last 14 years do not
generally rely upon POSIX facilities for anything but the make files.
The main constraint on their portability is three third-party
libraries; anywhere those libraries can be installed, my C code can be
compiled, and should execute correctly. All three libraries can be
installed on Windows XP machines using MSVC++ as the C compiler. As
far as I know, installation on Vista platforms hasn't been tested yet;
apparently it isn't a high priority for users of those libraries.

[santosh]

Kenny McCormack wrote:

but the clc regs need to realize
that, in a very real sense, the student is always right, too. I.e.,
the student (in clc, that means the newbie questioner) knows what he
needs to know,

No. This is wrong. Very often newbies don't know of possible better
solutions to their problems.

[Kenny McCormack]

In article <g8**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:

>Kenny McCormack wrote:

>but the clc regs need to realize
that, in a very real sense, the student is always right, too. I.e.,
the student (in clc, that means the newbie questioner) knows what he
needs to know,

No. This is wrong. Very often newbies don't know of possible better
solutions to their problems.

heh - santosh thinks I'm wrong. I guess that must make it so (NOT).

It appears you don't get what I mean when I say "The <Xis always right".

Think about it - it will come to you.

[Richard Bos]

CBFalconer <cb********@yahoo.comwrote:

Keith Thompson wrote:

No, it does not *always* reduce your portability.

Or do you claim that
system("mkdir foo");
is more portable than
mkdir("foo", 0777);

The OP needs to create a directory. That's a specific reason to
use POSIX functions.

That is covered above by 'specific reasons'. However the program
without any mkdir will compile and execute on more systems than the
program with mkdir.

That's what you think. For mkdir, you may even be correct, because that
command happens to be called the same thing on MS-DOS as under Unix. Now
try the same thing with "dir".

That's increased portability.

Not in practice, it isn't.

Richard

[Bill Reid]

Sheesh, just looked at this old post, somebody musta defecated
in his scrambled eggs that morning...

Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:g7**********@canopus.cc.umanitoba.ca...

In article <69*********************@bgtnsc04-news.ops.worldnet.att.net>,
Bill Reid <ho********@happyhealthy.netwrote:

What you're really looking for is something called "POSIX",
which was initially developed based on Unix, but could potentially
apply to any computer system, and as a matter of fact is
included in the "C" compilers for many different types of
systems.

POSIX is included in the C compilers for "many different types of
systems"?? Would I be likely to recognize the names of any of
those systems??

Sure. Think "Evil Empire"...

POSIX is the "Portable Operating System Interface". A C compiler
does not implement operating system interfaces: to do so would
take them out of the realm of being *operating system* interfaces
into the realm of being *application* entities.

Come on, you know what I meant, that either totally-conforming or
"POSIX-like" C function calls are included in some C compilers. Mine
does, but I dare not breathe the name of the "system" for fear that
Lord Gater will use his mind to choke me...

Sometimes C compilers bundle in, as extensions, header files useful
with POSIX -- but the operating system behaviours are left to
the operating system to implement, not delivered by the C compiler.

Hmmmmm, "header files", hmmmmm...all I know is that I can call
a function that does what the OP wanted to do (of course, what the OP
wanted to do is always forgotten in these "discussions") in my compiler,
because it includes a bunch of functions that have either identical
or similar signatures and usage as are specified by POSIX...

Are you aware of the following, Bill?

http://support.microsoft.com/kb/308259

POSIX and OS/2 are not supported in Windows XP or in Windows Server 2003

OMG!!! Who woulda thunk it!!?!!!

The truly hilarious thing is that if "Windows" "supported" POSIX, then
it could be legally called "Unix"!!!! And even more hilariously, "Windows"
may be more POSIX compliant than "Linux"!!!!

Overview
Utilities and SDK for UNIX-Based Applications is an add-on to the
Subsystem for UNIX-Based Applications (referred to as SUA, hence
forth) component that shipped in Microsoft Windows Vista /
Windows Server 2008 RTM. [...]

System Requirements

* Supported Operating Systems: Windows Server 2008; Windows
Vista Enterprise; Windows Vista Enterprise 64-bit edition;
Windows Vista Service Pack 1; Windows Vista Ultimate; Windows
Vista Ultimate 64-bit edition

If it was just a matter of having the right C compiler, then why
the restrictions on the supported editions? Why no support for
Vista Starter, Vista Home, Vista Home Premium, or Vista Business ?

It must be some sort of illegal monopolistic strategy, of course.

Look, you're just being argumentative for no apparent reason.
If you want to make a directory in a C program, you're gonna have
to use an "extension" of some sort. As has been discussed to
death, I think it might behoove you to use an extension that
conforms to POSIX as much as possible, for the sake of the
sacred "portability" at the source level, but if you want to use
direct calls to a system designed by the guy who killed Obi
Wan-Kenobi to each his own...

---
William Ernest Reid

[Lew Pitcher]

On October 12, 2008 12:50, in comp.lang.c, Bill Reid
(ho********@happyhealthy.net) wrote something completely off-topic for
comp.lang.c:
[snip]

> POSIX and OS/2 are not supported in Windows XP or in Windows Server
2003

OMG!!! Who woulda thunk it!!?!!!

The truly hilarious thing is that if "Windows" "supported" POSIX,

What do you mean by "if"? Haven't you heard about Windows SFU (Services for
Unix)?

then it could be legally called "Unix"!!!!

Not without certification from the Open Group.

But, POSIX support is not Unix support. POSIX compliance simply gets
Microsoft past the US GAO requirement that all computer systems purchased
by US Federal agencies /must/ support POSIX. (Does that requirement still
exist?)

And even more hilariously, "Windows" may be more POSIX compliant
than "Linux"!!!!

Don't know. Don't care. Most Windows programmers do not write POSIX
applications for Windows. It matters not if Microsoft supplies a POSIX
environment for Windows, when no one uses it.

In practical terms, Linux apps are more POSIX-compliant than Windows apps,
and (unlike Windows), Linux /comes/ with POSIX compatability.
--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------