🚀 go-pugleaf

In article <1991Mar19.105139.28070@jato.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes:
>In article <1991Mar19.150319.25547@qut.edu.au> lunnon@qut.edu.au writes:
>>Huh, why not use dirent ??? This seems reasonably capable and is portable
>>to boot ???
>
>I'd agree, we should try to hide the Fsfirst/Fsnext layer completely and
>use the Unix *dir routines instead. (This seems reasonable, given MiNT's
>apparent intent to provide as much BSD functionality as possible...)

i agree with howard. only i think we should pick BSD or USG, but *not*
both. POSIX would be ideal (does it say anything about opendir/readdir/etc?
wait, i just checked... yes it does). i have to carry around ndir.h direct.h
dirent.h and all the others from BSD and USG for portability. let's stick
to posix, here, and do away with the duplicity.

posix synopsi are:

	#include <sys/types.h>
	#include <dirent.h>

	DIR *opendir(dirname)
	char *dirname;

	struct dirent *readdir(dirp)
	DIR *dirp;

	void rewinddir(dirp)
	DIR *dirp;

	int closedir(dirp)
	DIR *dirp;

typical use:

	DIR *dirp;
	struct dirent *d;
	char *name;

	if ((dirp = opendir(name)) != (DIR *) NULL)
	{
		while ((d = readdir(dirp)) != (struct dirent *) NULL)
			do_something_with_d (d);
		if (closedir(dirp))
			check_errno_right_now ();
	}
	else
		check_errno_right_now ();

issues: is int 32-bit or 16-bit (note that DTA uses 16-bit ints in its
low-level structure)? will we support errno? zillions of (incompatible)
versions (like lharc :-). note that readdir(3) provides space for the
dirent so it gets wacked on subsequent calls.

i have more or less working (BSD-flavor) versions of these. it made porting
BSD ls(1) easy. only trouble is it is slow as molasses for large directories.
i think gulam's ls reads the FAT directly. it is great for recursive searches
(i think i have a traverse(3), if memory serves). i try to hide Fsfirst/next
as much as i can, though they do exist in MSDOS. not that both turbo C and
MSC on the PC support the *dir functions (i think) so applications port to
dos, too (if that matters). my versions use Fs*.

in general, i think sticking to posix as much as possible is what we really
want. that's why it was developed, after all: portability. speed is another
issue altogether. in fact, with these functions in place, it should be
possible to use either GEMDOS Fs* or direct reads of the FAT and still have
a portable program.

if u want, i can post these...

-bill
rosenkra@convex.com






--
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
Convex Computer Corp.      |ARPA: rosenkra%c1yankee@convex.com