Re: rc.d/rndctl

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 4 Nov 2008 08:59:43 +0200
    From:        Alan Barrett <apb%cequrux.com@localhost>
    Message-ID:  <20081104065943.GU356%apb-laptoy.apb.alt.za@localhost>

  | For normal commands, "VAR=value cmd args" sets the variable for the
  | duration of the command and reinstates the old value afterwards, but
  | for special built-in commands it sets the variable permanently.

I certainly see where it says that, but IMO, that's insane, or perhaps
an instance of an inadvertant side effect - that is, defining these
special builtin commands (ones that are basically syntax for the shell,
rather than normal commands), and then observing that for many of that set,
var assignments are useless as the command cannot possibly use any
var value, so a temporary assignment would be meaningless.

AFter all, in a command like

        X=y break

what would be the point of the assignment if it remained only for the
break command, which is never going to care what $X happens to be
(regardless of what X happens to be - even PATH IFS etc).

But for a few of the set (. eval exec) this is just not true, and
having the temporary assignment rules as for normal commands (including
others that have to be implemented without forking, like "cd") would
make much more sense.  "exec" might seem like a weird case, as after
it, the shell no longer exists to care what its variables are set to -
except that exec can fail, there should not really be a difference
between
        X=y ls
and
        X=y exec ls
where for some reason the exec fails and execution continues.

For eval, as the original code showed, it is even more useful.  The
same for processing the . command where the script can (or should be
able to be) read with vars set one way, and then the shell continue
with original settings).

Personally I'd get rid of the special case handling of var assignments
on special builtins completely - it is never necessary, if one really
wanted to do

        X=y break

(break from the loop/whatever with var X set to y afterwards) one can always
just do X=y; break (or perhaps { X=y; break; } after a && or something.)

But I guess we just get to live with this nonsense for now...

kre