cottrell@NBS-VMS (03/21/85)
/* [ jpage@rruxe.uucp wants to set PS1 in [k]sh when he does 'cd' ] Perhaps this is a good time to repost an earlier article, as I didn't receive as much comment as I liked. The lack of aliases & history in 'sh' is most disturbing. It all started when I read the BSTJ article by Kernighan & Pike (got it right this time!) that bemoaned the multiplicity of options on 'cat', Berkeley 'ls', & then went on to attack the history mechanism of 'csh' as being specific only to 'csh' & not working for ALL input, including programs invoked by [c]sh. After fuming at the authors willingness to trade off useful features for abstract purity, I did some thinking, and came up with the following bizarre ideas. Write a program (prog) which copies its stdin to stdout unless certain escape characters (which implement history, aliases, local cmd editing, anything else you want). Type 'prog | sh -i'. Whenever 'prog' sees the user type 'cd <anything>\n' it stuffs ';PS1="`pwd` %' before the '\n'. Thus, the prompt is always the current directory! This will work MOST of the time, but there are exceptions. VI will not work unless its stdin is a tty. Therefore, our prog must intercept any references to VI (or any other uppity interactive program), fork & exec it itself after redirecting stdin back to the tty. There are other things that might be done, such as saving/restoring all stty modes before/after any such interactive program executes, forking the subshell directly from prog, always running in cbreak mode, etc. Please note that this is SYS V we're talking about. No pseudo tty's are available. Now that the cat's out of the bag, let's talk about ways to skin it. What else does 'prog' have to watch out for? jim cottrell@nbs */
robert@gitpyr.UUCP (Robert Viduya) (03/25/85)
> > Please note that this is SYS V we're talking about. No pseudo tty's > are available. > Actually, System V Release 2 has pseudo tty's. If you've got a manual available, look at sxt(7). I haven't personally played with them, but they don't look as flexible as BSD's pseudo tty's (you have to grab them in groups of 8), but they do look a real tty to any program talking to them. The only thing that uses them in SysVR2 currently is shl(1), a program that allows you to have upto 8 shells running and to be able to switch from one to another. It appears to be AT&T's answer to csh's job control; I personally see it as an kludge. robert -- Robert Viduya Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
ron@BRL-TGR (Ron Natalie) (03/29/85)
They are not Pseudotty's in the Berkeley sense. A Berkeley PTY has two sides, the side that looks like a tty to an application, and the control side which is connected to your communications program like telnetd or mpx or whatever. The System V SXT devices multiplex multiple "TTY devices" into a single channel going to a terminal. You can't divert the backend to a program, it always goes to the terminal that did the LINK ioctl to pick up the group of pty's. -Ron