ber@enea.UUCP (Bjorn Eriksen) (06/09/85)
I'm posting this for a guy (without net access) that has problems
with process communication in System V. What he needs is something
like the script command in 4.[1-2]BSD.
This is how he explains the problem:
I have been advised to contact you on some Unix problems
I have. As you know I have been involved in questions I
can not sort out myself.
I develop a system based on dialog switching technology
which calls for "Mire".
The Mire program controls application systems by (program
to program) two-pipes read/write communication.
The Mire control program forks a child, redirects pipes to
child stdin/stdout, next exec the application. These traditional
parent-to-child interprocess pipes do not work with screen
handling programs, like "vi", "more" etc.
I need some sort of paren-to-child interface to get under
control applications using screen handlers.
The Mire control program reads a response from the exec'd
child application, compare it with a string of text and
depending on if the comparision is true, sends the new message
to the application system, otherwise kills the application
and sends response to end user.
I can change pipes to Mire-file-child communication if that
helps me but I can not find a file or "virtual terminal" which
is suitable for my purpose.
Well System V wizards, how do you do a front end program that has total
terminal control even over a raw mode "application" like vi.
Some programs don't like to be piped at, so they have to fooled somehow.
I don't know System V that well, so any ideas would be appreciated.
Please also include info about what "version" of System V (that is machine)
it's supposed/not suppused to work on. It's not System V release 2.
--
Bjorn Eriksen
ENEA DATA Sweden
UUCP: {seismo,decvax,philabs}!{mcvax,ukc,unido}!enea!ber
ARPA: decvax!mcvax!enea!ber@berkeley.arpa
mcvax!enea!ber@seismo.arpagwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (06/16/85)
> Well System V wizards, how do you do a front end program that has total > terminal control even over a raw mode "application" like vi. > Some programs don't like to be piped at, so they have to fooled somehow. The general answer is, you can't do that in UNIX System V Release 2. I suspect it would be easy enough with stream I/O; rumor has it that stream I/O may be supported in the next release, which may be available around the end of this year. But this is just a rumor. UNIX processes were not supposed to care whether their input was from a terminal or not..
brent@phoenix.UUCP (Brent P. Callaghan) (06/20/85)
> Well System V wizards, how do you do a front end program that has total > terminal control even over a raw mode "application" like vi. > Some programs don't like to be piped at, so they have to fooled somehow. Have you tried tee stdin | vi something | tee stdout It captures the I/O despite it being raw - and vi doesn't seem to mind a bit i.e. you can't tell the tees are there! It seems that vi's ioctl calls to get into raw mode affect the reads and writes of tee! The shell checks whether its reading from a tty and omits the PS1 prompts. tee stdin | sh | tee stdout is rather difficult to use. -- Made in New Zealand --> Brent Callaghan AT&T Information Systems, Lincroft, NJ {ihnp4|mtuxo|pegasus}!phoenix!brent (201) 576-3475
guy@sun.uucp (Guy Harris) (06/20/85)
> UNIX processes were not supposed to care whether their input was from a > terminal or not.. If that's literally true, UNIX programs shouldn't go into (CBREAK/~ICANON) mode and expect the system to act any differently. Screen editors, however, expect their input to be generated by a human being as they run; there's not much point in running "vi" with its input coming from a program generating commands or from a file consisting of commands generated by a program. If you want an editor that can either be driven directly by a person or by a program, use "ed" - or "ex". Screen editors solve a different problem from "UNIX tools"; not all programs should be UNIX tools. You can put a screen front-end on top of an "ed"-style editor, letting the editor program run as a "UNIX tool" and put the sane user interface in a separate process. Guy Harris
arnold@gatech.CSNET (Arnold Robbins) (06/21/85)
> [.....] > The shell checks whether its reading from a tty and omits > the PS1 prompts. > > tee stdin | sh | tee stdout > > is rather difficult to use. > -- > > Made in New Zealand --> Brent Callaghan > AT&T Information Systems, Lincroft, NJ > {ihnp4|mtuxo|pegasus}!phoenix!brent > (201) 576-3475 If you give the shell the -i flag (interactive), it will then assume that it should prompt. I haven't tried it, but I'll bet that it'll work. -- Arnold Robbins CSNET: arnold@gatech ARPA: arnold%gatech.csnet@csnet-relay.arpa UUCP: { akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold How come nobody likes good ideas when they don't come up with them?
levy@ttrdc.UUCP (Daniel R. Levy) (06/22/85)
guy@sun.uucp (Guy Harris) in <2325@sun.uucp>: > > ... > >expect their input to be generated by a human being as they run; there's not >much point in running "vi" with its input coming from a program generating >commands or from a file consisting of commands generated by a program. If >you want an editor that can either be driven directly by a person or by a >program, use "ed" - or "ex". Screen editors solve a different problem from > > ... > > Guy Harris I thought that 'ex' and 'vi' WERE the same program! /usr/bin/ex and /usr/bin/vi are the same file on my system, just two different links (the program knows which one it was via arg0). Yes, yes, I know, we were talking about two KINDS of editors (and while on that subject, wouldn't 'sed' be the ideal "editor" to interface with another program? O.K. I guess it would be kind of hard to feed it except via a named pipe or a temp file, so maybe it's not ideal, but it is sure devoid of any interactiveness) but I wonder if Guy knew that ex and vi are identical except in name .... :-) here's hacking, dan levy at&t teletype corporation skokie, illinois
scotth@grpwre.UUCP (Scott Herzinger) (06/25/85)
> there's not > much point in running "vi" with its input coming from a program generating > commands or from a file consisting of commands generated by a program. > Guy Harris One point in running any program whose quality is to be assured, including screen-oriented editors, with its input coming from a file is in automating the testing process. A screen-oriented language-directed editor in whose development I participated could not have been tested in a timely way without using this technique. -- Scott Herzinger, Groupware Systems ...!{ucbvax,decvax,ihnss}!tektronix!reed!grpwre!scotth {allegra,purdue,cbosg}
guy@sun.uucp (Guy Harris) (06/26/85)
> > there's not > > much point in running "vi" with its input coming from a program generating > > commands or from a file consisting of commands generated by a program. > > Guy Harris > > One point in running any program whose quality is to be assured, > including screen-oriented editors, with its input coming from a file is > in automating the testing process. A screen-oriented language-directed > editor in whose development I participated could not have been tested > in a timely way without using this technique. However, there may be some aspects of its behavior that can't be tested by running it from a file. (An example - an editor which can offload some of the low-level character processing to a smart terminal. Your front end tester will have to emulate the smart terminal - and even that may not be enough, if you're also trying to debug the terminal's behavior.) Also, that won't test its terminal mode setting/getting behavior (if it's a screen editor, it sets the terminal mode to something other than the default). If you want to *really* test that, or if you want to get a transcript of a session, something like "script" is the best choice - it eliminates one variable from the testing procedure (the program's input is at least coming from something it thinks is a terminal). Besides, these are all special cases. The point still remains that designing a screen editor so that it runs "just as well" with its input redirected to a pipe or file doesn't serve much purpose; if you want an editor that talks to programs or files, write an editor intended to be talked to by computer programs, not people. People are good at things that computers are very bad at and *vice versa*, so the quality of the user interface of an interactive tool should *not* be sacrificed in the name of "making it work with its input redirected". Guy Harris
mike@enmasse.UUCP (Mike Schloss) (07/01/85)
> The point still remains that > designing a screen editor so that it runs "just as well" with its input > redirected to a pipe or file doesn't serve much purpose; if you want an > editor that talks to programs or files, write an editor intended to be > talked to by computer programs, not people. People are good at things that > computers are very bad at and *vice versa*, so the quality of the user > interface of an interactive tool should *not* be sacrificed in the name of > "making it work with its input redirected". > What about all the "novice" and not so novice users who dont want to be bothered learning 14 different editors for different purposes. They learn the one they use primarily (VI) well and want to be able to use it for their occasional repetative editing scripts. Who cares if it is fast or produces bogus messages as long as they dont have to spend hours tracking down documentation and learning a new editor which they are going to forget anyway. No qualities have to be sacrificed if the program is well thought out in advance and properly implemented. The excuse that it takes less time to do it sloppily and no one will notice and if they do they shouldnt be doing that anyway just doesn't cut it. Mike Schloss
guy@sun.uucp (Guy Harris) (07/02/85)
> What about all the "novice" and not so novice users who dont want to be > bothered learning 14 different editors for different purposes. They learn > the one they use primarily (VI) well and want to be able to use it for > their occasional repetative editing scripts. Well, the article mentioned having a screen editor which used a line editor underneath it; where are the 12 other editors you're referring to? And do you know anybody who uses "vi" (not "ex", remember, we're talking about screen editors) to do their scripts? If it had a "learn" mode, maybe, just maybe... > No qualities have to be sacrificed if the program is well thought out > in advance and properly implemented. Do you have any examples to offer? What kind of repetitive operations does this "well thought out and properly implemented" editor provide? How do you write scripts - is there a "learn mode" in which it remembers keystrokes, or is there a "programming language" that you write these scripts in, or do you just stuff the bytes that would normally be generated by your terminal when you typed the keystrokes of the script into a file? (If the latter, I fear that editing and debugging scripts will be a *real* bear...) And what if your editor accepts commands from something other than the typewriter portion of the keyboard? Which codes for the cursor keys does it use? How can you indicate mouse input in a file? (No, entering the byte codes that your mouse software presents to the program, assuming that your OS prsents mouse actions in the standard input stream as byte codes, doesn't cut it - especially for the novice user.) Guy Harris
root@bu-cs.UUCP (Barry Shein) (07/02/85)
Arghh...oh well. I for one am still interested...has anyone done anything like 4.2bsd script under SYS-V. I'll remind the group of the original question cuz in the months of digression on the topic the rest of us have gotten our new SYSV R2 systems with sxt's and vsxts etc, tho maybe the answer is still no (then, has anyone added pty's to SYSV yet?) -Barry Shein, Boston University P.S. My students need this and thank you in advance.