Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!lll-tis!oodis01!uplherc!esunix!bpendlet From: bpendlet@esunix.UUCP (Bob Pendleton) Newsgroups: comp.unix.wizards Subject: child process current directory and wild shell ravings Message-ID: <889@esunix.UUCP> Date: 28 Jun 88 21:54:47 GMT Organization: Evans & Sutherland, Salt Lake City, Utah Lines: 54 A while back I asked if anyone knew how to find the current working directory of a child process. The answers were generally negative, with a few people saying I shouldn't want to do that. After looking at this problem for a while I've come to the conclusion that the structure of all the shells I've ever used or read about is wrong. I don't claim to know about every shell, so if there exists a non broken shell please educate me, instead of incinerating me. I recently wrote a little hack I call ile, for the Input Line Editor. It is a simple program that uses a pty to wedge itself between the tty and a users program. It gives you a nice one line editor with history recall. In the key binding I use, it is of course customizable, ^P moves back one line in the history buffer, ^N moves forward one line, and a lot of other standard emacs keybindings do emacs like things to the current command line. This little tool gives me history and command line editing in any program run under it. Most of the time I run csh under it. ile also does some file name completion. But it can't complete relative paths like ./ and ../ because it doesn't know the current working directory of the program running under it. ile is smart enough to get out of the way when the pty is put into CBREAK or RAW mode, but I haven't figured out how to tell if csh is running or a user program is running so I can't reliably ask csh for the current working directory. So what does this have to do with the claim that all the shells I know of are broken? Well... if shells were structured as an environment server, an input line editor, a command line interpreter, and a batch language interpreter (the last two could be one program) each a separate but communicating process, then I could have the input line editor I want and the command language I want. Mix and match to my desire. Each of these programs would be a single function program instead of a complex multifunction monolithic program. I know that mach provides an environment server, is anyone working on a shell structured the way I've described? Does anyone have an environment server that runs under 4.3BSD and its SUNOS and ULTRIX relatives? What are the gotchas in redefining getenv and putenv? Would you have to redefine all the exec calls also? Bob P. P.S. Oh, yeah. Anyone found a solution to the original question? A solution that doesn't require hacking the kernel or the shell? -- Bob Pendleton @ Evans & Sutherland UUCP Address: {decvax,ucbvax,allegra}!decwrl!esunix!bpendlet Alternate: utah-cs!utah-gr!uplherc!esunix!bpendlet I am solely responsible for what I say.