1coproc(1F) FMLI Commands coproc(1F)
2
6 coproc, cocreate, cosend, cocheck, coreceive, codestroy - communicate
7 with a process
8
10 cocreate [-r rpath] [-w wpath] [-i id] [-R refname]
11 [-s send_string] [-e expect_string] command
12 cosend [-n] proc_id string
15 cocheck proc_id
18 coreceive proc_id
21 codestroy [-R refname] proc_id [string]
24
27 These co-processing functions provide a flexible means of interaction
28 between FMLI and an independent process; especially, they enable
29 FMLI to be responsive to asynchronous activity.
30 The cocreate function starts command as a co-process and initializes
33 communications by setting up pipes between FMLI and the standard input
34 and standard output of command. The argument command must be an exe‐
35 cutable and its arguments (if any). This means that command expects
36 strings on its input (supplied by cosend) and sends information on its
37 output that can be handled in various ways by FMLI.
38 The cosend function sends string to the co-process identified by
41 proc_id via the pipe set up by cocreate (optionally wpath), where
42 proc_id can be either the command or id specified in cocreate. By
43 default, cosend blocks, waiting for a response from the co-process.
44 Also by default, FMLI does not send a send_string and does not expect
45 an expect_string (except a newline). That is, it reads only one line of
46 output from the co-process. If -e expect_string was not defined when
47 the pipe was created, then the output of the co-process is any single
48 string followed by a newline: any other lines of output remain on the
49 pipe. If the -e option was specified when the pipe was created, cosend
50 reads lines from the pipe until it reads a line starting with
51 expect_string. All lines except the line starting with expect_string
52 become the output of cosend.
53 The cocheck function determines if input is available from the process
56 identified by proc_id, where proc_id can be either the command or id
57 specified in cocreate. It returns a Boolean value, which makes cocheck
58 useful in if statements and in other backquoted expressions in Boolean
59 descriptors. cocheck receives no input from the co-process; it simply
60 indicates if input is available from the co-process. You must use core‐
61 ceive to actually accept the input. The cocheck function can be called
62 from a reread descriptor to force a frame to update when new data is
63 available. This is useful when the default value of a field in a form
64 includes coreceive.
65 The coreceive function is used to read input from the co-process iden‐
68 tified by proc_id, where proc_id can be either the command or id speci‐
69 fied in cocreate. It should only be used when it has been determined,
70 using cocheck, that input is actually available. If the -e option was
71 used when the co-process was created, coreceive will continue to return
72 lines of input until expect_string is read. At this point, coreceive
73 will terminate. The output of coreceive is all the lines that were read
74 excluding the line starting with expect_string . If the -e option was
75 not used in the cocreate, each invocation of coreceive will return
76 exactly one line from the co-process. If no input is available when
77 coreceive is invoked, it will simply terminate without producing out‐
78 put.
79 The codestroy function terminates the read/write pipes to proc-id,
82 where proc_id can be either the command or id specified in cocreate. It
83 generates a SIGPIPE signal to the (child) co-process. This kills the
84 co-process, unless the co-process ignores the SIGPIPE signal. If the
85 co-process ignores the SIGPIPE, it will not die, even after the FMLI
86 process terminates (the parent process id of the co-process will be 1).
87 The optional argument string is sent to the co-process before the co-
90 process dies. If string is not supplied, a NULL string is passed, fol‐
91 lowed by the normal send_string (newline by default). That is, code‐
92 stroy will call cosend proc_id string: this implies that codestroy will
93 write any output generated by the co-process to stdout. For example, if
94 an interactive co-process is written to expect a "quit" string when the
95 communication is over, the close descriptor could be defined;
96 close=`codestroy ID 'quit' | message` and any output generated by the
97 co-process when the string quit is sent to it via codestroy (using
98 cosend) would be redirected to the message line.
99 The codestroy function should usually be given the -R option, since you
102 may have more than one process with the same name, and you do not want
103 to kill the wrong one. codestroy keeps track of the number of refnames
104 you have assigned to a process with cocreate, and when the last
105 instance is killed, it kills the process (id) for you. codestroy is
106 typically called as part of a close descriptor because close is evalu‐
107 ated when a frame is closed. This is important because the co-process
108 will continue to run if codestroy is not issued.
109 When writing programs to use as co-processes, the following tips may be
112 useful. If the co-process program is written in C language, be sure to
113 flush output after writing to the pipe. (Currently, awk(1) and sed(1)
114 cannot be used in a co-process program because they do not flush after
115 lines of output.) Shell scripts are well-mannered, but slow. C language
116 is recommended. If possible, use the default send_string, rpath and
117 wpath. In most cases, expect_string will have to be specified. This,
118 of course, depends on the co-process.
119 In the case where asynchronous communication from a co-process is
122 desired, a co-process program should use vsig to force strings into the
123 pipe and then signal FMLI that output from the co-process is avail‐
124 able. This causes the reread descriptor of all frames to be evaluated
125 immediately.
126
128 cocreate options are:
129 -r rpath If -r is specified, rpath is the pathname from
131 which FMLI reads information. This option is usu‐
132 ally used to set up communication with processes
133 that naturally write to a certain path. If -r is
134 not specified, cocreate will choose a unique path
135 in /var/tmp.
136 -w wpath If -w is specified, wpath is the pathname to which
139 cosend writes information. This option is usually
140 used so that one process can talk to many different
141 FMLI processes through the same pipe. If -w is not
142 specified, cocreate will choose a unique path in
143 /var/tmp.
144 -i id If -i is specified, id is an alternative name for
147 the co-processinitialized by this cocreate. If -i
148 is not specified, id defaults to command. The argu‐
149 ment id can later be used with the other co-pro‐
150 cessing functions rather than command. This option
151 is typically used, since it facilitates the cre‐
152 ation of two or more co-processes generated from
153 the same command. (For example, cocreate -i ID1
154 program args and cocreate -i ID2 program differ‐
155 ent_args).
156 -R refname If -R is specified, refname is a local name for the
159 co-process. Since the cocreate function can be
160 issued more than once, a refname is useful when the
161 same co-process is referenced a second or subse‐
162 quent time. With the -R option, if the co-process
163 already exists a new one will not be created: the
164 same pipes will be shared. Then, refname can be
165 used as an argument to the -R option to codestroy
166 when you want to end a particular connection to a
167 co-process and leave other connections undisturbed.
168 (The co-process is only killed after codestroy -R
169 has been called as many times as cocreate -R was
170 called.)
171 -s send_string The -s option specifies send_string as a string
174 that will be appended to all output sent to the co-
175 process using cosend. This option allows a co-
176 process to know when input from FMLI has com‐
177 pleted. The default send_string is a newline if -s
178 is not specified.
179 -e expect_string The -e option specifies expect_string as a string
182 that identifies the end of all output returned by
183 the co-process. (Note: expect_string need only be
184 the initial part of a line, and there must be a
185 newline at the end of the co-process output.) This
186 option allows FMLI to know when output from the
187 co-process has completed. The default expect_string
188 is a newline if -e is not specified.
189 cosend options are:
193 -n If the -n option is specified, cosend will not wait for a
195 response from the co-process. It simply returns, providing no
196 output. If the -n option is not used, a co-process that does not
197 answer will cause FMLI to permanently hang, waiting for input
198 from the co-process.
199
202 Example 1 Sample commands
203 .
205 .
206 .
207 init=`cocreate -i BIGPROCESS initialize`
208 close=`codestroy BIGPROCESS`
209 .
210 .
211 .
212 reread=`cocheck BIGPROCESS`
213 name=`cosend -n BIGPROCESS field1`
215 .
216 .
217 .
218 name="Receive field"
219 inactive=TRUE
220 value=`coreceive BIGPROCESS`
221
225 See attributes(5) for descriptions of the following attributes:
226 ┌─────────────────────────────┬─────────────────────────────┐
231 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
232 ├─────────────────────────────┼─────────────────────────────┤
233 │Availability │SUNWcsu │
234 └─────────────────────────────┴─────────────────────────────┘
235
237 awk(1), cat(1), sed(1), vsig(1F), attributes(5)
238
240 If cosend is used without the -n option, a co-process that does not
241 answer will cause FMLI to permanently hang.
242 The use of non-alphabetic characters in input and output strings to a
245 co-process should be avoided because they may not get transferred cor‐
246 rectly.
247SunOS 5.11 5 Jul 1990 coproc(1F)