Date: Sun, 15 Oct 1995 03:19:39 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: "Gasparovski / Daniel (ISE)" <u923168@student.canberra.edu.au> Cc: Warner Losh <imp@village.org>, hackers@freebsd.org Subject: Re: IPX now available Message-ID: <17386.813752379@time.cdrom.com> In-Reply-To: Your message of "Sun, 15 Oct 1995 17:09:22 %2B1000." <Pine.SOL.3.91.951015170014.19078A-100000@student.canberra.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> eg: have the shell fork off the process, give it a pty as controlling > terminal which will be handled by the shell, and by default show it's > output on the user's tty. Then, if a "bg >& make.out" is given, have the > shell open make.out and start writing the output there instead of the tty. > > It's not the most ideal solution, for example "ls" won't do the right > thing, but it's good enough for most, if not all, situations. Until you run out of PTYs.. :-) Really, (ab)using PTYs in such a fashion would almost certainly predicate reimplimenting them to be truly dynamic. If you need a PTY every time anyone needs to perform a "splice" operation then you're going to run out of them PDQ. It also grossly violates my sense of esthetics.. :-) Truly, if you think of the problem as implementing something more like a "cross bar" switch with a fairly sophisicated model of data "sources" and "sinks" then you're starting to talk more my language. Make any file dependency from a process refer to an object that can be reassigned, age and die, etc and you're really piquing my interest.. :-) > echo spam > file1 > file2 > > (which also needs shell intervention), and it's still actively being > developed by a very talented pool of programmers. Hmmm. I've heard a fair bit about zsh, yes. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17386.813752379>