Skip site navigation (1)Skip section navigation (2)
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>