From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from margay.cs.wisc.edu ([128.105.2.236]) by archone.tamu.edu with SMTP id <22543>; Thu, 1 Aug 1991 02:12:38 -0500
From: dws@cs.wisc.edu (DaviD W. Sanderson)
Message-Id: <9108010712.AA28450@margay.cs.wisc.edu>
Received: by margay.cs.wisc.edu; Thu, 1 Aug 91 02:12:21 -0500
Subject: 'access' builtin for rc?
To: rc@archone.tamu.edu
Date: Thu, 1 Aug 1991 02:12:17 -0500
X-Mailer: ELM [version 2.3 PL11]

I propose adding (perhaps conditionally) a new builtin for rc to
perform the most common functions of "test" for examining the file
system.  I have in mind those operations I would use "test" for that
are nothing more than an access() or a stat().

There are three reasons I am proposing this.

1) Currently it takes rc about 15 seconds to start up with my current
.rcrc, mostly because I'm doing things like testing whether directories
exist before I put them into my path.

I agree it's possible to test this sort of thing without a builtin, but
using /bin/test makes things sooooooo slow in my startup.

2) There is "prior art".  Many other shells have implemented "test" as
a builtin, for performance reasons.  I am not proposing for rc anything
so complicated as "test", since rc already has ways to examine strings
and process boolean expressions.

3) Byron wanted to see what the opinion of the mailing list would be.

So, I propose the following builtin command:

	access [-rwxaefdbcplguk] path ...

	where:
		-r	read permission (as reported by access())
		-w	write permission (as reported by access())
		-x	execute permission (as reported by access())
		-a	existence (as reported by access())

		-e	existence (as reported by lstat() success)
		-f	ordinary file
		-d	directory
		-b	block special
		-c	char special
		-p	named pipe (fifo)
		-l	symbolic link (maybe -L for visibility??)
		-g	setgid bit set
		-u	setuid bit set
		-k	sticky bit set

	If no test is specified the default is -a.

	If multiple tests are specified the result is the "anding"
	of the results of the individual tests.
	If multiple paths are given the result is the "anding"
	of the results for all of the paths.
	(Put more simply, the first failed test causes "access" to
	short-circuit to failure.)

	Tests like -l or -p will of course always fail on systems
	without these features.

	The non-access() tests use stat() except for -l and -e which
	use lstat() if available.

This command does not worry about handling strings or boolean
expressions as /bin/test does; it concentrates entirely on simple file
system probes.  The reason I propose to allow multiple tests and
multiple paths is that it seems stupid to me to arbitrarily allow only
one, and "anding" the results seems to me the natural thing to do.

Possible other options (getting into feeping creaturism here):

	-N
	-O	These would succeed if all the pathnames AFTER the first
		pathname were newer or older, respectively, than the
		first pathname.  They would fail if only one pathname
		argument was given.  They would also fail if stat()
		failed on any of the pathname arguments.

	-E	"Equivalence".   (Maybe "-I" for "Identical"?)
		Test whether the given pathnames refer to the same file.
		Returns true if all the pathname arguments have the
		same st_dev and st_ino numbers as returned by lstat().
		Vacuously succeeds if only one pathname is given and
		lstat() succeeds.

	-t	Test whether the given file descriptors are ttys.
		In this case the "path" argument(s) would be
		decimal numbers.  For consistency with the other
		options, there would be no default file descriptor
		to test.

	-o	"Or" all the tests instead of "And"ing them.
		This would not only Or the results of all the tests,
		but it would also Or the results for all the paths.
		(e.g. the first successful test would cause "access"
		to short-circuit to a success.)

I could write "access" so that it could be conditionally compiled as a
separate command, for those purists who don't want it in the shell.
(Or simply leave it out, if it isn't wanted.)

My impression (having just thought it up) is that "access" is simple,
small, clean, and consistent (hopefully in the style of rc), and offers
quite a performance improvement for common tests.

I am interested in what the rest of you think about this idea.

DaviD W. Sanderson (dws@cs.wisc.edu)