mkdir() won't do it for me

[MikeC]

Good People,

I'm writing a backup utility that uses a chdir() to go into the source
directory (in which the files reside that I want to back up), so I don't
want to use chdir() to get into the target directory (where the backup
copies will be kept, on another drive). I can successfully test whether the
target directory exists or not using findfirst(), but if it doesn't, I
wanted to create it using mkdir(), but it doesn't like the path I'm using.

mkdir("newdirectory", S_IWUSR); // this works OK, and appends newdirectory
to the current path

mkdir("F:\\myfolder\\dumps", S_IWUSR); // does not work.

Incidentally, I use DJGPP, and S_IWUSR apparently makes the directory
read/write. If it is omitted, the directory is read-only.

I know that I could chdir() to the other disk then build up the path bit by
bit, but is there a more streamlined way?

Many thanks,

MikeC

--
Mental decryption required to bamboozle spam robots:

mike_best$ntlworld*com
$ = @
* = dot

[Richard Heathfield]

MikeC said:

Good People,

I'm writing a backup utility that uses a chdir() to go into the source
directory (in which the files reside that I want to back up), so I don't
want to use chdir() to get into the target directory (where the backup
copies will be kept, on another drive). I can successfully test whether
the target directory exists or not using findfirst(), but if it doesn't, I
wanted to create it using mkdir(), but it doesn't like the path I'm using.

mkdir("newdirectory", S_IWUSR); // this works OK, and appends
newdirectory to the current path

mkdir("F:\\myfolder\\dumps", S_IWUSR); // does not work.

Strange as it may sound, this isn't actually a question about C. Rather,
it's a question about your operating system. mkdir()'s behaviour is
governed not by the C language definition (which doesn't even mention it)
but by your implementation. So you'll want to be asking about it in a
Windows or MS-DOS programming group.

Just a thought, though - does myfolder exist? If not, that could be your
problem. You might not be able to create \a\b without first creating \a.

Anyway, I recommend comp.os.msdos.programmer or
comp.os.ms-windows.programmer.win32 as your next port of call.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Bill Reid]

Richard Heathfield <in*****@invalid.invalidwrote in message
news:7o******************************@bt.com...

MikeC said:

I'm writing a backup utility that uses a chdir() to go into the source
directory (in which the files reside that I want to back up), so I don't
want to use chdir() to get into the target directory (where the backup
copies will be kept, on another drive).

You don't need to use chdir() for either directory, riiiiiiiiight?

I can successfully test whether
the target directory exists or not using findfirst(), but if it doesn't,

I

wanted to create it using mkdir(), but it doesn't like the path I'm

using.

findfirst() or opendir()...

mkdir("newdirectory", S_IWUSR); // this works OK, and appends
newdirectory to the current path

mkdir("F:\\myfolder\\dumps", S_IWUSR); // does not work.

Strange as it may sound, this isn't actually a question about C. Rather,
it's a question about your operating system. mkdir()'s behaviour is
governed not by the C language definition (which doesn't even mention it)
but by your implementation. So you'll want to be asking about it in a
Windows or MS-DOS programming group.

Just a thought, though - does myfolder exist? If not, that could be your
problem. You might not be able to create \a\b without first creating \a.

Anyway, I recommend comp.os.msdos.programmer or
comp.os.ms-windows.programmer.win32 as your next port of call.

Ah, horsefeathers...

I think this might help (I think this is all at least POSIX-compliant,
close enough for real-world work on non-embedded systems):

#include <stdio.h /* required to breathe */
#include <stdlib.h /* required to breathe for non-Unix */
#include <string.h /* required to manipulate text */
#include <dir.h /* required to make directories */
#include <dirent.h /* required to scan data directories */

DIR *directory; /* directory pointer */
char path_directories[512];

unsigned directory_exists(char *target_directory) {

/* try to open the directory, return FALSE on failure */
if((directory=opendir(target_directory))==NULL)
return FALSE;

/* if we could open it, close it and return TRUE */
else {
closedir(directory);
return TRUE;
}
}

/* recursively creates all the needed file path directories */
unsigned make_file_path_dirs(char *file_path) {
unsigned dir_num=count_file_path_dirs(file_path);
unsigned dirs_needed=0,needed_dir=0,dirs_made=0;
char *search_ptr;

strcpy(path_directories,file_path);

while((search_ptr=strrchr(path_directories,'\\'))! =NULL) {

*search_ptr=NUL;

if(!directory_exists(path_directories)) dirs_needed++;

else {
needed_dir=dir_num;
break;
}

dir_num--;
}

if(dirs_needed>0) {

printf("\nFile path requires %i directories",dirs_needed);
printf("\nMaking directories: ");

strcpy(path_directories,file_path);
search_ptr=path_directories;

dir_num=0;
while((search_ptr=strchr(search_ptr,'\\'))!=NULL) {

if(dir_num==needed_dir) {

*search_ptr=NUL;

printf("\n %s",path_directories);

if(mkdir(path_directories)!=SUCCESS) {
printf("\n FAILED TO MAKE DIRECTORY!!!");
break;
}

*search_ptr='\\';
dirs_made++;
needed_dir++;
}

search_ptr++;
dir_num++;
}

if(dirs_made<dirs_needed) {

printf("\nCouldn't make all the required directories");
dirs_made=0;
}
}

else printf("\nNo directories required");

return dirs_made;
}

Anytime you want to write to a full file path or just make sure a
directory path exists, call make_file_path_dirs(char *file_path),
and bingo!, you are assured that your file/directory path is
copacetic...

---
William Ernest Reid

[CBFalconer]

MikeC wrote:

>

.... snip ...

>
mkdir("newdirectory", S_IWUSR); // this works OK, and appends
newdirectory to the current path

mkdir("F:\\myfolder\\dumps", S_IWUSR); // does not work.

Incidentally, I use DJGPP, and S_IWUSR apparently makes the
directory read/write. If it is omitted, the directory is
read-only.

I know that I could chdir() to the other disk then build up the
path bit by bit, but is there a more streamlined way?

Yes, by asking on comp.os.msdos.djgpp, where this is topical, and
you are likely to find someone who knows the appropriate answer.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[CBFalconer]

Bill Reid wrote:

>

.... snip ...

>
I think this might help (I think this is all at least POSIX-compliant,
close enough for real-world work on non-embedded systems):

It is not helpful to post off-topic answers to off-topic queries,
when a simple redirection to an appropriate newsgroup will get the
OP the data he needs. It also encourages the asking of such
off-topic questions here.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Richard Heathfield]

Bill Reid said:

>
Richard Heathfield <in*****@invalid.invalidwrote in message
news:7o******************************@bt.com...

<snip>

>Anyway, I recommend comp.os.msdos.programmer or
comp.os.ms-windows.programmer.win32 as your next port of call.

Ah, horsefeathers...

....would at least have the merit of being portable.

>
I think this might help

<system-specific solution snipped>

Unlikely, since he's not using a POSIX-conforming implementation AFAIK.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[MikeC]

Folks,

