-privileged programs when they need to. It is unsuitable for this
-purpose precisely because it enforces a strong separation between the
-calling and the called program, which is undesirable in this context.<P>
-
-Its facilities for restricting activities to running certain programs
-may at first glance seem to provide similar functionality to
-<kbd>sudo</kbd><A href="footnotes.html#2" name="fr2">[2]</A>. However, the
-separation mentioned above is a problem here too, particular for
-interaction - it can be hard for a <kbd>userv</kbd> service program to
-interact with its real caller or the user in question.
+arbitrary programs like text editors as root (or other system users)
+when they need to. It is unsuitable for this purpose precisely
+because it enforces a strong separation between the calling and the
+called program, which is undesirable in this context.
+</p>
+
+<p>
+However, its use when restricted to running particular programs in
+particular ways is very similar to many common uses of
+<code>sudo</code><a href="footnotes.html#2" name="fr2">[2]</a>. <code>userv</code> is
+generally much better than restricted <code>sudo</code>, because it protects
+the called program much more strongly from bad environmental
+conditions set up by the caller. Most programs that one might want to
+run via restricted <code>sudo</code>, have not been designed to run in a
+partially hostile environment. <code>userv</code> allows these programs to
+be run in a safer environment and should be used instead.
+</p>
+
+<hr>
+
+<h2>
+<a name="s-stdinerr">6.6 Error handling and input streams (eg stdin)</a>
+</h2>
+
+<p>
+When the service program is reading from a file descriptor connected
+to the calling side, the fd that the service program refers to a pipe
+set up by <code>userv</code> and not to the same object as was presented by
+the caller.
+</p>
+
+<p>
+Therefore if there is some kind of error it is possible for the
+service-side fd to give premature end of file. If it is important to
+tell whether all of the intended data has been received by the service
+program, the datastream must contain an explicit end-of-file
+indication of some kind.
+</p>
+
+<p>
+For example, consider a <code>userv</code> service for submitting a mail
+message, where message is supplied on the service's stdin. However,
+if the calling process is interrupted before it has written all of the
+message, the service program will get EOF on the message data. In a
+naive arrangement this would cause a half-complete message to be
+sent. To prevent this, it is necessary to adopt some kind of explicit
+end indication; for example, the end of the message could be signalled
+by a dot on a line by itself, and dots doubled, as in SMTP. Then the
+service program would know when the entire message had been received,
+and could avoid queueing incomplete messages.
+</p>
+