Re: es %dup

[Paul Haahr <haahr@mv.us.adobe.com>]

first off, Donn's right about prim-io.c's incorrect use of mvfd where we meant
cpfd in prim-io.c:redir(), and we'll fix that in the next version.

second, on the combination of exec {} and %dup:  this raises hard issues.
Byron and i just talked about it, and neither of has thought about that
case before, at least in enough depth to figure out what should happen
in the ideal shell.  (on a side note, es and rc seem to behave the same
way as most other shells---that is, what happens depends on which file
descriptor you pick.)

my current feeling is that if a %dup is executed with a file descriptor
that es is using (for example, the history file or the script es is running),
es should move the file descriptor it's using around to clear it out for
the user.  it seems to me that one never want to dup the history file
and hand it as input to some program, especially since there is no way
other than trial and error to get at it.

anyhow, i think we will be able to implement those semantics, so expect
them in 0.7.  here's a question though, what should this do?

	echo ls > foo
	echo 'exec {<foo}' | es

here's what is does in a couple of cases

;; echo ls > foo
;; echo 'exec <foo' | rc
CHANGES         es.h            glom.c          makefile        parse.y         prim.h          stdenv.h        tree.c          y.output
closure.c       eval.c          heredoc.c       match.c         parse.y-        print.c         str.c           trip.es
config.h        except.c        initial.es      mkfile          parse.y-old     print.h         syntax.c        util.c
conv.c          foo             input.c         mkinitial       prim-ctl.c      proc.c          syntax.h        var.c
dict.c          gc.c            input.h         mksignal        prim-etc.c      signal.c        term.c          vec.c
doc             gc.h            list.c          obj.next        prim-io.c       split.c         todo            version.c
errors          glob.c          main.c          open.c          prim.c          status.c        token.c         which.c
;; echo 'exec <foo' | sh
CHANGES         es.h            glom.c          makefile        parse.y         prim.h          stdenv.h        tree.c          y.output
closure.c       eval.c          heredoc.c       match.c         parse.y-        print.c         str.c           trip.es
config.h        except.c        initial.es      mkfile          parse.y-old     print.h         syntax.c        util.c
conv.c          foo             input.c         mkinitial       prim-ctl.c      proc.c          syntax.h        var.c
dict.c          gc.c            input.h         mksignal        prim-etc.c      signal.c        term.c          vec.c
doc             gc.h            list.c          obj.next        prim-io.c       split.c         todo            version.c
errors          glob.c          main.c          open.c          prim.c          status.c        token.c         which.c
;; echo 'exec <foo' | csh
exec: Too few arguments.
;; 

now it seems to me like this is wrong:  that is, in these examples, stdin (fd 0)
is owned by the shell and it shouldn't be touched by the user.

comments, anyone?