- DocumentID: logical-and
  Title: >-
    And (`&&`) Logical Operator
  CategoryID: parser
  Summary: >-
    Continues next operation if previous operation passes
  Description: |-
    When in the **normal** run mode (see "schedulers" link below) this will only
    run the command on the right hand side if the command on the left hand side
    does not error. Neither STDOUT nor STDERR are piped.

    This has no effect in `try` nor `trypipe` run modes because they automatically
    apply stricter error handling.
  Examples: |-
    Second command runs because the first command doesn't error:

    ```
    » out: one && out: two
    one
    two
    ```

    Second command does not run because the first command produces an error:

    ```
    » err: one && out: two
    one
    ```
  Detail: |-
    This is equivelent to a `try` block:

    ```
    try {
        err: one
        out: two
    }
    ```
  Related:
  - pipe-err
  - user-guide/pipeline
  - user-guide/schedulers
  - commands/out
  - commands/err
  - commands/try
  - commands/trypipe



- DocumentID: logical-or
  Title: >-
    Or (`||`) Logical Operator
  CategoryID: parser
  Summary: >-
    Continues next operation only if previous operation fails
  Description: |-
    When in the **normal** run mode (see "schedulers" link below) this will only
    run the command on the right hand side if the command on the left hand side
    does not error. Neither STDOUT nor STDERR are piped.

    This has no effect in `try` nor `trypipe` run modes because they automatically
    apply stricter error handling. See detail below.
  Examples: |-
    Second command does not run because the first command doesn't error:

    ```
    » out: one || out: two
    one
    ```

    Second command does run because the first command produces an error:

    ```
    » err: one || out: two
    one
    two
    ```
  Detail: |-
    This has no effect in `try` nor `trypipe` run modes because they automatically
    apply stricter error handling. You can achive a similiar behavior in `try` with
    the following code:

    ```
    try {
        err: one -> !if { out: two }
    }
    ```

    There is no workaround for `trypipe`.
  Related:
  - pipe-err
  - user-guide/pipeline
  - user-guide/schedulers
  - commands/out
  - commands/err
  - commands/try
  - commands/trypipe