```nu
  [ a b c ] | each {
    print $in
    print $in
    $in
  }
  ```

  All three of the `$in` values are the same on each iteration, so this outputs:

  ```nu
  a
  a
  b
  b
  c
  c
  ╭───┬───╮
  │ 0 │ a │
  │ 1 │ b │
  │ 2 │ c │
  ╰───┴───╯
  ```

- **_Rule 2:_** When used anywhere else in a pipeline (other than the first position), `$in` refers to the previous expression's result:

  Example:

  ```nushell
  4               # Pipeline input
  | $in * $in     # $in is 4 in this expression
  | $in / 2       # $in is now 16 in this expression
  | $in           # $in is now 8
  # =>   8
  ```

- **_Rule 2.5:_** Inside a closure or block, Rule 2 usage occurs inside a new scope (a sub-expression) where that "new" `$in` value is valid. This means that Rule 1 and Rule 2 usage can coexist in the same closure or block.

  Example:

  ```nushell
  4 | do {
    print $in            # closure-scope $in is 4

    let p = (            # explicit sub-expression, but one will be created regardless
      $in * $in          # initial-pipeline position $in is still 4 here
      | $in / 2          # $in is now 16
    )                    # $p is the result, 8 - Sub-expression scope ends

    print $in            # At the closure-scope, the "original" $in is still 4
    print $p
  }
  ```

  So the output from the 3 `print` statements is:

  ```nu
  4
  4
  8
  ```

  Again, this would hold true even if the command above used the more compact, implicit sub-expression form:

  Example:

  ```nushell
  4 | do {
    print $in                       # closure-scope $in is 4
    let p = $in * $in | $in / 2     # Implicit let sub-expression
    print $in                       # At the closure-scope, $in is still 4
    print $p
  }

  4
  4
  8
  ```

- **_Rule 3:_** When used with no input, `$in` is null.

  Example:

  ```nushell
  # Input
  1 | do { $in | describe }
  # =>   int
  "Hello, Nushell" | do { $in | describe }
  # =>   string
  {||} | do { $in | describe }
  # =>   closure

  # No input
  do { $in | describe }
  # =>   nothing
  ```

* **_Rule 4:_** In a multi-statement line separated by semicolons, `$in` cannot be used to capture the results of the previous _statement_.

  This is the same as having no-input:

  ```nushell
  ls / | get name; $in | describe
  # => nothing
  ```

  Instead, simply continue the pipeline:

  ```nushell
  ls / | get name | $in | describe
  # => list<string>
  ```

### Best practice for `$in` in Multiline Code

While `$in` can be reused as demonstrated above, assigning its value to another variable in the first line of your closure/block will often aid in readability and debugging.

Example:

```nu
def "date info" [] {
  let day = $in
  print ($day | format date '%v')
  print $'... was a ($day | format date '%A')'
  print $'... was day ($day | format date '%j') of the year'
}

'2000-01-01' | date info
# =>  1-Jan-2000
# => ... was a Saturday
# => ... was day 001 of the year
```

### Collectability of `$in`

Currently, the use of `$in` on a stream in a pipeline results in a "collected" value, meaning the pipeline "waits" on the stream to complete before handling `$in` with the full results. However, this behavior is not guaranteed in future releases. To ensure that a stream is collected into a single variable, use the [`collect` command](/commands/docs/collect.html).

Likewise, avoid using `$in` when normal pipeline input will suffice, as internally `$in` forces a conversion from `PipelineData` to `Value` and _may_ result in decreased performance and/or increased memory usage.

## Working with External Commands

Nu commands communicate with each other using the Nu data types (see [types of data](types_of_data.md)), but what about commands outside of Nu? Let's look at some examples of working with external commands:

`internal_command | external_command`

Data will flow from the internal_command to the external_command. This data will get converted to a string, so that they can be sent to the `stdin` of the external_command.