Editing Pipeline (Unix) (section)

===Pipemill===
<!-- section header used in redirect -->
In the most commonly used simple pipelines the shell connects a series of sub-processes via pipes, and executes external commands within each sub-process.  Thus the shell itself is doing no direct processing of the data flowing through the pipeline.

However, it's possible for the shell to perform processing directly, using a so-called '''mill''' or '''pipemill''' (since a <code lang="bash">while</code> command is used to "mill" over the results from the initial command). This construct generally looks something like:
<syntaxhighlight lang="bash">
command | while read -r var1 var2 ...; do
    # process each line, using variables as parsed into var1, var2, etc
    # (note that this may be a subshell: var1, var2 etc will not be available
    # after the while loop terminates; some shells, such as zsh and newer
    # versions of Korn shell, process the commands to the left of the pipe
    # operator in a subshell)
    done
</syntaxhighlight>

Such pipemill may not perform as intended if the body of the loop includes commands, such as <code>cat</code> and <code>ssh</code>, that read from <code>[[stdin]]</code>:<ref>{{cite web |date=6 March 2012 |title=Shell Loop Interaction with SSH |url=http://72.14.189.113/howto/shell/while-ssh/ |url-status=dead |archive-url=https://web.archive.org/web/20120306135439/http://72.14.189.113/howto/shell/while-ssh/ |archive-date=6 March 2012}}</ref> on the loop's first iteration, such a program (let's call it ''the drain'') will read the remaining output from <code>command</code>, and the loop will then terminate (with results depending on the specifics of the drain).  There are a couple of possible ways to avoid this behavior.  First, some drains support an option to disable reading from <code>stdin</code> (e.g. <code>ssh -n</code>).  Alternatively, if the drain does not ''need'' to read any input from <code>stdin</code> to do something useful, it can be given <code>&lt; /dev/null</code> as input.

As all components of a pipe are run in parallel, a shell typically forks a subprocess (a subshell) to handle its contents, making it impossible to propagate variable changes to the outside shell environment. To remedy this issue, the "pipemill" can instead be fed from a [[here document]] containing a [[command substitution]], which waits for the pipeline to finish running before milling through the contents. Alternatively, a [[named pipe]] or a [[process substitution]] can be used for parallel execution. [[GNU bash]] also has a {{code|lastpipe}} option to disable forking for the last pipe component.<ref>{{cite web |author=John1024 |title=How can I store the "find" command results as an array in Bash |url=https://stackoverflow.com/a/23357277 |website=Stack Overflow}}</ref>