In article <58D04B65.3020106%eq.cz@localhost>, rudolf <netbsd%eq.cz@localhost> wrote:
Christos Zoulas wrote:
- why kill those only for 'start'? I guess it is only important for start,
but...
- I don't think think that the parens are needed; after all the cd command
is separate.
If i read it right, the _doit string is being evaled in the current
shell. I wanted the change to have minimal impact so i've added the
parens to unset the vars in a subshell to not affect the current shell
and rc functions that may by launched after the run_rc_command().
There are 2 cases, but let's take things one at a time:
1. Here we are running a $_precmd; without applying environment, nice,
and chroot, etc. Perhaps we should but we don't.
if ! eval $_precmd && [ -z "$rc_force" ]; then
return 1
fi
2. Now the two cases for Startup:
# setup the command to run, and run it
#
echo "Starting ${name}."
if [ -n "$_chroot" ]; then
_doit="\
2a. Here's the chroot case [case 1]; this will run:
${_env:+env $_env }\
${_nice:+nice -n $_nice }\
chroot ${_user:+-u $_user }${_group:+-g $_group }${_groups:+-G $_groups }\
$_chroot $command $rc_flags $command_args"
else
2b. This is the regular case, the chroot change does not need chdir since
it changes the root? Here we are already altering the shell context
with chdir and not restoring it...
_doit="\
${_chdir:+cd $_chdir; }\
${_env:+env $_env }\
${_nice:+nice -n $_nice }\
$command $rc_flags $command_args"
if [ -n "$_user" ]; then
_doit="su -m $_user -c 'sh -c \"$_doit\"'"
fi
fi
# if the cmd failed and force
# isn't set, exit
#
if ! eval $_doit && [ -z "$rc_force" ]; then
return 1
fi
3. Here's the postcmd, again with no modifiers:
# finally, run postcmd
#
eval $_postcmd
The same reason (minimal impact of the change) was for unsetting the
vars only for 'start' and that is indeed quite arbitrary, but now when i
read the other "case" branches, it seems to me that only in the 'start'
it has any sense. Or do you think it is useful for the "eval $_postcmd" too?
I don't think that we should be changing precmd and postcmd, because nobody
has complained about the current behavior. OTOH adding a subshell changes
the semantics of the command (i.e. if the command was meant to modify the
current shell context now it will not) so I think that the minimum impact
is to set the variables to empty in the env invocation.