Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.unix.wizards Subject: Re: Symbolic Links Message-ID: <6411@brl-smoke.ARPA> Date: Wed, 9-Sep-87 11:41:43 EDT Article-I.D.: brl-smok.6411 Posted: Wed Sep 9 11:41:43 1987 Date-Received: Fri, 11-Sep-87 03:53:27 EDT References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <6366@brl-smoke.ARPA> <599@murphy.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 21 In article <599@murphy.UUCP> dave@murphy.UUCP (Dave Cornutt) writes: >Then I guess we should get rid of all those pesky tty mode bits ... I realize you were being sarcastic, but actually the fact that the setting of the terminal handler modes by one process can affect another process's operation IS a problem, as everyone who has found their terminal left in a funny state by a sick or buggy process can attest. UNIX might have been better off with the state of the controlling terminal kept on a per-process basis (and the "stty" command built into the shell). There would be some problems implementing that, and it's too late now anyway, but it is a good example of the problem with the OS maintaining "modes". The reason for mentioning dual universes w.r.t. ".." interpretation is that the interpretation mode would have to be inherited, so that the shell-level "$ command ../file" would be handled per user wishes by "command". But note that the programmer of "command" may have decided to use ".." with the other interpretation in places not connecting with handling the argument. I don't see how you could reasonably have it both ways at the same time. Trying to provide a run-time choice of interpretation for ".." seems unworkable.