Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: encapsulating directory operations
Date: Wed, 21 May 2025 04:35:24 +0200
Organization: A noiseless patient Spider
Lines: 130
Message-ID: <100je5c$2l1b2$1@dont-email.me>
References: <100h650$23r5l$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 21 May 2025 04:35:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5a06320e906bc7d3540dc805e22898c9";
	logging-data="2786658"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+xAB7lK3pgYaO2i/qfxmFm"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:Pi0xYzkDvvkpBIWECIeYUypD3nY=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <100h650$23r5l$1@dont-email.me>

On 20.05.2025 08:06, Paul Edwards wrote:
> 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!")?

Directories are like files entities that have to and are handled
by the OS. Different OSes provide different interfaces to those
functions. There's, for example, Unix systems that historically
had differing interfaces. So standards have evolved (SUS, POSIX)
to get a common interface for Unix systems. Those standards also
define (besides the system calls) the other types of interfaces;
the shell and the Unix utilities called from the shell. Besides
the system calls (that are "incidentally" written and documented
in the C language) there's the languages that may want their own
abstractions; e.g. 'printf' (vs. 'write'). Such abstractions are
certainly useful to be supported as library functions. And I'd
write and provide directory abstractions also as add-on library
functions (as opposed to part of a language; but my opinion on
that is not strong). Historically other languages even missed to
provide any I/O functions; vendors provided own (non-standard)
functions. This had been considered a bad decision. There's also
other abstractions to files and directories, like, e.g. the OSI
and ITU-T standards for directories (X.500) and for file access
and management (FTAM); both abstracted on the upper OSI layer 7.

To sum up; on the way from the OS entity to the user interface
there's various abstraction levels. Depending on the service I'd
like to provide I'd probably choose different abstraction layers.
I _don't_ think that a directory abstraction should be *inherent*
part of the C language, but if necessary provided as a _library_.

Just my opinion on (some of?) your questions. HTH.

Janis

> 
> Thanks. Paul.
> 
>