BREAK(1POSIX)

🌸 PROLOG 🌸

okay so bestie, before we even get into it β€” this page is part of the POSIX Programmer's Manual. the Linux implementation of this interface may differ, so if you're on Linux pls consult the corresponding Linux manual page for the deets on Linux behavior. or honestly?? the interface might not even be implemented on Linux at all. vibe check accordingly. πŸ’…


✨ NAME ✨

break β€” exit from for, while, or until loop

πŸŽ€ SYNOPSIS πŸŽ€

break [n]

πŸ’– DESCRIPTION πŸ’–

so here's the tea. if n is specified, the break utility shall exit from the nth enclosing for, while, or until loop. if n is not specified, break shall behave as if n was specified as 1. like, default is one loop, that's the whole vibe.

execution shall continue with the command immediately following the exited loop. the value of n is a positive decimal integer. and if n is greater than the number of enclosing loops?? the outermost enclosing loop shall be exited β€” it just keeps going till there's nothing left to break out of. but if there is no enclosing loop, the behavior is unspecified. πŸ™ˆ

now, a loop shall enclose a break or continue command if the loop lexically encloses the command. a loop lexically encloses a break or continue command if the command is:

  • executing in the same execution environment (see Section 2.12, Shell Execution Environment) as the compound-list of the loop's do-group (see Section 2.10.2, Shell Grammar Rules), and
  • contained in a compound-list associated with the loop (either in the compound-list of the loop's do-group or, if the loop is a while or until loop, in the compound-list following the while or until reserved word), and
  • not in the body of a function whose function definition command (see Section 2.9.5, Function Definition Command) is contained in a compound-list associated with the loop.

and one more thing bestie, this one's important: if n is greater than the number of lexically enclosing loops and there is a non-lexically enclosing loop in progress in the same execution environment as the break or continue command, it is unspecified whether that loop encloses the command. so like, don't count on it. 😭

🌈 OPTIONS 🌈

None.

πŸ¦‹ OPERANDS πŸ¦‹

See the DESCRIPTION.

πŸ’œ STDIN πŸ’œ

Not used.

πŸ“ INPUT FILES πŸ“

None.

🧚 ENVIRONMENT VARIABLES 🧚

None.

⭐ ASYNCHRONOUS EVENTS ⭐

Default.

πŸŽ€ STDOUT πŸŽ€

Not used.

πŸ’€ STDERR πŸ’€

The standard error shall be used only for diagnostic messages.

🌸 OUTPUT FILES 🌸

None.

✨ EXTENDED DESCRIPTION ✨

None.

πŸ‘‘ EXIT STATUS πŸ‘‘

  • 0 β€” Successful completion. slay.
  • >0 β€” The n value was not an unsigned decimal integer greater than or equal to 1.

πŸ”₯ CONSEQUENCES OF ERRORS πŸ”₯

Default.


the following sections are informative. (iykyk πŸ‘€)


🫢 APPLICATION USAGE 🫢

None.

🌈 EXAMPLES 🌈

okay first, the classic. break out the second you hit a directory:

for i in *
do
    if test -d "$i"
    then break
    fi
done

now. the results of running the following example are unspecified: there are two loops in progress when the break command is executed, and they are in the same execution environment, but neither loop is lexically enclosing the break command. (there are no loops lexically enclosing the continue commands, either.) so like... it's giving chaos, honestly:

foo() {
    for j in 1 2; do
        echo 'break 2' >/tmp/do_break
        echo "  sourcing /tmp/do_break ($j)..."
        # the behavior of the break from running the following command
        # results in unspecified behavior:
        . /tmp/do_break

        do_continue() { continue 2; }
        echo "  running do_continue ($j)..."
        # the behavior of the continue in the following function call
        # results in unspecified behavior (if execution reaches this
        # point):
        do_continue

        trap 'continue 2' USR1
        echo "  sending SIGUSR1 to self ($j)..."
        # the behavior of the continue in the trap invoked from the
        # following signal results in unspecified behavior (if
        # execution reaches this point):
        kill -s USR1 $$
        sleep 1
    done
}
for i in 1 2; do
    echo "running foo ($i)..."
    foo
done

πŸ’… RATIONALE πŸ’…

so in early proposals, consideration was given to expanding the syntax of break and continue to refer to a label associated with the appropriate loop as a preferable alternative to the n method. like, cuter, right?? however, this volume of POSIX.1‐2017 does reserve the name space of command names ending with a <colon>. and it is anticipated that a future implementation could take advantage of this and provide something like:

outofloop: for i in a b c d e
do
    for j in 0 1 2 3 4 5 6 7 8 9
    do
        if test -r "${i}${j}"
        then break outofloop
        fi
    done
done

and that this might be standardized after implementation experience is achieved. so like, watch this space bestie. πŸ‘€

⭐ FUTURE DIRECTIONS ⭐

None.

πŸ¦‹ SEE ALSO πŸ¦‹

Section 2.14, Special Built-In Utilities

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .


okay that's the whole thing bestie, we ate and left no crumbs. this was brought to you by IEEE/The Open Group, 2017 β€” mwah, periodt. πŸ’…βœ¨

πŸ“¦ where this page comes from