-specified by the system administrator.</footnote>. However, the
-separation mentioned above is a problem here too, particular for
-interaction - it can be hard for a <prgn/userv/ service program to
-interact with its real caller or the user in question.
+specified by the system administrator.</footnote>. <prgn/userv/ is
+generally much better than restricted <prgn/sudo/, 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 <prgn/sudo/, have not been designed to run in a
+partially hostile environment. <prgn/userv/ allows these programs to
+be run in a safer environment and should be used instead.
+
+<sect id="stdinerr">Error handling and input streams (eg stdin)
+<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 <prgn/userv/ and not to the same object as was presented by
+the caller.
+<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>
+
+For example, consider a <prgn/userv/ 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.