Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!longway!std-unix
From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-ID: <761@longway.TIC.COM>
Date: 30 Jun 90 10:28:58 GMT
References: <385@usenix.ORG> <754@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 61
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

Moderator!:  Delete most of these lines (begin):
Return-Path: <uunet!goanna.cs.rmit.OZ.AU!ok>
Submitted-From: uunet!goanna.cs.rmit.OZ.AU!ok (Richard A. O'Keefe)
Moderator!:  Delete most of these lines (end).

From:  ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)


>In <385@usenix.ORG> From: jsh@usenix.org, Paul Rabin <rabin@osf.org>
> reports on the April 23-27 meeting in Salt Lake City, UT:
>...
> There was a discussion about whether it is possible (and preferable)
> to improve the low-level directory interfaces instead of adding new,
> high-level interfaces.  Do the high-level interfaces really add new
> functionality for portable applications?  Do they belong with the
> low-level operating system interfaces specified in 1003.1?

In article <754@longway.TIC.COM>, gwyn@smoke.brl.mil (Doug Gwyn) writes:
> From:  Doug Gwyn <gwyn@smoke.brl.mil>
> No, definitely not.  However, they would be appropriate at the 1003.2
> level.

If I want file tree walking, what's wrong with something on the order of
	FILE *files_selected = popen("find ......");
Presumably popen() and 'find' have to be in 1003.2 anyway.  There is
precisely one reason why I can't use this right now, and that is that
'find' doesn't quote its output, so if there is a file name with an
embedded \n things break.  That might be addressed by any number of
methods; one simple method would be to add a
	-length
subcommand which would do the equivalent of
	printf("%d %s\n", strlen(pathname), pathname);
where the existing
	-print
subcommand does the equivalent of
	printf("%s\n", pathname);

If I understand Doug Gwyn correctly, that's the kind of thing he has
in mind.  It is, after all, no more than the traditional UNIX Way.

By the way, I don't quite understand the file tree walking problem.
Unless one has some absolutely compelling reason for requiring a
depth-first search and not using /tmp files, something like 'find'
can be done using
	- one file descriptor to send file names to
	  (used sequentially)
	- one file descriptor for a work file
	  (random access)
	- one directory descriptor or whatever
	  (each directory being opened once, scanned once, and
	   never looked at again)
Basically you do a breadth-first search of directories, using the work
file to hold the queue.  If you want some other order, sort the output.
This is, of course, vulnerable to directories being renamed while the
walk is in progress, but so is a depth-first walker that can't hang on
to all the directories in the current branch.

-- 
"private morality" is an oxymoron, like "peaceful war".

Volume-Number: Volume 20, Number 76