encapsulating directory operations

Someone (Jean-Marc) wrote some "folder" routines which I like a lot.
You can see them here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/hwzip/folder.c

And in essence, when you read from a directory, the only
thing you get is the filename. If it is actually a subdirectory,
then that is indicated with a "/" at the end of the filename.

Other things like size and creation date are not available,
and C90 does not guarantee that such concepts even
exist. C90 does guarantee that files exist though.

And in fact, files are the only thing that are ever actually
externally visible to a C90-compliant program.

Now it so happens that I need to traverse directories.
I want this to run on MVS/TSO as well as other environments,
and I have a way of making directories appear, even though
they don't really exist on the mainframe (traditional, like
MVS 3.8J).

So they will appear to be an 8.8 files, simlar to traditional
8.3 with FAT.

Plus I want to work with modern FAT long filenames, and
Unix too.

The folder routines will do everything I need.

The mkfldr() routine won't work under my MVS/TSO design,
but that doesn't bother me. I can probably make rmfldr() work,
but don't intend to for now.

Now C90 doesn't have folder/directory operations (such as
opendir()) for a reason.

That reason may cease to exist if I can demonstrate directories
grafted onto the mainframe.

And C90 (etc) could potentially be extended to include a folder.h

Or this could be something that doesn't belong in the C standard.

Or alternatively, this could be something incorporated within the
C90 standard, as designed.

I have already demonstrated zmodem working on a COM1
stream opened with fopen (shipped with Freewindows at
pdos.org). Interesting note is that I needed to escape the
MSDOS x'1a' (EOF) because something was swallowing it.
And I demonstrated it via my mainframe emulator too - giving
the mainframe the ability to connect to a BBS and do a FREQ.
Should work on real hardware too, using a TN3270 OSA/ICC
as an encapsulation layer, as I previously demonstrated with
an EBCDIC ANSI terminal.

So the next thing that I would potentially encapsulate is
something like this:

fopen(argv[1], "w+");

where the argument might be "/some/dir/" (with a terminating /
for good measure).

And then do a fputs("dir\n");

And fgets() and collect each name from the folder, using something
similar to those folder routines above - all done internally so not
really relevant.

Possibly a rewind() to reset the EOF condition of  the fgets.
Or maybe an fseek to offset 0 from SEEK_CUR.

And fputs("mkdir subdir\n"); to make a subdirectory.

And fputs("rmdir subdir\n"); to remove one.

And fputs("cd ..\n"); to change directory.


I'm wondering what the underlying principles here are that
would govern the correct thing to do.

Maybe I shouldn't be overloading the FILE concept to make
an artificial file.

Or maybe it is the other way around - we should perhaps
eliminate lots of APIs - like the TCP/IP ones - and stick
them all inside streams, and perhaps FILE is a misnomer,
it should have really been called STREAM.

Any thoughts (besides "get a life!")?

Thanks. Paul.