PE> */ /* The first parameter is a filename. This can be a simple
PE> */ /* filename such as "temp.c", or one that contains
wildcards such
PE> */ /* as "temp.*" or "temp.c(*)".
^^^^^^^^
Read!!!
PE> */ /* The second parameter is a pointer to a control block. This
PE> */ /* control block's structure is machine-specific, and contains
PE> */ /* information that trav will use such as whether or not to
PE> */ /* search subdirectories as well.
PE> */ /*
PE> */ /* The third parameter is a pointer to a function which will get
PE> */ /* called for every file found.
PE> */ /*
PE> */ /* The fourth parameter is a pointer to a control block which will
PE> */ /* get passed to the function you specified as parameter 3.
PE> */ /*
PE> */ /* The function that trav calls takes two parameters:
PE> */ /* The first is a filename that trav has found.
PE> */ /* The second is the fourth parameter you passed to trav.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Read!!!
PE> */ /*
PE> */ /* example of use:
PE> */ /*
PE> */ /* int myfunc(char *fnm, void *ucb)
PE> */ /* {
PE> */ /* printf("fnm is %s\n",fnm);
PE> */ /* return (1);
PE> */ /* }
PE> */ /*
PE> */ /* main()
PE> */ /* {
PE> */ /* trav("dd:input(*)",NULL,myfunc,NULL);
PE> */ /* return (0);
PE> */ /* }
PE> */ /*
BL> This is as clear as mud. I think I understand what you want to do,
BL> but how? Or what?
You could have tried it out.
BL> 1. What the fuck does "dd:input(*)" mean? It's a great
wank and it
BL> must make you feel really clever to know the secret, but what the
BL> fuck is it? My guess is something like..."C:\*.*"
Did you read where it says exactly that, giving temp.* as an example?
trav() must have been written originally on the mainframe, where
dd:input(*) is how you refer to all members of the PDS referred to by DD
input. In other words, that particular format of filename is only used for
MVS. For MSDOS, use *.* etc instead.
BL> 2. in mydefunct() what the fuck is uch? I assume that fnm is a file
BL> name but what is the form of uch? I assume it's a struct with the
BL> file data in it but I could be wrong.
Did you read where it tells you that it is whatever YOU specified as the
fourth parameter to trav()? The example uses NULL for the 4th parameter,
so you will get NULL. The example shows that parameter being ignored. You
can ignore it too.
PE> /* tcb of 1 means that the user wants the TTR */
BL> This gets my nomination for "misdirection of the Century" award. Are
BL> you kidding?
That's for MVS.
BL> Paul... trav() is so obscure that it is totally USELESS!
BL> I admit that I am not a patient man but I am incredibly persistent.
BL> If I can see a point in something I can worry at it for years until
BL> I finally understand it... but trav()! You've gotta be kidding.
I provide a 4-line program to get you started. I provide more
documentation in that function than I've supplied in all my other code put
together. Most applications only need the filename, not the file size and
date. Actually, you can get the file size portably in C. You can't get the
date though. Even then, what you do is make the date an optional feature,
so that if you have an environment that has a method of obtaining a date,
fine, if you don't, fine, put blanks there. At least it still works.
BL> I'll tell you what you need to make C work. It's fucking useless on
BL> files and directories... exactly the same as Pascal but Pascal gives
BL> up and just makes it work in DOS and Windows.
POSIX addresses the directory issue. I forgot to look up fstat() today. I
have already read the POSIX spec on opendir() and readdir() though.
BL> trav() *could* have been made to work, but not the way you did it.
BL> You need a findfirst() fndnext() wrapper approach that uses a struct
BL> to return the file data... in DOS format so you can use the rest of it
BL> to turn date/time into strings... not something that does whatever the
BL> fuck trav() does.
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 no one
BL> can!
It's actually not a new approach. There is a unix function ftw() which
does the same thing. In fact, the unix version of trav actually calls
ftw(). I somehow learnt about ftw() before I learnt about findfirst()/
findnext(). Anyway, the way it works is obvious if you had compiled and
run the sample program, putting in a DOS version of the wildcards instead
of MVS.
BL> And at the same time, you need a way to copy(), erase(), and move()
There's no copy, but you can do that by opening and reading files. erase()
is remove(). move() is rename().
BL> files and directories that works across the various O/S staying inside
BL> ansi functions. You need to write a little LIBRARY, using names and
BL> actions similar to existing functions, so everyone can use them the
BL> way they're used to using them, across the O/S barrier in ansi C. And
BL> for Christ's sake, don't try to be clever. Try to think like child
BL> who knows fuck all about anything. Any fool can make it complicated.
BL> Only a genius can make it simple. Be a genius and do it simple.
BL> But right now you've lost me. I can't make head nor fucking tail of
BL> what you've done and I can't see any value in trying to find out.
Feel free to use the POSIX functions instead of trav(). I would have done
that had POSIX been invented when I wrote trav(), or had I known about it,
whatever. Instead, I based trav() on ftw(), ie you supply a function, and
ftw() will call that function for each file it finds. BFN. Paul.
@EOT:
---
* Origin: X (3:711/934.9)
|