I'm sorry if I asked this in the wrong group, and I agree with the sentiment
that off-group articles are not helpful - when looking at technical groups,
I have even seen such off-beat topics as celebrity sex films - not helpful
at all!!

However, that said, I really appreciate Richard Heathfield's gentlemanly
suggestion that my question would be better suited to another forum (DJGPP
in this case), and Bill Reid's offer of a considered solution to my problem.
I'll give it a go later today, Bill.

Thanks again to all,

MikeC.

"MikeC" <My********@end.of.postwrote in message
news:HS******************@newsfe7-gui.ntli.net...

Good People,

I'm writing a backup utility that uses a chdir() to go into the source
directory (in which the files reside that I want to back up), so I don't
want to use chdir() to get into the target directory (where the backup
copies will be kept, on another drive). I can successfully test whether
the target directory exists or not using findfirst(), but if it doesn't, I
wanted to create it using mkdir(), but it doesn't like the path I'm using.

mkdir("newdirectory", S_IWUSR); // this works OK, and appends
newdirectory to the current path

mkdir("F:\\myfolder\\dumps", S_IWUSR); // does not work.

Incidentally, I use DJGPP, and S_IWUSR apparently makes the directory
read/write. If it is omitted, the directory is read-only.

I know that I could chdir() to the other disk then build up the path bit
by bit, but is there a more streamlined way?

Many thanks,

MikeC

--
Mental decryption required to bamboozle spam robots:

mike_best$ntlworld*com
$ = @
* = dot

[Kenny McCormack]

In article <45***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>Bill Reid wrote:

>>

... snip ...

>>
I think this might help (I think this is all at least POSIX-compliant,
close enough for real-world work on non-embedded systems):

It is not helpful to post off-topic answers to off-topic queries,
when a simple redirection to an appropriate newsgroup will get the
OP the data he needs. It also encourages the asking of such
off-topic questions here.

You people need to get a grip.

[Bill Reid]

Kenny McCormack <ga*****@xmission.xmission.comwrote in message
news:ej**********@news.xmission.com...

In article <45***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

Bill Reid wrote:

>

... snip ...

>
I think this might help (I think this is all at least POSIX-compliant,
close enough for real-world work on non-embedded systems):

It is not helpful to post off-topic answers to off-topic queries,
when a simple redirection to an appropriate newsgroup will get the
OP the data he needs. It also encourages the asking of such
off-topic questions here.

You people need to get a grip.

Or loosen it!

---
William Ernest Reid

[Bill Reid]

Richard Heathfield <in*****@invalid.invalidwrote in message
news:wt******************************@bt.com...

Bill Reid said:

Richard Heathfield <in*****@invalid.invalidwrote in message
news:7o******************************@bt.com...

<snip>

Anyway, I recommend comp.os.msdos.programmer or
comp.os.ms-windows.programmer.win32 as your next port of call.

Ah, horsefeathers...

...would at least have the merit of being portable.

Please try comp.horsefeathers...

I think this might help

<system-specific solution snipped>

Can't say for sure right now just how many systems the "solution"
would work on, but I'm pretty sure it's more than one (and probably
more than 50, admittedly with some tweaks), therefore is not
"system-specific", riiiiiiiiiiight?

Unlikely, since he's not using a POSIX-conforming implementation AFAIK.

Can't say for sure right now, but I doubt there's any such thing as
a "POSIX-conforming implementation" in the anal-restrictive sense
anywhere on the face of the planet. Of course, that is also true of
an "ANSI C-conforming" implementation...

I actually have a hard-copy bound version of the POSIX standard
here, but only because I fished it out of the trash of "Unix house" I
worked at...the problem with the ANSI C standard appears to be
that even fewer people ever bothered to buy it in the first place, only
to throw it away as useless junk two months later...

When somebody posts a question with the term "mkdir()" in the
subject, as a PRACTICAL matter the actual answer is not actually
STRICTLY "POSIX-compliant", but, let us say, "derived from
Unix/POSIX and largely a 'work-alike' and most importantly
WIDELY USED ON MANY DIFFERENT 'SYSTEMS'
AND 'IMPLEMENTATIONS'".

Try to think logically: "mkdir()" is NOT specific to "DJGPP" (whatever
the holy god-forsaken hell that is). Interestingly enough, the SPECIFIC
"implementation" of "mkdir()" he mentions is closer to "POSIX" and
"Unix" than what I use to develop for Windows, because it takes
a "permissions" argument, though decidedly NOT the "Unix" argument...

So is "mkdir()" a "DJGPP" topic, a "C" topic, a "MS-DOS" topic,
a "Windows" topic, a "Linux" topic, a "Unix" topic, or what? And when
you figure that out, please tell me if a "socket" is a "Unix" topic
(as is so often asserted here) or a "Microsoft" topic (well, "winsock"
is)...

As a practical matter, the way people work who actually program
in the "C programming language" is to compile "foreign" code, count
the errors, check their documentation for missing functions/headers,
and make INTELLIGENT decisions from there...but of course,
that's all covered in alt.real-life...

---
William Ernest Reid

[Kenny McCormack]

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

>
Kenny McCormack <ga*****@xmission.xmission.comwrote in message
news:ej**********@news.xmission.com...

>In article <45***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>Bill Reid wrote:

... snip ...

I think this might help (I think this is all at least POSIX-compliant,
close enough for real-world work on non-embedded systems):

It is not helpful to post off-topic answers to off-topic queries,
when a simple redirection to an appropriate newsgroup will get the
OP the data he needs. It also encourages the asking of such
off-topic questions here.

You people need to get a grip.

Or loosen it!

Well put.

