bpendlet@esunix.UUCP (Bob Pendleton) (06/29/88)
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.
rbj@nav.icst.nbs.gov (Root Boy Jim) (07/12/88)
From: Bob Pendleton <bpendlet@esunix.uucp> 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. Well, in general, this is not a good thing to do, but you seem to have an application that makes it desirable. 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? You have to make some assumptions. If you are talking to a shell, you can simply intercept the cd commands and do them yourself. This requires `registering' all commands that change (or push or pop) directorys with ile. If you are talking to an applications program, which may change directorys *at will*, you need a command that ile will trap without passing to the application that will cause ile to change directorys itself, or just punt and don't use filename completion in that case. Note that if you do implement an ile cd command, you will have to retell the shell to cd whenever you see the shell's prompt. This can be confusing. Similar problems exist in emacs's shell mode. The distributed version attempts to maintain the current directory with `shell-cd-regexp', `shell-pushd-regexp', `shell-popd-regexp', and `shell-prompt-pattern'. It does not attempt to do filename expansion as distributed, but several versions have been posted to do so, and the run into exactly the same problem you have. Most notable is running ftp inside shell mode, as one of the ftp commands is `cd'. As far as running su is concerned, you could read the next line without echoing it, but then you'd have to check for `su -f command' etc. And that still wouldn't handle ftp passwords and other similar things. Perhaps a more general solution is an ile builtin that turns echoing/history on/off. Who wants to save vi/emacs keystrokes in the history list either? I suspect that the real place for line editing is either in the shell itsef (as in tcsh, ksh, (and brlsh?)) or in the kernel. 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. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement My name is in /usr/dict/words. Is yours?