child process current directory and wild shell ravings

[Root Boy Jim]

   From: Bob Pendleton <bpendlet at 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 at 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?