Glenn Fowler wrote:
> On Thu, 6 Dec 2007 22:33:42 -0500 David Korn wrote:
> > > > ... if PATH is /usr/xpg4/bin:/usr/bin, a "ls" builtin is bound to
> > > > /usr/bin/ls
> > > > and the script should execute the "ls" builtin it will execute
> > > > /usr/xpg4/bin/ls
> > > > instead of the builtin command because /usr/xpg4/bin comes before
> > > > /usr/bin in
> > > > PATH.
>
> > I must be missing something. If ls is a builtin for /usr/bin/ls
> > but /usr/xpg4/bin comes before /usr/bin in PATH, then ls should run
> > /usr/xpg4/bin/ls, not the built-in version of /usr/bin/ls.
>
> > That is the whole point of binding a builtin to a path name rather than
> > just making ls a builtin.
>
> so Roland, is there a specific case where an alias.sh test fails for
> PATH=/usr/xpg4/bin:/usr/bin
> but works for
> PATH=/usr/bin
> ?
>
> I just tried the alias test both ways on sol11.sun4 and it passed both ways
Erm... the name "alias.sh" may be a bit misleading in this case: The
script is not the "alias.sh" script from the ksh93 test suite, it's an
Solaris OS/Net-specific script which "maps" a physical file like
/usr/bin/kill to the ksh/ksh93 "kill" builtin (take a look at
/usr/bin/kill on a Solaris machine - it's a shell script which calls the
/usr/bin/ksh "kill" builtin).
The problem is that if a builtin like "kill" (<--- example!!) is bound
to a specific path element then the original script (e.g.
-- snip --
cmd=`basename $0`
$cmd "$@"
-- snip --
) ... will crawl over all elements in ${PATH} and execute the first
command called "kill" it finds. If the "kill" script is itself called
/usr/bin/kill and the path contains /usr/xpg4/bin:/usr/bin then the
/usr/xpg4/bin/kill command will be executed by the /usr/bin/kill script
instead of the (intended) "kill" builtin bound to /usr/bin/kill
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
