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

[Keith Thompson]

Unless you have specific reasons for needing to use POSIX
functions, you should stick to the standard C functions. Most of
the time the standard functions will be adequate, and in some cases
the results will be more efficient. Using things outside the C
standard always reduces your portability.

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.

 

[CBFalconer]

.... snip ...


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 increased portability.

 

[s0suk3]

... snip ...





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 increased portability.

....by your definition of "portability." IMO, it's better to have the
program *not* compile and tell me that something doesn't work, instead
of having it compile and shipping something that will produce an
utterly and completely useless result when executed.

Sebastian

 

[Ian Collins]

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 increased portability.

Portability is inversely proportional to usability...

 

[CBFalconer]

...by your definition of "portability." IMO, it's better to have
the program *not* compile and tell me that something doesn't work,
instead of having it compile and shipping something that will
produce an utterly and completely useless result when executed.

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.

 

[s0suk3]

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.

Oh, I thought you were saying yes to what Keith Thompson asked
(whether system("mkdir foo") was more portable than mkdir("foo",
0777)).

But requiring the user to create the directory him/herself just
because the program can't do it portably isn't something acceptable
out there in the "real world."

Sebastian

 

[Antoninus Twink]

But requiring the user to create the directory him/herself just
because the program can't do it portably isn't something acceptable
out there in the "real world."

As you're discovering, "Chuck" neither knows nor cares about the "real
world". And why would he? It all seems so far away when you're sitting
amongst a group of incontinent crones in an old folks home.

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: ?*#?*#?*#?*#?*#!!!!!?*#!

 

[Chris Torek]

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

 

[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]

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.

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

 

[Kenny McCormack]

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]

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

Thanks and good to know this.

 

[Dik T. Winter]

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

 

[Joachim Schmitz]

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]

CBFalconer wrote:
...

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.

 

[Walter Roberson]

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.

 

[Walter Roberson]

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.

 

[jameskuyper]

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]

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]

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 <X> is always right".

Think about it - it will come to you.