Re: Bug? with builtin redirection

• Date: Thu, 21 Mar 1996 23:18:36 PST
• From:
  Christopher Unkel <cunkel@us.itd.umich.edu>
• cc: moo-cows.PARC@xerox.com
• Content-Type: TEXT/PLAIN; charset=US-ASCII
• In-Reply-to: <199603220551.VAA04164@wasteland.calbbs.com>

On Thu, 21 Mar 1996, Brian Buchanan wrote:

> 
> Forgot to cc my response to Christopher Unkel, so reposting it here so I
> don't get asked again:
> 
> Yes, this was under 1.8.0p2, and yes $server_options.protect_move existed
> and was set true.

I awakened just enough to reproduce it.  I agree--this is not how it 
should work.  For the benefit of those no more awake than I was:

(1.8.0p2, with force_callers() patch):

$server_options.protect_move = 1
#0:bf_move tnt rxd
 1:  player:tell("Now in bf_move.");
 2:  set_task_perms(caller_perms());
 3:  return args < 2 ? E_ARGS | move(@args[1..2]);

A real verb would presumably do something differently if args was three, 
but here we just want to find out what's going on.  As long as it's 
called with at least two arguments, it should work fine and disregard extras.

;move(#2, #61, "blah")

#-1:Input to EVAL, line 1:  Incorrect number of arguments
... called from built-in function eval()
... called from #57:eval_cmd_string (this == #2), line 18
... called from #57:eval*-d (this == #2), line 10
(End of traceback)

(notice #0:bf_foo is not involved).

Since one of the most desirable (and backwards compatible) ways to modify 
a built-in function is to add an extra optional argument that changes its 
behavior, this probably isn't how this should work.

  --Chris                           cunkel@engin.umich.edu
    ResComp Network Support Technician, Bursley Hall
    "Invisibility is in the eye of the beholder."
    Home Page: http://www-personal.engin.umich.edu/~cunkel/

• Re: Bug? with builtin redirection
• From: Brian Buchanan <brian@wasteland.calbbs.com>

• Prev: Re: Bug? with builtin redirection
• Next: RE: Bug? with builtin redirection
• Index: MOO-cows
• Thread: MOO-cows