(Of course, they won't get it)

[Flash Gordon]

Bill Reid wrote:

Richard Heathfield <in*****@invalid.invalidwrote in message
news:wt******************************@bt.com...

>Bill Reid said:

>>Richard Heathfield <in*****@invalid.invalidwrote in message
news:7o******************************@bt.com.. .

<snip>

>>>Anyway, I recommend comp.os.msdos.programmer or
comp.os.ms-windows.programmer.win32 as your next port of call.

Ah, horsefeathers...

...would at least have the merit of being portable.

Please try comp.horsefeathers...

>>I think this might help

<system-specific solution snipped>

Can't say for sure right now just how many systems the "solution"
would work on, but I'm pretty sure it's more than one (and probably
more than 50, admittedly with some tweaks), therefore is not
"system-specific", riiiiiiiiiiight?

It does not work on all the systems I have programmed so it certainly is
specific to a selection of systems not general to all systems.

>Unlikely, since he's not using a POSIX-conforming implementation AFAIK.

Can't say for sure right now, but I doubt there's any such thing as
a "POSIX-conforming implementation" in the anal-restrictive sense
anywhere on the face of the planet. Of course, that is also true of
an "ANSI C-conforming" implementation...

I've no idea how many implementations claim POSIX compliance, nor how
many actually achieve it (modulo bugs). However, I do know that many
compilers, when correctly prodded, are compliant to a version of the ISO
C standard apart from the odd bug.

<snip>

I actually have a hard-copy bound version of the POSIX standard
here, but only because I fished it out of the trash of "Unix house" I
worked at...the problem with the ANSI C standard appears to be
that even fewer people ever bothered to buy it in the first place, only
to throw it away as useless junk two months later...

Well, I find reference to a (draft of) the C standard useful sometimes.

When somebody posts a question with the term "mkdir()" in the
subject, as a PRACTICAL matter the actual answer is not actually
STRICTLY "POSIX-compliant", but, let us say, "derived from
Unix/POSIX and largely a 'work-alike' and most importantly
WIDELY USED ON MANY DIFFERENT 'SYSTEMS'
AND 'IMPLEMENTATIONS'".

Even if the mkdir takes a different number of arguments or they mean
completely different things?

Try to think logically: "mkdir()" is NOT specific to "DJGPP" (whatever
the holy god-forsaken hell that is). Interestingly enough, the SPECIFIC
"implementation" of "mkdir()" he mentions is closer to "POSIX" and
"Unix" than what I use to develop for Windows, because it takes
a "permissions" argument, though decidedly NOT the "Unix" argument...

If, as you claim in this post it is neither the same as the Unix version
nor the Windows version then very probably it *is* specific to DJPP.

So is "mkdir()" a "DJGPP" topic, a "C" topic, a "MS-DOS" topic,
a "Windows" topic, a "Linux" topic, a "Unix" topic, or what?

Depends on the version of mkdir being used. Which is one reason why it
is not topical here.

And when
you figure that out, please tell me if a "socket" is a "Unix" topic
(as is so often asserted here) or a "Microsoft" topic (well, "winsock"
is)...

Actually, it could sensibly be argued that it is a networking topic and
there are networking groups.

As a practical matter, the way people work who actually program
in the "C programming language" is to compile "foreign" code, count
the errors, check their documentation for missing functions/headers,
and make INTELLIGENT decisions from there...but of course,
that's all covered in alt.real-life...

More sensible people review the code to find out what areas are standard
and will not need changing and what areas are system specific (even if
specific to a number of systems) and this group will help with that. I
consider questions like, "is such and such standard?" to be topical
here. I also consider the follow up questions of, "well, is there an
alternative that is standard, and if so what is it?" to be topical.

Also, it is possible to write vast amounts of code that is completely
standard C although you often also need a small amount of non-standard
(or different standard) code, and here we deal with that vast quantity
of standard code. I just wish that more people stuck to standard C where
extensions are not needed, it would make my life a lot easier.
--
Flash Gordon

[Chris Torek]

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

>I think this might help (I think this is all at least POSIX-compliant,
close enough for real-world work on non-embedded systems):

No, because (at least):

while((search_ptr=strrchr(path_directories,'\\'))! =NULL) {

.... the POSIX path-separator character is slash ('/'), not backslash.

(There may be other problems, but this was the one that sprang right
out.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Bill Reid]

Chris Torek <no****@torek.netwrote in message
news:ej********@news4.newsguy.com...

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

I think this might help (I think this is all at least POSIX-compliant,
close enough for real-world work on non-embedded systems):

No, because (at least):

while((search_ptr=strrchr(path_directories,'\\'))! =NULL) {

... the POSIX path-separator character is slash ('/'), not backslash.

Absolutely correct, but I believe that you can use '/' for what the
OP was working on and have it be portable to a very large majority
of all the general-purpose computer systems manufactured after
1990 (unfortunately, probably not the one I'm typing this on without
another "tweak")...

I did follow up and note that my definition of "POSIX-compliant"
isn't so much strict compatibility but rather just "sort of looks like
POSIX"...I don't know how that could possibly cause confusion...

(There may be other problems, but this was the one that sprang right
out.)

Also I noted the difference in the number of arguments to "mkdir()",
and the specifics of the "permissions" argument...other than that, and
probably a bunch of other stuff, it's totally POSIX-compliant! Who
knew MS-DOS was actually a Unix system!

---
William Ernest Reid

[Bill Reid]

Flash Gordon <sp**@flash-gordon.me.ukwrote in message
news:ji************@news.flash-gordon.me.uk...

Bill Reid wrote:

Richard Heathfield <in*****@invalid.invalidwrote in message
news:wt******************************@bt.com...

Bill Reid said:
Richard Heathfield <in*****@invalid.invalidwrote in message
news:7o******************************@bt.com...
<snip>

Anyway, I recommend comp.os.msdos.programmer or
comp.os.ms-windows.programmer.win32 as your next port of call.

Ah, horsefeathers...

...would at least have the merit of being portable.

Please try comp.horsefeathers...

>I think this might help

<system-specific solution snipped>

Can't say for sure right now just how many systems the "solution"
would work on, but I'm pretty sure it's more than one (and probably
more than 50, admittedly with some tweaks), therefore is not
"system-specific", riiiiiiiiiiight?

It does not work on all the systems I have programmed so it certainly is
specific to a selection of systems not general to all systems.

Nice try...well, not really, I give that a "4" on the Dodge-O-Meter...

Unlikely, since he's not using a POSIX-conforming implementation AFAIK.

Can't say for sure right now, but I doubt there's any such thing as
a "POSIX-conforming implementation" in the anal-restrictive sense
anywhere on the face of the planet. Of course, that is also true of
an "ANSI C-conforming" implementation...

I've no idea how many implementations claim POSIX compliance, nor how
many actually achieve it (modulo bugs). However, I do know that many
compilers, when correctly prodded, are compliant to a version of the ISO
C standard apart from the odd bug.

I very carefully (and sneakily) used the term "anal-restrictive" as opposed
to the more common term "anal-retentive"...as part of the "standards wars"
in Unix in years past there was at least one period where there was
a certain effort made to conform to POSIX, but you can be certain that
none of the systems CONFINED their functionality ENTIRELY to what
was in the POSIX standard...

Likewise, to the best of my knowledge and belief all the parts of the
compiler I used to compile the code I presented are absolutely conforming
to the ANSI C (90?) standard, except it also contains a whole bunch
of other stuff, including some 99 (?), "special extensions", "even more
special extensions that prove what geniuses we are", and of course, it's
actually a C++ compiler, but a lot of it is actually Pascal, to further
prove
what geniuses they were...

By comparison, just accepting mkdir() as a fact of a "C" programmer's
life is pretty benign, wouldn't you say?

<snip>

I actually have a hard-copy bound version of the POSIX standard
here, but only because I fished it out of the trash of "Unix house" I
worked at...the problem with the ANSI C standard appears to be
that even fewer people ever bothered to buy it in the first place, only
to throw it away as useless junk two months later...

Well, I find reference to a (draft of) the C standard useful sometimes.

Well, as far as later ANSI C standards (99?) are concerned, didn't
they wind up in the trash bin pretty much the day they were printed?
But yeah, I picked one up out of the trash and do look at it occasionally...

When somebody posts a question with the term "mkdir()" in the
subject, as a PRACTICAL matter the actual answer is not actually
STRICTLY "POSIX-compliant", but, let us say, "derived from
Unix/POSIX and largely a 'work-alike' and most importantly
WIDELY USED ON MANY DIFFERENT 'SYSTEMS'
AND 'IMPLEMENTATIONS'".

Even if the mkdir takes a different number of arguments or they mean
completely different things?

Well, yeah. It's the basic idea that counts, because mkdir() in all cases
takes a file path and makes a directory.

What the hell else are you going to do to make a directory on a system
that uses directories? Squat down like a baby in your own baby poop
and squall endlessly about "IT'S NOT PORTABLE MOMMY!!!", or
just "man up" and change the arguments to mkdir() to match your
system?

Try to think logically: "mkdir()" is NOT specific to "DJGPP" (whatever
the holy god-forsaken hell that is). Interestingly enough, the SPECIFIC
"implementation" of "mkdir()" he mentions is closer to "POSIX" and
"Unix" than what I use to develop for Windows, because it takes
a "permissions" argument, though decidedly NOT the "Unix" argument...

If, as you claim in this post it is neither the same as the Unix version
nor the Windows version then very probably it *is* specific to DJPP.

Unfortunately, this nonsense forced me to actually look at what
"DJGPP" actually is, and I almost threw up. Ironic, really, but trust
me, there's NOTHING "specific" about it, and of course, the OP's
problem almost certainly has NOTHING to do with a specific
"DJGPP" problem (if it is, it's most like a "Java problem" where the
program doesn't run right on differing Unix X-window managers
even though they use the same X intrinsics)...

So is "mkdir()" a "DJGPP" topic, a "C" topic, a "MS-DOS" topic,
a "Windows" topic, a "Linux" topic, a "Unix" topic, or what?

Depends on the version of mkdir being used. Which is one reason why it
is not topical here.

OK, one of the choices was "C" and the OP dude was using a "C" version
of mkdir() (!) so I guess it IS on topic here! Done and done!

And when
you figure that out, please tell me if a "socket" is a "Unix" topic
(as is so often asserted here) or a "Microsoft" topic (well, "winsock"
is)...

Actually, it could sensibly be argued that it is a networking topic and
there are networking groups.

Yes, but you do have to get increasingly granular because as a
"networking topic" it really doesn't have anything to do at all with any
actual networking protocols! It's just a particular low-level software
methodology for sending and receiving data that comes over a network
connection...conceptually, sockets work identically in both Windows
and Unix (Linux et. al.) systems.

If you're going to re-direct, it's actually something like
comp.programming.<system>.networking.sockets,
but most of the time, it's really just a higher-level networking
library implementation question, so the guy is just gonna
get bounced back to a protocol group, then to languages
group, back to the sockets group (which is a dead group
in the first place because there's really nothing to discuss)...

Really, the take-away lesson is that Usenet is only good
for political flame wars and race-baiting, which are ALWAYS
on-topic...

As a practical matter, the way people work who actually program
in the "C programming language" is to compile "foreign" code, count
the errors, check their documentation for missing functions/headers,
and make INTELLIGENT decisions from there...but of course,
that's all covered in alt.real-life...

More sensible people

read: "sloooooow-working"?

review the code to find out what areas are standard

"standard" with what? If it's the "ANSI C standard" in the
"anal-restrictive" sense, then generally very little of it is "standard"
and we might as well just start squatting in the baby poop...

and will not need changing and what areas are system specific (even if
specific to a number of systems)

I dunno...I really think it boils down to some type of existing code
and library base where you "work". If you've seen and used mkdir()
before, you know you've got it, you're 90% done already...if not,
you're gonna find out very quickly in any event.

There's also something called "reading the labels on the package"
which is where "standards" are actually useful. If it says "ANSI C"
and "POSIX" on the label, and you know what those are and
what you have, again, you're 90% done already...too bad that
I've met several VPs of Software Development who couldn't handle
that simple task...

and this group will help with that. I
consider questions like, "is such and such standard?" to be topical
here. I also consider the follow up questions of, "well, is there an
alternative that is standard, and if so what is it?" to be topical.

So, the statement, "mkdir() is kind of a standard 'C' function for
making a directory, originally used in Unix" IS topical...whew, what
a relief...

Also, it is possible to write vast amounts of code that is completely
standard C although you often also need a small amount of non-standard
(or different standard) code, and here we deal with that vast quantity
of standard code.

Review carefully any and all of the code I post and note that a
large quantity of it is "standard" by your "restrictive" definition, but
if you want to get REALLY restrictive about it "printf()" isn't REALLY
a part of the "C" programming language, and neither is just about
everything else...

I just wish that more people stuck to standard C where
extensions are not needed, it would make my life a lot easier.

Absolutely, why re-invent the wheel? But if man had "standardized"
the wheel 6,000 years ago, we wouldn't have the "extension" of the
jet engine, and then what would happen to your frequent flyer miles?

---
William Ernest Reid

[Keith Thompson]

"Bill Reid" <ho********@happyhealthy.netwrites:

Kenny McCormack <ga*****@xmission.xmission.comwrote in message

[the usual]

Or loosen it!

Bill, please don't feed the troll.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>"Bill Reid" <ho********@happyhealthy.netwrites:

>Kenny McCormack <ga*****@xmission.xmission.comwrote in message

[the usual]

>Or loosen it!

Bill, please don't feed the troll.

Keith, Keith, Keith. You are such a girl.
It is just hard to imagine someone who's life is so empty.

[Flash Gordon]

Bill Reid wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrote in message
news:ji************@news.flash-gordon.me.uk...

>Bill Reid wrote:

>>Richard Heathfield <in*****@invalid.invalidwrote in message
news:wt******************************@bt.com.. .
Bill Reid said:
Richard Heathfield <in*****@invalid.invalidwrote in message
news:7o******************************@bt.com.. .

<snip>

>>When somebody posts a question with the term "mkdir()" in the
subject, as a PRACTICAL matter the actual answer is not actually
STRICTLY "POSIX-compliant", but, let us say, "derived from
Unix/POSIX and largely a 'work-alike' and most importantly
WIDELY USED ON MANY DIFFERENT 'SYSTEMS'
AND 'IMPLEMENTATIONS'".

Even if the mkdir takes a different number of arguments or they mean
completely different things?

Well, yeah. It's the basic idea that counts, because mkdir() in all cases
takes a file path and makes a directory.

Have you used *all* current and future* implementations then? No,
thought not.

What the hell else are you going to do to make a directory on a system
that uses directories?

I might use CreateDirectory or whatever other non-standard function is
provided.

Squat down like a baby in your own baby poop
and squall endlessly about "IT'S NOT PORTABLE MOMMY!!!", or
just "man up" and change the arguments to mkdir() to match your
system?

I have not said not to use it just that it is not topical here. If you
don't like the focus of this group, tough.

<snip>

>>As a practical matter, the way people work who actually program
in the "C programming language" is to compile "foreign" code, count
the errors, check their documentation for missing functions/headers,
and make INTELLIGENT decisions from there...but of course,
that's all covered in alt.real-life...

More sensible people

read: "sloooooow-working"?

No, I mean professionals who want to provide something that will work
and do it in a predictable timescale.

>review the code to find out what areas are standard

"standard" with what? If it's the "ANSI C standard" in the
"anal-restrictive" sense, then generally very little of it is "standard"
and we might as well just start squatting in the baby poop...

You obviously don't know how to write C properly. If you did you would
know that 90% of most projects can be written in strict C90. Then, that
90% does not need to be changed when porting.

>and will not need changing and what areas are system specific (even if
specific to a number of systems)

I dunno...I really think it boils down to some type of existing code
and library base where you "work". If you've seen and used mkdir()
before, you know you've got it, you're 90% done already...if not,
you're gonna find out very quickly in any event.

Unless mkdir or some other non-standard code you are using behaves in s
subtly different manner so that normally it will work but in some
situations it will fail.

There's also something called "reading the labels on the package"
which is where "standards" are actually useful. If it says "ANSI C"
and "POSIX" on the label, and you know what those are and
what you have, again, you're 90% done already...too bad that
I've met several VPs of Software Development who couldn't handle
that simple task...

So educate them.

>and this group will help with that. I
consider questions like, "is such and such standard?" to be topical
here. I also consider the follow up questions of, "well, is there an
alternative that is standard, and if so what is it?" to be topical.

So, the statement, "mkdir() is kind of a standard 'C' function for
making a directory, originally used in Unix" IS topical...whew, what
a relief...

Show me the reference in the C standard. I'll save you the trouble,
there isn't one, so it is not standard C and not topical.

>Also, it is possible to write vast amounts of code that is completely
standard C although you often also need a small amount of non-standard
(or different standard) code, and here we deal with that vast quantity
of standard code.

Review carefully any and all of the code I post and note that a
large quantity of it is "standard" by your "restrictive" definition, but
if you want to get REALLY restrictive about it "printf()" isn't REALLY
a part of the "C" programming language, and neither is just about
everything else...

You are showing your ignorance again. The printf standard is right there
in the C standard with clearly defined behaviour.

>I just wish that more people stuck to standard C where
extensions are not needed, it would make my life a lot easier.

Absolutely, why re-invent the wheel? But if man had "standardized"
the wheel 6,000 years ago, we wouldn't have the "extension" of the
jet engine, and then what would happen to your frequent flyer miles?

The wheel being standardised would have no impact on the development of
the jet engine. C being standardised does not prevent extensions being
provided for things not covered by the C standard, in fact the C
standard specifically allows it.

If you want to argue that the focus of this group be changed at least
first learn what the focus is and what is covered by the C standard and
then get your facts right in your post. You might find these links helpful
http://clc-wiki.net/wiki/C_community...ility_attitude
http://clc-wiki.net/wiki/intro_to_clc
--
Flash Gordon

[Martijn]

Keith Thompson wrote:

"Bill Reid" <ho********@happyhealthy.netwrites:

>Kenny McCormack <ga*****@xmission.xmission.comwrote in message
[the usual] Or loosen it!

Bill, please don't feed the troll.

Blaming the kettle... :P

--
Martijn
http://www.sereneconcepts.nl
http://blogger.xs4all.nl/mihaak/

[Bill Reid]

Keith Thompson <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Bill Reid" <ho********@happyhealthy.netwrites:

Kenny McCormack <ga*****@xmission.xmission.comwrote in message

[the usual]

Or loosen it!

Bill, please don't feed the troll.

Which one?

Or did I just do it again?

---
William Ernest Reid

[Bill Reid]

Flash Gordon <sp**@flash-gordon.me.ukwrote in message
news:90************@news.flash-gordon.me.uk...

Bill Reid wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrote in message
news:ji************@news.flash-gordon.me.uk...

Bill Reid wrote:
Richard Heathfield <in*****@invalid.invalidwrote in message
news:wt******************************@bt.com...
Bill Reid said:
Richard Heathfield <in*****@invalid.invalidwrote in message
news:7o******************************@bt.com. ..

<snip>

>When somebody posts a question with the term "mkdir()" in the
subject, as a PRACTICAL matter the actual answer is not actually
STRICTLY "POSIX-compliant", but, let us say, "derived from
Unix/POSIX and largely a 'work-alike' and most importantly
WIDELY USED ON MANY DIFFERENT 'SYSTEMS'
AND 'IMPLEMENTATIONS'".

Even if the mkdir takes a different number of arguments or they mean
completely different things?

Well, yeah. It's the basic idea that counts, because mkdir() in all

cases

takes a file path and makes a directory.

Have you used *all* current and future* implementations then? No,
thought not.

BWHAHAHAHAHAHAHAHAHA!!! Have I "used all future
implementations"!!!! BRILLIANT!!!!

This is why you should never "argue" with a troll...insane troll logic
is impossible for a "normal" to even comprehend, let alone "disprove"...

What the hell else are you going to do to make a directory on a system
that uses directories?

I might use CreateDirectory or whatever other non-standard function is
provided.

The OP's system uses mkdir()! More brilliance! Somebody asks
about mkdir(), therefore "I would use CreateDirectory"!!!

Squat down like a baby in your own baby poop
and squall endlessly about "IT'S NOT PORTABLE MOMMY!!!", or
just "man up" and change the arguments to mkdir() to match your
system?

I have not said not to use it just that it is not topical here. If you
don't like the focus of this group, tough.

Nope, that's not all you said. But the take-away message here
is "don't ever post any C code that includes any functions not included
in the C standard, but we're a little fuzzy on which C standard because
frankly nobody really uses the most recent C standards, but in any event
<deeeeep breath>, if it doesn't appear in ANY ANSI C standard it is
'off-topic', and don't try to sneak any IEEE POSIX stuff by us, neither,
or we'll be on you like stink on a skunk <deeeeeeeeeep breath>".

But seriously, what's the REAL problem here? I mean, I couldn't
help but notice posting C code in a group called "comp.lang.c" seemed
to get some panties in a bunch...any thoughts as to why? I've got
mine...

<snip>

>As a practical matter, the way people work who actually program
in the "C programming language" is to compile "foreign" code, count
the errors, check their documentation for missing functions/headers,
and make INTELLIGENT decisions from there...but of course,
that's all covered in alt.real-life...

More sensible people

read: "sloooooow-working"?

No, I mean professionals who want to provide something that will work
and do it in a predictable timescale.

You mean like "Rod Pemberton"? Or his revered colleague the guy
with the potato chip database?

review the code to find out what areas are standard

"standard" with what? If it's the "ANSI C standard" in the
"anal-restrictive" sense, then generally very little of it is "standard"
and we might as well just start squatting in the baby poop...

You obviously don't know how to write C properly.

Of course not, because you just said so. I'm sure "Rod Pemberton"
would agree, and the potato chip database guy, and the guy who
threatened to shoot people with a bow and arrow if they ask where
his code is...

I'll tell you what, I'm ready to learn...I'm gonna buy a big bag of
"Lay's" and start cataloging each delicious chip tomorrow, in preparation
for my new career in "professional programming"...

If you did you would
know that 90% of most projects can be written in strict C90.

Did you know that 93.4568% of all statistics are just made up?

Also, remember those <deeeeeeeep breathsI included in your
topicality statement for the group? You might want to take one right
now, because you are already past the point where you are making
a complete fool of yourself.

Then, that
90% does not need to be changed when porting.

WAAAAAYYYY past the point...

and will not need changing and what areas are system specific (even if
specific to a number of systems)

Maybe you're just another alias for "Rod Pemberton" and this is
all just another one of his "jokes"?

I dunno...I really think it boils down to some type of existing code
and library base where you "work". If you've seen and used mkdir()
before, you know you've got it, you're 90% done already...if not,
you're gonna find out very quickly in any event.

Unless mkdir or some other non-standard code you are using behaves in s
subtly different manner so that normally it will work but in some
situations it will fail.

It always starts with an inability to THINK, doesn't it...remember, we
don't have an ANSI C STANDARD way to create a directory in the first
place.

Now, here's something really hard, but I want you to try: just keep that
FIRST thought in your head (it's your "thought" after all) even if a
SECOND thought also needs to be considered, such as, "we've got some
code that does file manipulation and we want to 'port' it to our
system rather than re-write it all from scratch to save some time".

Once you prove you can handle TWO thoughts, we'll work up to
THREE...but I'M not holding MY breath...

There's also something called "reading the labels on the package"
which is where "standards" are actually useful. If it says "ANSI C"
and "POSIX" on the label, and you know what those are and
what you have, again, you're 90% done already...too bad that
I've met several VPs of Software Development who couldn't handle
that simple task...

So educate them.

OK, I'm just going to go ahead and conclude from all the evidence
you've presented that you've never worked a day in your life in an
actual place of business (previously, I safely concluded you've never
worked anywhere near a software house that has to deal with portability
of a massive C codebase to a wide variety of systems)...

and this group will help with that. I
consider questions like, "is such and such standard?" to be topical
here. I also consider the follow up questions of, "well, is there an
alternative that is standard, and if so what is it?" to be topical.

So, the statement, "mkdir() is kind of a standard 'C' function for
making a directory, originally used in Unix" IS topical...whew, what
a relief...

Show me the reference in the C standard.

IEEE Standard 1003.1, Portable Operating System Interface for
Computer Environments, as tightly "bound" to the C programming
language.

Oh sorry, I forgot <deep breath>...

I'll save you the trouble,
there isn't one, so it is not standard C and not topical.

comp.std.c (or whatever) is just around the corner, check it out and
cease your trolling...

Also, it is possible to write vast amounts of code that is completely
standard C although you often also need a small amount of non-standard
(or different standard) code, and here we deal with that vast quantity
of standard code.

Review carefully any and all of the code I post and note that a
large quantity of it is "standard" by your "restrictive" definition, but
if you want to get REALLY restrictive about it "printf()" isn't REALLY
a part of the "C" programming language, and neither is just about
everything else...

You are showing your ignorance again.

I hate it when I do that! I must be because you asserted it, just
like "Rod Pemberton" asserted it takes three months print a magazine!

The printf standard is right there
in the C standard with clearly defined behaviour.

It's right there in Section 8.1, "Referenced C Language Routines" in
IEEE 1003.1 as well. So I guess it is a STANDARD library routine,
just not actually part of the C programming language per se...

I just wish that more people stuck to standard C where
extensions are not needed, it would make my life a lot easier.

Absolutely, why re-invent the wheel? But if man had "standardized"
the wheel 6,000 years ago, we wouldn't have the "extension" of the
jet engine, and then what would happen to your frequent flyer miles?

The wheel being standardised would have no impact on the development of
the jet engine. C being standardised does not prevent extensions being
provided for things not covered by the C standard, in fact the C
standard specifically allows it.

Here is where you have to try really hard and keep THREE things
in your head at once...isn't "mkdir()" indeed just yet another of those
"extensions" SPECIFICALLY ALLOWED BY THE "C STANDARD"?

<wheewwwwwwwwwfff! (The sound you just heard was that
last thought flying out of his head like a jet plane.)

If you want to argue that the focus of this group be changed at least
first learn what the focus is

Oh, I'm not going to "argue" what the focus is, I'm just going to
post appropriate code examples written in the C language from
time to time no matter what you or "Rod Pemberton" or any
other similarly mentally-situated person feels about it. Again,
I suggest a little deep-breathing and perhaps the trick of counting
to 10 before you post...also, the basic idea of not saying anything
unless you have something constructive to contribute is good too...

and what is covered by the C standard and
then get your facts right in your post.

I did make mistakes as always...intelligent, thoughtful people learn
and grow (and in my case, re-learn what I already knew!).

For example, the OP specifically stated:

mkdir("newdirectory", S_IWUSR); // this works OK, and appends
newdirectory to the current path

mkdir("F:\\myfolder\\dumps", S_IWUSR); // does not work.

And then later I averred that:

Interestingly enough, the SPECIFIC
"implementation" of "mkdir()" he mentions is closer to "POSIX" and
"Unix" than what I use to develop for Windows, because it takes
a "permissions" argument, though decidedly NOT the "Unix" argument...

Actually, it is PRECISELY the POSIX "Unix" argument; reading
between the coffee grounds in my salvaged copy of IEEE 1003.1
(and looking at some of my own code!), I see in Section 5.6.1.2
"<sys/stat.hFile Modes":

S_IWUSR Write permission for the file owner class.

So again, I have displayed my profound ignorance...I am deeply
shamed...

Also, I might mention that in addition to not adding that
"permissions" argument to the code I posted using "mkdir()",
the OP might also be stymied by the declaration/definition of:

unsigned dir_num=count_file_path_dirs(file_path);

Since I forgot to include:

unsigned count_file_path_dirs(char *file_path) {
unsigned num_dirs=0;
char *search_ptr=file_path;

while((search_ptr=strchr(search_ptr,'\\'))!=NULL) {
search_ptr++;
num_dirs++;
}

return num_dirs;
}

Of course, the code is bone-stock ANSI C standard, but oddly
assumes there is such a thing on a system as a "directory" but ANSI
C doesn't think directories even exist but even so you can use
ANSI C to manipulate directories <deeeeeeeeep breathjust
not create them, read them, delete them, rename them <deeeep breath>...

You might find these links helpful
http://clc-wiki.net/wiki/C_community...ility_attitude
http://clc-wiki.net/wiki/intro_to_clc

I generally don't click on links provided in Usenet posts as a
security precaution...there's a lot of mentally-unstable weirdos
on Usenet, doncha know ("Rod"?)...

---
William Ernest Reid

[Random832]

2006-11-13 <_g*******************@bgtnsc05-news.ops.worldnet.att.net>,
Bill Reid wrote:

>
Flash Gordon <sp**@flash-gordon.me.ukwrote in message
news:90************@news.flash-gordon.me.uk...

>Bill Reid wrote:

Well, yeah. It's the basic idea that counts, because mkdir() in
all cases takes a file path and makes a directory.

Have you used *all* current and future* implementations then? No,
thought not.

BWHAHAHAHAHAHAHAHAHA!!! Have I "used all future implementations"!!!!
BRILLIANT!!!!

This is why you should never "argue" with a troll...insane troll logic
is impossible for a "normal" to even comprehend, let alone
"disprove"...

I don't know - the bit about future implementations does a pretty good
job at disproving it.

--
Yes, I've changed my name. I've rethought the wisdom of using my real
name on usenet.

[Chris Torek]

In article <_g*******************@bgtnsc05-news.ops.worldnet.att.net>
Bill Reid <ho********@happyhealthy.netwrote (in part):

>comp.std.c (or whatever) is just around the corner ...

comp.std.c is for discussions like "shouldn't the third word of
the fourth paragraph on page 47 of draft X be `shall' instead of
`may'?" There is some overlap between "on-topic" items for both
comp.std.c and comp.lang.c, but -- in my opinion anyway -- the
thrust of the two groups is quite different: comp.lang.c is mainly
about using what we have now, while comp.std.c is mainly about
changing what we will have ten years from now.

>Also, I might mention that in addition to not adding that
"permissions" argument to the code I posted using "mkdir()" ...

Depending on whether the system is POSIX-like or not. Note that
POSIX discussions really belong in comp.unix.programmer (that
group's name predates POSIX, hence the word "unix" instead of
"posix" ... just as "comp.lang.c" predates the ANSI C standard,
hence the name, which should perhaps have been
"comp.lang.standard-c-and-nothing-else" :-) ).

>the OP might also be stymied by the declaration/definition of:

unsigned dir_num=count_file_path_dirs(file_path);

Since I forgot to include:

unsigned count_file_path_dirs(char *file_path) {
unsigned num_dirs=0;
char *search_ptr=file_path;

while((search_ptr=strchr(search_ptr,'\\'))!=NULL) {
search_ptr++;
num_dirs++;
}

return num_dirs;
}

For what it is worth, this again makes the mistake of using backslash
instead of forward slash, so it will not work on actual POSIX
systems. This is easy to fix, but after fixing that, it still
gives a wrong answer for, e.g.:

count_file_path_dirs("this//that/the///other")

(In fact, the whole idea is a little flawed. Compare path names
like "./foo" and "/foo", for instance. Note that while POSIX says
that multiple slashes *within* a pathname are equivalent to a single
slash, it allows multiple *leading* slashes to have special meaning,
so "foo/bar" and "foo//bar" are identical, but "/foo" and "//foo" may
be either identical or different.)

If you want to know what to do on Windows systems (e.g., how to
treat path names like "A:\\foo" vs "\\foo"), one of the many
comp.os.ms-windows.* groups is probably the most appropriate place.
(The double backslashes here are meant in the C sense, to prevent
the letter f from being part of the \f form-feed escape.)

>Of course, the code is bone-stock ANSI C standard, but oddly
assumes there is such a thing on a system as a "directory" but ANSI
C doesn't think directories even exist but even so you can use
ANSI C to manipulate directories <deeeeeeeeep breathjust
not create them, read them, delete them, rename them <deeeep breath>...

For instance, you cannot -- at least not without using "#ifdef"s
-- create code that works correctly on both POSIX systems and (e.g.)
vxWorks 5.5 systems, even though both of those support ANSI C89.
(vxWorks 6.x has some POSIX support, with some restrictions. This
means, among other things, that there are two *different* ways to
call mkdir()!)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

Bill Reid wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrote in message

.... snip ...

>>
I have not said not to use it just that it is not topical here.
If you don't like the focus of this group, tough.

Nope, that's not all you said. But the take-away message here
is "don't ever post any C code that includes any functions not
included in the C standard, but we're a little fuzzy on which C
standard because frankly nobody really uses the most recent C
standards, but in any event <deeeeep breath>, if it doesn't appear
in ANY ANSI C standard it is 'off-topic', and don't try to sneak
any IEEE POSIX stuff by us, neither, or we'll be on you like stink
on a skunk <deeeeeeeeeep breath>".

Congratulations. Now you are finally beginning to catch on. Of
course, if you include the (std C) source for that function in the
article, it can then be critiqued along with everything else.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Nick Keighley]

Bill Reid wrote:

Chris Torek <no****@torek.netwrote in message
news:ej********@news4.newsguy.com...

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

>I think this might help (I think this is all at least POSIX-compliant,
>close enough for real-world work on non-embedded systems):

No, because (at least):

while((search_ptr=strrchr(path_directories,'\\'))! =NULL) {

... the POSIX path-separator character is slash ('/'), not backslash.

Absolutely correct, but I believe that you can use '/' for what the
OP was working on and have it be portable to a very large majority
of all the general-purpose computer systems manufactured after
1990 (unfortunately, probably not the one I'm typing this on without
another "tweak")...

VAX? Trax?

I did follow up and note that my definition of "POSIX-compliant"
isn't so much strict compatibility but rather just "sort of looks like
POSIX"...I don't know how that could possibly cause confusion...

(There may be other problems, but this was the one that sprang right
out.)

Also I noted the difference in the number of arguments to "mkdir()",
and the specifics of the "permissions" argument...other than that, and
probably a bunch of other stuff, it's totally POSIX-compliant! Who
knew MS-DOS was actually a Unix system!

you are an idiot.
--
Nick Keighley

[Flash Gordon]

Bill Reid wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrote in message

<snip>

This is why you should never "argue" with a troll...insane troll logic
is impossible for a "normal" to even comprehend, let alone "disprove"...

<snip>

>You might find these links helpful
http://clc-wiki.net/wiki/C_community...ility_attitude
http://clc-wiki.net/wiki/intro_to_clc

I generally don't click on links provided in Usenet posts as a
security precaution...there's a lot of mentally-unstable weirdos
on Usenet, doncha know ("Rod"?)...

Set up your system properly and you can safely click on any link. Or you
can Google this group for the history of that site.

Also, you seem to be associating me with Rod Pemberton, I'm sure he
would agree that he and I have some significantly different opinions.

It's highly likely I would disagree with a lot of the rest of your post,
but the way you were ranting it did not seem worth the effort of reading.

Oh, by the way, *PLONK*, something I don't think you see trolls say,
since they are here to argue.
--
Flash Gordon

[Bill Reid]

Chris Torek <no****@torek.netwrote in message
news:ej*********@news4.newsguy.com...

In article <_g*******************@bgtnsc05-news.ops.worldnet.att.net>
Bill Reid <ho********@happyhealthy.netwrote (in part):

comp.std.c (or whatever) is just around the corner ...

comp.std.c is for discussions like "shouldn't the third word of
the fourth paragraph on page 47 of draft X be `shall' instead of
`may'?"

Yeah, I know...did you know I knew?

>

Also, I might mention that in addition to not adding that
"permissions" argument to the code I posted using "mkdir()" ...

Depending on whether the system is POSIX-like or not.

I think you're more hung up on "slashes" than OJ Simpson, but
anyway...

Note that
POSIX discussions really belong in comp.unix.programmer (that
group's name predates POSIX, hence the word "unix" instead of
"posix" ...

Is there a "POSIX" group (not that I care)?

just as "comp.lang.c" predates the ANSI C standard,
hence the name, which should perhaps have been
"comp.lang.standard-c-and-nothing-else" :-) ).

THE NEWSGROUP FOUNDERS COULDN'T PREDICT
"FUTURE IMPLEMENTATIONS"!!!

the OP might also be stymied by the declaration/definition of:

unsigned dir_num=count_file_path_dirs(file_path);

Since I forgot to include:

unsigned count_file_path_dirs(char *file_path) {
unsigned num_dirs=0;
char *search_ptr=file_path;

while((search_ptr=strchr(search_ptr,'\\'))!=NULL) {
search_ptr++;
num_dirs++;
}

return num_dirs;
}

For what it is worth, this again makes the mistake of using backslash
instead of forward slash, so it will not work on actual POSIX
systems.

Easy, Orenthal...

This is easy to fix, but after fixing that, it still
gives a wrong answer for, e.g.:

count_file_path_dirs("this//that/the///other")

James, please!!! That nonsense is pure, unadulterated POSIX
fol-de-rol! It takes a committee to come up with an abomination
like that!

(In fact, the whole idea is a little flawed. Compare path names
like "./foo" and "/foo", for instance. Note that while POSIX says
that multiple slashes *within* a pathname are equivalent to a single
slash, it allows multiple *leading* slashes to have special meaning,
so "foo/bar" and "foo//bar" are identical, but "/foo" and "file://foo" may
be either identical or different.)

All 100% POSIX true...I know all this because I just recently read
the POSIX standard, then had to lie down for a week due to bureaucratic
wooziness...

If you want to know what to do on Windows systems (e.g., how to
treat path names like "A:\\foo" vs "\\foo"), one of the many
comp.os.ms-windows.* groups is probably the most appropriate place.

Why, since what I posted works great on Windows systems, just
not on systems with pathnames created by pathological weirdos pushing
the limits of the standard?

(The funniest thing about my copy of the POSIX standard is
Section B.1.2.12 "WeirdNIX...or destructive QA of a standard.",
where they have a contest to come up with the most ridiculous
example of a compliant implementation detail possible...what
did you expect from the creators of the "Obfuscated C Code
Contest"...)

BTW, I think you're in the running with "this//that/the///other"...an
operating system designed by a benevolent dictator like Bill Gates
would never allow that...

>

Of course, the code is bone-stock ANSI C standard, but oddly
assumes there is such a thing on a system as a "directory" but ANSI
C doesn't think directories even exist but even so you can use
ANSI C to manipulate directories <deeeeeeeeep breathjust
not create them, read them, delete them, rename them <deeeep breath>...

For instance, you cannot -- at least not without using "#ifdef"s
-- create code that works correctly on both POSIX systems and (e.g.)
vxWorks 5.5 systems, even though both of those support ANSI C89.
(vxWorks 6.x has some POSIX support, with some restrictions. This
means, among other things, that there are two *different* ways to
call mkdir()!)

Well, at least that means full employment for programmers!

---
William Ernest Reid

[Bill Reid]

Random832 <ra****@random.yi.orgwrote in message
news:sl*******************@rlaptop.random.yi.org.. .

2006-11-13 <_g*******************@bgtnsc05-news.ops.worldnet.att.net>,
Bill Reid wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrote in message
news:90************@news.flash-gordon.me.uk...

Bill Reid wrote:

Well, yeah. It's the basic idea that counts, because mkdir() in
all cases takes a file path and makes a directory.

Have you used *all* current and future* implementations then? No,
thought not.

BWHAHAHAHAHAHAHAHAHA!!! Have I "used all future implementations"!!!!
BRILLIANT!!!!

This is why you should never "argue" with a troll...insane troll logic
is impossible for a "normal" to even comprehend, let alone
"disprove"...

I don't know - the bit about future implementations does a pretty good
job at disproving it.

Yup, anybody without a time machine is gonna be SOL...and I so
wanna visit Buck Rogers in the 25th century...

--
Yes, I've changed my name. I've rethought the wisdom of using my real
name on usenet.

I like your new name, not that I know what the old one was...try to
live up to it with a lot of jumbled up spelling, syntax, and logic, and
you'll fit right in to the "new Usenet"!

---
William Ernest Reid

[Bill Reid]

CBFalconer <cb********@yahoo.comwrote in message
news:45***************@yahoo.com...

Bill Reid wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrote in message

... snip ...

>
I have not said not to use it just that it is not topical here.
If you don't like the focus of this group, tough.

Nope, that's not all you said. But the take-away message here
is "don't ever post any C code that includes any functions not
included in the C standard, but we're a little fuzzy on which C
standard because frankly nobody really uses the most recent C
standards, but in any event <deeeeep breath>, if it doesn't appear
in ANY ANSI C standard it is 'off-topic', and don't try to sneak
any IEEE POSIX stuff by us, neither, or we'll be on you like stink
on a skunk <deeeeeeeeeep breath>".

Congratulations. Now you are finally beginning to catch on.

Yeah, took me a while, even longer to "comply" unfortunately...

Of
course, if you include the (std C) source for that function in the
article, it can then be critiqued along with everything else.

Oh hell, it might be in assembler for all I know...why do I think that
if I called it "black_function_that_creates_directory_from_pathst ring()"
you might "accept" it a little easier, and just "critique" the remaining
ANSI C code...

---
William Ernest Reid

[Bill Reid]

Flash Gordon <sp**@flash-gordon.me.ukwrote in message
news:d9************@news.flash-gordon.me.uk...

Bill Reid wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrote in message

<snip>

This is why you should never "argue" with a troll...insane troll logic
is impossible for a "normal" to even comprehend, let alone "disprove"...

<snip>

You might find these links helpful
http://clc-wiki.net/wiki/C_community...ility_attitude
http://clc-wiki.net/wiki/intro_to_clc

I generally don't click on links provided in Usenet posts as a
security precaution...there's a lot of mentally-unstable weirdos
on Usenet, doncha know ("Rod"?)...

Set up your system properly and you can safely click on any link.

<Maynerd J. Krebs>WORK!</Maynerd J. Krebs>

Or you
can Google this group for the history of that site.

Hmmmm..."or" is not the appropriate word here, because it doesn't
matter what the "history" of the site is, if it is a "spoofed" link...

Also, you seem to be associating me with Rod Pemberton, I'm sure he
would agree that he and I have some significantly different opinions.

His arms are too short to box with God...are you just a super-hero,
or something more?

It's highly likely I would disagree with a lot of the rest of your post,
but the way you were ranting it did not seem worth the effort of reading.

Well, we all value rants differently...

Oh, by the way, *PLONK*, something I don't think you see trolls say,
since they are here to argue.

Well, good for you, "Flash"...about five more unemployed insane
ex-programmers to go, and I'll have made this group safe for intelligent
adults...

---
William Ernest Reid

[Bill Reid]

Nick Keighley <ni******************@hotmail.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...

>
you are an idiot.

You're a genius...your momma told me...

---
William Ernest Reid