'access' builtin for rc?

'access' builtin for rc?

[DaviD W. Sanderson]

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)

Re: 'access' builtin for rc?

[Boyd Roberts]

    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().

No way.  NO WAY!  _NO WAY_!!

    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.

Hack your .rcrc so it's not so bloated or get a faster cpu.  `test' does
_not_ belong in the shell.  I thought we knew that from as far back as V6.
Back when programs were small and fast and CPUs were slow.

On my 3max it takes 0.4s (real & 0.0s cpu) to start rc and 1.6s (real & 0.4s
cup) to process my .rcrc, and it's bloated to 181 lines of system imposed crap
and 61 lines of personal stuff.  Getting a `rc -l' in an xterm is damn near
instantaneous, once X decides to give me a window.

Just what _have_ you got in your .rcrc?

    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.

Other shells, written by bozos included `test'.  Look at that System V mess.
Look at the hideous `type' command.  Couldn't code `whatis', but they built
`test' into the shell.

Don't start me on the Korn shell, jesus!  `typeset'...  $RANDOM... puke!

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

    So, I propose the following builtin command:

    	access [-rwxaefdbcplguk] path ...

No, we already have test.  Why have another `test'?

    Possible other options (getting into feeping creaturism here):

Features?  It's already got to many.  What about a:

	-C 	Compile the arguments to C    and execute.
	-L	  "      "      "     "  lisp  "     "

Just where will it all end?

If you really want this abortion, code it up and stick it in your bin.
NOT IN THE SHELL.  ANYWHERE, BUT IN THE SHELL!!!

I CANNOT SAY THIS TOO STRONGLY:

    _LEAVE THE FUCKING SHELL ALONE_!!!!!
    
I DON'T WANT ksh/csh/tcsh IN rc.  I WANT rc.  THAT'S ALL!!  NO MORE, NO LESS!!

    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.

How can it possibly be `simple' with 19 options?  Are you trying to rival `ls'?
`simple, small, clean, ...' blah blah blah that's what's always used to defend
just about any hack.  `gross, foul and unneccessary' is more like it.

Make it a command, and keep it out of the shell.

'access' builtin for rc?

[Hamish Macdonald]

I agree with Boyd.  It shouldn't be in the shell.

RE: 'access' builtin for rc?

[Dave Mason]

Boyd states it a little strongly, but I agree.  Access looks nicer than
test, but it should be an executable, not a builtin.  Perhaps it should ship
with rc (although is the extra functionality and clean-ness really worth the
incompatibility with test?), but in a bin library, please.

There are those of us who think that whatis should not be builtin.  And the
only excuse for echo is that it's tiny and used a *lot*.

	../Dave