Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!cs.umn.edu!uc!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott From: scott@nic.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: Laziness Message-ID: Date: 11 May 91 03:45:54 GMT References: <1991May3.230846.27038@cunixf.cc.columbia.edu> <665@rosie.NeXT.COM> Organization: Gustavus Adolphus College Lines: 88 Nntp-Posting-Host: nic.gac.edu In-reply-to: jmynatt@next.com's message of 6 May 91 18:56:54 GMTLines: 88 In article <665@rosie.NeXT.COM> jmynatt@next.com writes: In article <1991May3.230846.27038@cunixf.cc.columbia.edu> ta-aca@cunixb.cc.columbia.edu (Andrew C. Athan) writes: > > It is impotant to understand the difference between Terminal (or > Stuart) [[The App]] and the program that is running in the > Terminal window [[The Shell]]. It is the shell which needs to > "cd" Stuart/Terminal have nothing to do with details of what > the app in the window is doing (besides acting as one end of a pty). > > So ... the problem is communicating the "cd" command to > csh/ksh/bash/whatever. Probably the only generic guranteed to > work solution is to have the Services> item of which you speak > "type" a cd command into the window in question. You, as the > user of the Service, would have to make sure > your shell is at a prompt which can accept the "cd." If I write an app which runs a program such as 'csh/ksh/bash/whatever', I can invoke that program with control. If that means i issue a cd and a clear then so be it. Stuart and Terminal have a lot to do with the details of what the app in the window is doing. Stuart/ Terminal / Whatever then app object is, has complete control and can even do things like monitor what you are typing into the Text object (which sits between the window and the program ) and take appropriate action such as capturing typing rates for data entry applications. Well, sort of. When it comes down to it, though, Stuart and its ilk really do _not_ have much to do with what the subprogram does. The problem is manyfold. For one, you don't know what the subprogram is. Sure, it might be _named_ csh, but that doesn't mean anything - you can rename tcsh csh, and most things will work, but if Stuart makes assumptions about what csh will do, it will crash gloriously. It's even worse if you rename ksh sh, or bash sh, or even emacs vi. Secondly, without sophisticated artificial intelligence algorithms, you aren't going to be able to tell what the subshell is going to do, in general. Figuring out if an arbitrary subprogram is in such a state that a cd makes sense is certainly non-decidable without infinite resources. For instance, consider a subshell in which you ran rlogin to a remote system [a VAX], then hopped to another Unix host and ran emacs. How can Stuart have a chance to know what is and is not possible at this point? It can't. Thus, the user is going to have to have some brains, too (ie, only send the sequence when it makes sense). The user of the Service I was describing is the FileViewer. The Service responder (Stuart or Terminal) recognizes that it has been invoked by a service request (speaker/listener pair) and can get the information needed (directory path) and start up the appropriate program (csh/ksh/bash/whatever) and issue 'cd' commands or whatever. The Stuart/Terminal window opened can be a new one or a existing on (a feature which should be set by the user preferences). It would not be such a problem to open up a new window and do it. I think one could safely assume that the default subprogram will be a shell (sh, csh, or some variation), which would thus be able to accept the 'cd ...' that is sent by Stuart. It's the sending to an existing window that's problematic. Again, the simple solution is the only viable one - just send the damn command, and let the user worry about it. Hope this clears things up a bit. Well :-). This really doesn't clear things up like they could be, though. The best solution would be to have Workspace use the copy/paste stuff for the paths, too, and then there's not really any problem at all (I don't have to write a hack). Basically, right now we're considering fixing Stuart to supply some functionality that would be nice to have in the Workspace itself. But, what happens when we want it in Edit? In the Workspace's Shell window? In Mail? In Terminal? The fix obviously belongs in Workspace (I'm not saying it won't appear in Stuart eventually if it doesn't make the Workspace, just making a point). Hmm . . . consider the case where you don't want to cd to a directory, but you want to include a file's path as part of a command (for instance, as a parameter to a cp or a vi). Then, you just want the pathname, w/o the cd part. Wait! Now that I think of it, that's probably the general case, isn't it. Wow. OK, maybe that _will_ be there soon. Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad