From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by hawkwind.utcs.toronto.edu with SMTP id <2711>; Wed, 17 Jun 1992 12:38:07 -0400
Received: by doolittle.vetsci.su.oz.au id <49226>; Thu, 18 Jun 1992 02:36:23 +1000
From:	John (_You_ hide, they seek.) Mackin <john@vetsci.su.oz.au>
Date:	Wed, 17 Jun 1992 12:09:14 -0400
To:	The rc Mailing List <rc@hawkwind.utcs.toronto.edu>
Subject: "pathos" script
Message-ID: <199206180209.18162.rc.baler@vetsci.su.oz.au>
X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F
 k5[Ah<7xBWF<un6={nlL7Om5<0UsuHKjCxs)C$`DP.N'-LLb8=8)"a@d2bG-f7qD2AJ#UZ>-@-ru?&
 @4K4-b`ydd^`(n%Z{

I guess I should mail this one to the list.

You know how you often want to do something that does `just that
little bit extra'?  Like, in that script front-end I sent earlier,
you want to call that one "script" too and then have it execute
the command by the same name further along $path?  In my earlier
mail, I wrote "exec /full/path/to/real/script", but I always thought
it was a right bummer to have to wire those pathnames in.  Of course,
if the frontend you are writing is a function, you win since you
can just use "builtin" to get to the executable; but there's
nothing built-in to rc to help you in the more common case
where the frontend you are writing is a script.

Naturally, it doesn't have to be built in to rc; here it is.
I've been using this one for ages but didn't get around to sending
it out until now, so it should be solid.

You use it, say in my "script" example, by ending the command with:

exec pathos $0 $*

As simple as that.  It has one known deficiency, which I can't think
of a nice fix for: if you are in the directory containing the frontend
when you run it, then it gets exec'd with a relative pathname and the
script won't work.  In practice this doesn't present a problem.

It illustrates a neat technique for eliminating export of variables
(useful here since I often use pathos in a context that will end
up spawning an interactive shell somewhere down the track).  The
reason the variables all have funky names starting with underscore
is to minimise the chances of one of the variables clashing with
the name of the command you want to execute (i.e., the name of
the frontend), because in that case my trick with "whatis" won't
work right.  I did try, ages ago, to convince Byron that whatis
needed to take options so that I wouldn't need to do this, but
he wouldn't wear it, so...

(Like:

	whatis -e	shows only an executable
	whatis -v	shows only a variable
	whatis -f	shows only a function

Then I could have just used whatis -e and gone to a lot less
trouble -- and not needed funky names.)

Enjoy.

OK,
John.

#!/full/path/to/rc

#
# usage: pathos /full/path/to/command [args]
#
# The idea is that often we want to supersede a command that's further
# down the path.  This gives us the same function in a script -- pick
# up the command of the same name further along -- that we can get by
# using `builtin' in a function.
#

_Vars = ( _Vars _me _dir _cmd _tpath _chop _fatal )

_me = ` { basename $0 }

fn _fatal {
	echo $_me ^ : $* >[1=2]
	exit 1
}

if ( ~ $#* 0 )
	_fatal usage: $_me /full/path/to/command '[args]'

if ( ! ~ $1 /* )
	_fatal first argument must be a full pathname

_dir = ` { dirname $1 }
_cmd = ` { basename $1 }
shift

if ( ! ~ $_dir $path )
	_fatal can''''t find directory $_dir in path

if ( ~ $_cmd $_Vars )
	_fatal command name $_cmd matches an internal variable or function

fn _chop {
	shift
	_tpath = $*
}

_tpath = $path
for ( p in $path ) {
	_chop $_tpath
	if ( ~ $p $_dir )
		break
}
p = ()

if ( ~ $#_tpath 0 )
	_fatal directory $_dir is the last one in the path


if ( ! path = $_tpath $_cmd = () whatis $_cmd >/dev/null >[2=1] )
	_fatal command $_cmd not found in path fragment $_tpath

pid = ` { path = $_tpath $_cmd = () whatis $_cmd }		# chortle

for ( v in $_Vars ) $v = ()
v = ()
fn _chop
fn _fatal

exec $pid $*