PE> */ /* as "temp.*" or "temp.c(*)"
 PE> Read!!!

  So? Why call it dick:dobby(*$%) (or whatever it was?

 PE> */ /*  The second is the fourth parameter you passed to trav.          

 PE> Read!!!

  You mean you can't see anything confusing in that??? If the second
is the fourth, who's on first?

 BL> 1. What the fuck does "dd:input(*)" mean? It's a great wank and
 BL> it must make you feel really clever to know the secret, but
 BL> what the fuck is it? My guess is something like..."C:\*.*"

 PE> Did you read where it says exactly that, giving temp.* as an
 PE> example?

  I found it impossible to understand. If I were you, I'd aim at a 
slightly lower IQ level (like 100).

 PE> trav() must have been written originally on the mainframe,
 PE> where dd:input(*) is how you refer to all members of the PDS
 PE> referred to by DD input. In other words, that particular format
 PE> of filename is only used for MVS. For MSDOS, use *.* etc
 PE> instead. 

  You are doing it again. What's DD, PDS, MVS? I don't know any of
these. I especially liked the (*) that I thought was a pointer.

 BL> 2. in mydefunct() what the fuck is uch? I assume that fnm is a
 BL> file name but what is the form of uch? I assume it's a struct
 BL> with the file data in it but I could be wrong.

 PE> Did you read where it tells you that it is whatever YOU
 PE> specified as the fourth parameter to trav()? The example uses
 PE> NULL for the 4th parameter, so you will get NULL. The example
 PE> shows that parameter being ignored. You can ignore it too. 

  That was not my question. My question is: what the fuck is uch?

 PE> /* tcb of 1 means that the user wants the TTR */

 BL> This gets my nomination for "misdirection of the Century"
 BL> award. Are you kidding?

 PE> That's for MVS.

  Oh. Great. ROFL!!! What's MVS?

 BL> but trav()! You've gotta be kidding.

 PE> I provide a 4-line program to get you started. I provide more
 PE> documentation in that function than I've supplied in all my
 PE> other code put together. Most applications only need the
 PE> filename, not the file size and date. Actually, you can get the
 PE> file size portably in C. You can't get the date though.

  Oh, well that's great... I'll just leave a blank where it says
"date".

 PE> Even then, what you do is make the date an optional feature, so
 PE> that if you have an environment that has a method of obtaining
 PE> a date, fine, if you don't, fine, put blanks there. At least it
 PE> still works. 

  ROFL!!! And you call this a language... no date?

  Actually, you've helped me a lot. I went right through K&R and deep
into the depths of the Borland .h files to see what was in the structs
they use for UNIX and although I couldn'd find any way to get the data
I kept telling myself it can't be right. I still don't believe it,
actually. I reckon I should be able to crack the stat date struct
code.

 BL> No one is going to bother to learn a whole new appraoch to
 BL> directories... and especially when you have made it so obscure
 BL> no one can!

 PE> It's actually not a new approach. There is a unix function
 PE> ftw() which does the same thing. In fact, the unix version of
 PE> trav actually calls ftw(). I somehow learnt about ftw() before
 PE> I learnt about findfirst()/ findnext(). Anyway, the way it
 PE> works is obvious if you had compiled and run the sample
 PE> program, putting in a DOS version of the wildcards instead of
 PE> MVS. 

  Who cares? Life is too short. I'll use opendir().

 PE> There's no copy, but you can do that by opening and reading
 PE> files. erase() is remove(). move() is rename(). 

  How do you do copy() if you don't know the date, Paul? If I rewrite
the file I'll end up with today's date on it... and rename() isn't
UNIX according to Borland. You call this a portable language?

 PE> Feel free to use the POSIX functions instead of trav().

  I still don't know how to do copy() move() or rename() in C for
UNIX. Which is where I came in. I'll just cut to the chase....

... [later!!! FX: mad giggles]

  Aha! utime()!

  If I use stat() on an *OPEN* file to read time, I can set time on a
*CLOSED* file using utime() in both DOS and UNIX. The rest follows.
All I have to do now is write copy(), erase(), move() and all the file
functions... plus work out wtf opendir() does and I'm there!

  UNFORTUNATELY... it's not ansi C. But frankly my dear, I don't give 
a monkey's diddle.

  I told you I was persistent. It only took me 12 hours... hat a pity 
I'm not being paid my usual $2 a minute.

int copy(char *srce, char *dest)
{
FILE     *in, *out;
struct   stat     stt;
struct   utimbuf  tme;
int      ret;
char     buf[1024];

   if ((in = fopen(srce, "rb")) == NULL) return(-1);
   if ((out = fopen(dest, "wb")) == NULL) return(-1);
   while (1 == 1) {
      ret = fread(buf, 1, 1024, in);
      fwrite(buf, 1, ret, out);
      if (ret < 1) break;
   }
   if (stat(srce, &stt)) return(-1);
   tme.modtime = tme.actime = stt.st_ctime;
   fclose(in); fclose(out);
   if (utime(dest, &tme)) return(-1);
   return(0);
}

  Strange... that stat() works on an open file and utime() only works
on a closed file. I love the consistency in this fucking useless language.

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---