As several people have pointed out, it is possible (not necessarily
easy) to have builtin commands run as the source or sink of a
pipeline (although at most one such source or sink). The question
what I answered.
Actually, to be even more specific, csh forks the head ends of all
pipes. The tail end of a pipe will be done directly by csh if the
command is a csh builtin. Contrast this with sh, which forks the
tail ends of pipes first:
a | b | c | d | e &
In csh, you might get
 714 Runnning a |
715 b |
716 c |
717 d |
In sh, had it a jobs command, these might be listed as
718 Running a |
717 b |
716 c |
715 d |
In particular, in csh, builtins are run directly by the shell when
they are at the tail end of pipes. This is the most straightforward
implementation, given the direction of creation shown above. Try,
% jobs | cat
% cat /dev/null | jobs
The former produces no output; the latter lists some jobs, then
Reset tty pgrp from xxx to yyy
---which just goes to show that there are bugs in csh (what a
revelation :-) !). Indeed, it is necessary to do another `jobs'
command to flush the `cat | jobs' job from csh's joblist. Also
incidentally, this particular bug would wreak havoc with tty signals
(interrupt, stop) if any of csh's builtins were long-running.
Were csh more clever, it could indeed either avoid forking the jobs
command in `jobs | more' (but at least one `jobs' in `jobs | jobs |
more' must be forked), or defer forgetting about its parent's jobs.
Csh is just not that clever.
Having once again demonstrated that I can write more exposition
on a smaller subject than anyone else :-), I now return you to
your regular netnews,
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)