Re: es %dup

[Donn Cave <donn@u.washington.edu>]

|> I thought you were suggesting that ``exec <foo'' should
|> mean  ``push foo onto input''
|
| as an aside: this functionality is avaible with the predefined function ".",
| as in rc and sh.

Lots of potential confusion over what "input" means.  I'm just advocating
a distinction (to which heretofore all shells have been oblivious) between
command input and data input.  When the shell starts, it assigns command
input <== data input (lacking a file argument), but the user should be able
to change data input, using "exec", without changing the command input stream.

As Scott points out, this can be expressed as something like
        (with-open-file (*standard-input* "foo")
                (my-cat)
        )
(which by itself is just saying "my-cat < foo"), if it's done automatically
for all commands until further notice, but it's hard to see what that buys.
My feeling is that by allowing the user to manipulate fds, directly, but
protecting the internal fds by duping them out of the way when there's a
collision, you add some sanity along with a feature.

As for pushing vs. setting the fd, I think I'm talking about setting it.
I need to set 0 in the dot-file, and have it stay on that stream (the tty)
after exiting the dot-file, and under no circumstances am I interesting in
seeing unit 0 ever return to the command input stream.

|> You should have direct access to
|> open, close, read, write, etc.
|
| unclear.  read & write are still controversial, in my mind.  open, close,
| etc. are provided, but insufficient, because you need to pick some fd
| to work on.  as Donn notes, it's probably reasonable to add something
| which returns an unused fd number that you can then use in open and
| create calls.  how about
| 	<>{%newfd}
| ?

Well, I thought that was your idea, but it's sure to be used.  Lots of
Bourne shell scripts do this kind of thing, and they pick some arbitrary
file descriptor and hope they're not clobbering anything.  Getting a handle
variable is a step in the right direction.  As for read and write, I'd like
to see read, but "echo" seems like it's already doing the write part.  I
mean, as in "exec {>[3] foo}; echo data >[1=3]".  Read would be handy, though,
for people who don't want to carry around a C program that does the unbuffered
reading this needs.

	Donn Cave, University Computing Services, University of Washington
	donn@cac.washington.edu