Mike Gerdts wrote:
> On 6/6/07, Roland Mainz <roland.mainz at nrubsig.org> wrote:
> > * Use builtin commands if the shell provides them. For example ksh93s+
> > (ksh93, version 's+') delivered with Solaris supports the following
> > builtins:
>
> This seems to favor the use of never specifying the full path to all
> of your commands, rather set PATH.
Right... specifing the full path is ineffient for seveal reasons
including that most modern shells cache the location of the last called
command with that name anyway. Specifying full paths should be _avoided_
in ksh93/bash shell scripts unless there is a very good reason for that
(well, the usual hit&&run tactic to execute exactly one command (e.g.
ksh93 -c 'rm -f foo') will be faster by specifying the full path because
you save the full ${PATH} lookup... but that's not the way how shell
scripts are usually written (except their use/abuse in Makefiles... ;-(
)) - otherwise you trigger much more syscalls than neccesary.
> Builtins can then be picked up
> automatically without thinking about it.
Only if they are enabled by default. And those enabled by default in
Solaris ksh93 as defined by PSARC 2006/550 are bound to a specific path
(e.g. they will be executed in place of the normal version if the shell
lookup in PATH matches the path to which the builtin is bound to - for
example the ksh93 builtin for "mkdir" (which is bound to
"/usr/bin/mkdir") will only be executed if the shell scans ${PATH} and
would execute the native /usr/bin/mkdir) and are tested for 100%
compatibilty with their native vesions.
> > chown
>
> How does this work?
The same way as the native command works...
> Surely ksh93 doesn't install setuid by default...
Solaris "chown" isn't a setid application:
-- snip --
$ ls -l /usr/bin/chown
-r-xr-xr-x 1 root bin 13196 Mar 25 16:58 /usr/bin/chown
-- snip --
> Does it try to use the builtin then try chown in $PATH if it gets
> EPERM?
No... why should it call the native version in that case ?
> > * Using -p" for starting non-interactive shell scipts is AFAIK a NO-OP,
> > e.g.
> > -- snip --
> > #!/bin/ksh -p
> > -- snip --
> > should be replaced with
> > -- snip --
> > #!/bin/ksh
> > -- snip --
>
> I've recently been burned by this one. lucreate or luupgrade (I
> forget which) blew up due to missing -p and having some questionable
> stuff in the file pointed to by $ENV.
See
http://mail.opensolaris.org/pipermail/shell-discuss/2007-June/000470.html
- are you _sure_ that the script set in ENV is executed _within_ the
"lucreate"/"luupgrade" scripts ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
