Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!dg!rec From: rec@dg.dg.com (Robert Cousins) Newsgroups: comp.unix.wizards Subject: Re: What kinds of things would you want in the GNU OS? Summary: Why invent incompatibilities when other people have done it for you? Message-ID: <190@dg.dg.com> Date: 8 Jun 89 16:00:43 GMT References: <106326@sun.Eng.Sun.COM> <4315@ficc.uu.net> <338@arc.UUCP> <40062@cmcl2.NYU.EDU> <4438@ficc.uu.net> Reply-To: rec@dg.UUCP (Robert Cousins) Organization: Data General, Westboro, MA. Lines: 52 In article <4438@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <40062@cmcl2.NYU.EDU>, edler@cmcl2.NYU.EDU (Jan Edler) writes: >> We've been a bit indecisive about the exact form of pathname >> extension. My current preference is to say that "/@" at the beginning >> of a pathname, followed by a file descriptor number (as a string of >> digits) and a "/", means to take the object referred to by the file >> descriptor as the search starting point. >This is an intriguing idea. I, myself, would prefer to make '@' by itself >at the beginning of a file name a special token. This solves the problem >of files beginning with @ in /tmp... >I'd generalise it beyond directories, too. That way you could open '@5' to >clone a descriptor. This is similar to the /dev/fd/5 syntax described by >people using more recent bell releases, except that you can't chdir to >/dev/fd/5/workdir. >-- >Peter da Silva, Xenix Support, Ferranti International Controls Corporation. >Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. >Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com. AOS/VS from Data General has the concept of default files. These files being with the character @ and are "special." Whenever a program attempts to open @output, the OS converts this file name to an already established file name (the terminal by default). However, the value of @output can be changed at the CLI (shell) level. This serves a function similar to a cross between environment variables and I/O redirection. It is, however, VERY useful for many tasks. Perhaps a better solution would be to use some special character to signal a non-filesystem request to be passed to a another task. THis would allow special filesystems to be implemented as dedicated tasks and then used transparently. The task would simply initialize and then advertise itself to the OS in some standard fashion. Special networks, unique hardware and all manner of new features could be built on top of the current semantics then. To do this, however, I would suggest something of the form: / so that path semantics can be clearly used along with multiple adversting tasks. Just my $.02 worth. Robert Cousins Dept. Mgr, Workstation Dev't. Data General Corp. Speaking for myself alone.