Commands/execute

executes another command but allows changing the executor, changing the position and angle it is executed at, adding preconditions, and storing its result.

Java Edition
$$, there are twelve instructions (or sub-commands) for the  command. Multiple sub-commands are connected after /execute. Subcommands are divided into 4 categories: modify subcommands, condition subcommands, store subcommands, and  subcommand.
 * Modify subcommands modify command variables and change the situation the command is executed, and execute subcommands following it with specific executor(s), execution position(s), execution dimension(s), execution rotation(s) and execution anchor.
 * Condition subcommands are used to test whether certain conditions are true and output results or limit conditions of execution.
 * Store subcommands can store the return values of the command in a scoreboard or the data of an entity, block entity, or storage, and can also change the maximum or current value of a boss bar.
 * subcommand is used for carrying out another command.

All needed sub-commands can be concatenated together. Subcommands other than the  subcommand can be arranged arbitrarily and used multiple times. But the  subcommand can only be used once and must be put at the end of the subcommands chain. A  subcommand or a condition subcommand finalizes the command, otherwise the command does nothing. The game processes these subcommands in order from front to end, for example, the following commands are different:
 * All entities move one block forward:
 * All entities are teleported to one block in front of the executor:

The game processes other subcommands before processing  and store subcommands, so the   and store subcommands cannot affect other subcommands. commands and store subcommands cannot affect each other as well. In some cases, the command may terminate halfway and does nothing.

After executed (if it does not terminate halfway), the command returns a  value and a   value (see  for details). These two values ​​come from the last subcommand (may be a condition subcommand or a  subcommand). Note that the return value of the command must be an integer, if not, it is rounded down. The  value is usually 0 or 1. When the command fails, both return values ​​are 0. When the last subcommand (may be a condition subcommand or a  subcommand) is executed multiple times, only values of the last execution can be returned. The two values can be stored by store subcommands.

command also has a success count (whether or not terminates halfway), which is different from  and   value. This is usually  or , but if the last subcommand is executed many times separately (as perhaps with "/execute as @a -> execute") then success can be a number higher than. When executing it with a command block, the success count is returned to the command block, which can be checked by a conditional command block for success or be read with a redstone comparator.

There are twelve instructions (or sub-commands) for the  command, and each has its own special syntax, so describing syntax takes a large branching tree.


 * Full syntax tree:
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.
 * where  represents the start of another subcommand.

align

 * Updates the command's execution position, aligning to its current block position (an integer). Only applies along specified axes.
 * This is akin to the coordinates – i.e. rounding them downwards.
 * Syntax
 * Arguments
 * Any non-repeating combination of the characters 'x', 'y', and 'z'. (For example,,  ,  , or  .)
 * Result
 * Execution position in the given axes are floored, changing by less than 1 block.
 * Unparseable if the argument is not specified correctly
 * Example
 * Given position (-1.8, +2.3, +5.9),  changes the position of  (-2, +2.3, +5).
 * Given (+2.4, -1.1, +3.8),  sets the player's spawnpoint to (2, -2, 3).
 * Given position (-1.8, +2.3, +5.9),  changes the position of  (-2, +2.3, +5).
 * Given (+2.4, -1.1, +3.8),  sets the player's spawnpoint to (2, -2, 3).

anchored

 * Sets the execution anchor to the eyes or feet. Defaults to feet.
 * Effectively recenters local coordinates on either the eyes or feet, also changing the angle the  sub-command (of  and ) works off of
 * Syntax
 * Arguments
 * ( or  )
 * Whether to anchor the executed command to eyes or feet
 * Result
 * Execution anchor is set to either the eyes or the feet.
 * Unparseable if the argument is not specified correctly.
 * Example
 * The effect of is to move a target by placing its feet at the given position.
 * effectively teleports the executor's feet to where its eyes are (the execution position).
 * means "place the executor's feet 5 blocks left of where its eyes are"
 * means "place the executor's feet 5 blocks left of where its eyes are"

as

 * Sets the command's executor to target entity, without changing execution position, rotation, dimension, or anchor
 * Syntax
 * Arguments
 * Target entity/entities to become the new executor.
 * Result
 * Executor is updated to target entity (which changes the meaning of ).
 * Unparseable if the argument is not specified correctly.
 * Terminates if  fails to resolve to one or more valid entities (named players must be online).
 * When multiple entities are selected, next sub-command is executed once by each executor.
 * Example
 * Get data of all sheep:
 * Example
 * Get data of all sheep:

at

 * Sets the execution position, rotation, and dimension to match those of an entity; does not change executor.
 * Syntax
 * Arguments
 * Target entity/entities to match position, rotation, and dimension with.
 * Result
 * Execution position, rotation, and dimension are updated to match target entity.
 * Unparseable if the argument is not specified correctly.
 * Terminates if  fails to resolve to one or more valid entities (named players must be online).
 * When multiple entities are selected, next subcommand is executed once at each entity's execution position, rotation, and dimension.
 * Example
 * All sheep move upward 1 block:
 * Kill yourself, because "at" does not change the executor:
 * All sheep move upward 1 block:
 * Kill yourself, because "at" does not change the executor:

facing

 * Sets the execution rotation to face a given point, as viewed from its anchor (either the eyes or the feet)
 * Syntax
 * Arguments
 * Option: facing 
 * Coordinate to rotate towards
 * Option:'' facing entity 
 * The target(s) to rotate towards
 * ( or  )
 * Whether to point at the target's eyes or feet
 * Result
 * Execution otation is updated to face given position or targets
 * Unparseable if the argument is not specified correctly
 * Terminates if  fails to resolve to one or more valid entities (named players must be online)
 * When multiple entities are selected, next subcommand is executed once in each execution rotation
 * Example
 * Executor rotates once to the left:
 * All entities move one block in the direction of (0, 64, 0) (without changing their rotation):
 * All entities move one block in the direction of (0, 64, 0) (with changing their rotation):
 * All non player entities move one space in the direction of their nearest player (without changing their orientation):
 * Executor rotates once to the left:
 * All entities move one block in the direction of (0, 64, 0) (without changing their rotation):
 * All entities move one block in the direction of (0, 64, 0) (with changing their rotation):
 * All non player entities move one space in the direction of their nearest player (without changing their orientation):

in

 * Sets the execution dimension and position
 * It respects dimension scaling for relative and local coordinates: the execution position (only the X/Z part) is divided by 8 when changing from the Overworld to the Nether, and is multiplied by 8 when vice versa. Applies to custom dimensions as well.
 * Syntax
 * Arguments
 * Name of the new execution dimension
 * The standard dimensions in the minecraft namespace are "overworld", "the_nether", and "the_end".
 * Result
 * Execution dimension is updated
 * Unparseable if the argument is not specified correctly
 * Example
 * Looking for an end city (from the overworld):
 * If a player at position in Overworld runs command , the player is teleported to  in the Nether.
 * If a player at position in Overworld runs command , the player is teleported to  in the Nether.
 * If a player at position in Overworld runs command , the player is teleported to  in the Nether.
 * If a player at position in Overworld runs command , the player is teleported to  in the Nether.
 * If a player at position in Overworld runs command , the player is teleported to  in the Nether.

positioned

 * Sets the execution position, without changing execution rotation or dimension; can match an entity's position
 * Syntax
 * Arguments
 * Option: positioned 
 * New position
 * Option:'' positioned as 
 * Target entity/entities to match position with
 * Result
 * Position is updated
 * Unparseable if the argument is not specified correctly.
 * Terminates if  fails to resolve to one or more valid entities (named players must be online).
 * When multiple entities are selected, next sub-command is executed once in each execution position.
 * Examples
 * Look for a village near (0, 64, 0)
 * Let all sheep move one block in the direction of the executor's rotation (for example, when the executor looks east, the sheep moves one block eastward; when the executor looks up, the sheep moves one block upward):
 * When multiple entities are selected, next sub-command is executed once in each execution position.
 * Examples
 * Look for a village near (0, 64, 0)
 * Let all sheep move one block in the direction of the executor's rotation (for example, when the executor looks east, the sheep moves one block eastward; when the executor looks up, the sheep moves one block upward):
 * Let all sheep move one block in the direction of the executor's rotation (for example, when the executor looks east, the sheep moves one block eastward; when the executor looks up, the sheep moves one block upward):

rotated

 * Sets the execution rotation; can match an entity's rotation
 * Syntax
 * Arguments
 * The desired rotation
 * is measured clockwise in degrees from due south (the +Z direction), ranging [–180 to +180)
 * is measured as declination from the horizon in degrees, ranging [–90 to +90] (straight up to straight down)
 * Tilde notation can be used to specify a rotation relative to the current execution rotation.
 * Target entity/entities to match rotation with
 * Result
 * Unparseable if the argument is not specified correctly
 * Terminates if  fails to resolve to one or more valid entities (named players must be online).
 * When multiple entities are selected, next sub-command is executed once in each execution rotation.
 * Example
 * Move every sheep 1 block in the direction that the player closest to it is facing:
 * Terminates if  fails to resolve to one or more valid entities (named players must be online).
 * When multiple entities are selected, next sub-command is executed once in each execution rotation.
 * Example
 * Move every sheep 1 block in the direction that the player closest to it is facing:

Condition subcommands
The particular use of the  and   subcommands are to restrict command execution to happen only under specified conditions. In most cases,  is a negation of , which means the command execution happens only when the test result is "false", which can be seen as "if not...". The two commands have identical argument structures.

If the test fails, for example, testing a block outside the world, both  and   terminates.

There are six different types of conditions:
 * 1) (if|unless) block – Tests a single real block
 * 2) (if|unless) blocks – Tests a real 3D rectangular volume against another
 * 3) (if|unless) data – Tests the data held by a real block, entity, or a storage
 * 4) (if|unless) entity – Tests whether an entity like the one given is real
 * 5) (if|unless) predicate – Tests a predicate
 * 6) (if|unless) score - Tests an target's score

(if|unless) block

 * Compares the block at a given position to a given block ID or block tag.


 * Syntax


 * Arguments
 * Position of a target block to test
 * A valid block ID (or predicate) or block tag to test for
 * Block ID optionally followed by block states (bounded by brackets – ) and/or data tags (bounded by braces –  )
 * A valid block ID (or predicate) or block tag to test for
 * Block ID optionally followed by block states (bounded by brackets – ) and/or data tags (bounded by braces –  )


 * Result
 * If the block at the position matches the block ID (or predicate) or belongs to the block tag, the test result is "true", otherwise the test result is "false".
 * If the position is outside of the world, the test fails, and the command terminates.

(if|unless) blocks

 * Compares the blocks in two equally sized volumes


 * Syntax


 * Arguments
 * Positions of any two diagonal corners of the source volume (the comparand; the volume to compare)
 * Position of the lower northwest corner of the destination volume (the comparator; the volume to compare to)
 * Assumed to be of the same size as the source volume
 * lit. 'scan mode' or 'all' or 'masked'
 * Specifies whether all blocks in the source volume should be compared, or if air blocks should be masked/ignored
 * Assumed to be of the same size as the source volume
 * lit. 'scan mode' or 'all' or 'masked'
 * Specifies whether all blocks in the source volume should be compared, or if air blocks should be masked/ignored

(if|unless) data

 * Checks whether the targeted block, entity or storage has any data for a given tag


 * Syntax
 * – for data checking a block
 * – for data checking an entity
 * – for data checking [a storage?]


 * Arguments
 * Option:
 * Position of the block whose data will be tested.
 * Data tag that the block will be checked whether it has.
 * Option:
 * One single entity whose data will be tested.
 * Data tag that the entity will be checked whether it has.
 * Option:
 * The namespaced ID of the storage whose data will be tested.
 * Data tag that the storage will be checked whether it has.
 * Data tag that the entity will be checked whether it has.
 * Option:
 * The namespaced ID of the storage whose data will be tested.
 * Data tag that the storage will be checked whether it has.
 * Data tag that the storage will be checked whether it has.
 * Data tag that the storage will be checked whether it has.


 * Result
 * If the block, entity or storage has the data tag, the test result is "true".

(if|unless) entity

 * Checks whether one or more entities exist.


 * Syntax
 * Arguments
 * The target entity/ies to check. May be a player name, UUID or target selector.
 * Result
 * If the entity exists, or at least one entity can be selected by the target selector, the result is "true".
 * Result
 * If the entity exists, or at least one entity can be selected by the target selector, the result is "true".

(if|unless) predicate

 * Checks whether the predicate evaluates to a positive result. See Predicate for more information.


 * Syntax
 * Arguments
 * The predicate that will be checked whether evaluates to a positive result.
 * The predicate that will be checked whether evaluates to a positive result.
 * The predicate that will be checked whether evaluates to a positive result.


 * Result
 * If the predicate evaluates to a positive result, the result is "true".
 * Fails is the predicate does not exist.

(if|unless) score

 * Check whether a score has the relation to another score, or whether it is in a given range.


 * Syntax
 * – for comparing two scores
 * – for comparing one score against a range


 * Arguments
 * A single target score holder
 * can be executed but fails
 * The scoreboard objective to check under. The score of the target score holder in this objective will be checked.
 * Option: 
 * A source score holder to compare against
 * can be executed but fails
 * A scoreboard objective. The score of the source score holder in this objective will be checked.
 * Option: 
 * Range to compare score against
 * A scoreboard objective. The score of the source score holder in this objective will be checked.
 * Option: 
 * Range to compare score against
 * Range to compare score against
 * Range to compare score against


 * Result
 * Unparseable if the argument is not specified correctly.
 * When not at the end of the subcommands chain, only if the condition tests pass is the subcommand following it executed. If it is executed multiple times by multiple variables (e.g. executors, execution positions, execution rotations), it acts as a variable filter - Only the variable that matches the condition executes the next subcommand.
 * When at the end of the subcommands chain, it checks whether the condition is met and then outputs.


 * Example
 * Kill all players standing on a wool:
 * Check whether your own scores A and B are equal:

Store subcommand
Store the final command's  or   value somewhere. It first records the location to store in, and then stores in the location after all the commands are executed. Note that the return values of commands must be an integer. If a decimal, it is rounded down.

There are five different modes of storage:
 * 1) store (result|success) block – Store return value under one of a block's NBTs
 * 2) store (result|success) bossbar – Store return value as a bossbar data
 * 3) store (result|success) entity – Store return value under one of an entity's NBTs
 * 4) store (result|success) score – Store return value under a target's score on an objective
 * 5) store (result|success) storage – Store return value under one of a storage's NBTs

store (result|success) block

 * Saves the final command's return value as tag data within a block entity. Store as a byte, short, int, long, float, or double. If the return value is a decimal, it is rounded first and then multiplied by.


 * Syntax


 * Arguments
 * Position of target block
 * Location of the desired tag to hold the value in
 * lit. 'type' or 'byte' or 'short' or 'int' or 'long' or 'float' or 'double'
 * Desired data size/type
 * Multiplier to apply before storing value
 * Desired data size/type
 * Multiplier to apply before storing value
 * Multiplier to apply before storing value


 * Result
 * Unparseable if the argument is not specified correctly.
 * Does not store anything when the path does not exist.

store (result|success) bossbar

 * Saves the final command's return value in either a bossbar's current value or its maximum value


 * Syntax
 * Arguments
 * ID of the bossbar to target for saving
 * lit. 'value' or 'value' or 'max'
 * Whether to overwrite the bossbar's current value or its max value
 * Result
 * Unparseable if the argument is not specified correctly.
 * Result
 * Unparseable if the argument is not specified correctly.

store (result|success) entity

 * Save the final command's return value in one of an entity's data tags. Store as a byte, short, int, long, float, or double. If the return value is a decimal, it is rounded first and then multiplied by . Like the "" command, "/execute store " cannot modify player NBT.


 * Syntax


 * Arguments
 * A single entity to store under
 * Location of the desired tag to hold the value in
 * lit. 'type' or 'byte' or 'short' or 'int' or 'long' or 'float' or 'double'
 * Desired data size/type
 * Multiplier to apply before storing value
 * Result
 * Unparseable if the argument is not specified correctly.
 * Does not store anything when the path does not exist.
 * Result
 * Unparseable if the argument is not specified correctly.
 * Does not store anything when the path does not exist.

store (result|success) score

 * Overrides the score held by  on the given   with the final command's return value.


 * Syntax


 * Arguments
 * Specifies score holder(s) whose score is to be overridden
 * A scoreboard objective
 * Result
 * Unparseable if the argument is not specified correctly.
 * Result
 * Unparseable if the argument is not specified correctly.

store (result|success) storage

 * Uses the  within storage to store the return value in. Store as a byte, short, int, long, float, or double. If the return value is a decimal, it is rounded first and then multiplied by  . If the storage does not yet exist, it gets created.


 * Syntax


 * Arguments
 * (Single word)
 * Target storage container, as a namespaced ID
 * Location of the desired tag to hold the value in
 * lit. 'type' or 'byte' or 'short' or 'int' or 'long' or 'float' or 'double'
 * Desired data type/size
 * Multiplier to apply before storing value
 * Multiplier to apply before storing value
 * Multiplier to apply before storing value


 * Result
 * Unparseable if the argument is not specified correctly

Run subcommand
The command's single argument is the command to be executed, the variables of which may be modified by the subcommands used.


 * Syntax


 * Arguments
 * Can be any command
 * Can be any command


 * Technical
 * Resets the command node to the root of the command dispatcher
 * Information on modelling commands as chat text:
 * The command dispatcher is what starts when the player begins a message with a forward-slash.
 * A command node is the specific word/entry the cursor is editing, either a command or an argument.
 * The root node comes before the first word in the current command.


 * Result
 * Execute this command. Fails if  is failure.

More examples

 * Teleport all players who have an item enchanted with Efficiency in their first hotbar slot to coordinates (0, 64, 0):
 * Create a smoke particle three blocks in front of all players:
 * Place a saddle on pigs located within 5 blocks of the executing player, and remove saddles from pigs located over 5 blocks away from the executing player:
 * Make a player say "My feet are soaked!" in chat if they are located in a block of water:
 * Make a player say "Score is reset" in chat if the score 'test' is not set, eg by doing "scoreboard players reset @s test":
 * Make a player say "My feet are soaked!" in chat if they are located in a block of water:
 * Make a player say "Score is reset" in chat if the score 'test' is not set, eg by doing "scoreboard players reset @s test":
 * Make a player say "Score is reset" in chat if the score 'test' is not set, eg by doing "scoreboard players reset @s test":
 * Make a player say "Score is reset" in chat if the score 'test' is not set, eg by doing "scoreboard players reset @s test":

Syntax

 * An alternate syntax allows the command to be executed only if a specific block is detected:
 * An alternate syntax allows the command to be executed only if a specific block is detected:

Arguments

 * Specifies the target to be the command's executor. Must be a player name or target selector. If more than one entity is selected, the command is run once as each of them.


 * Specifies the position from which to run the command. Coordinates specified with tilde and caret notation are relative to the target, not to the position of the command's execution.


 * Specifies the command to be run. Must be a valid command.


 * Specifies the position of the block to check. May use tilde and caret notation to specify distances relative to.


 * Specifies the block ID that the block at detectPos, must match for the command to run. Must be a valid block ID.


 * Must be a valid block data for that type of block or  to match any block data.

Result

 * Fails if arguments are not specified correctly, if  fails to resolve to one or more valid entities (named players must be online), if the checked block is not of the correct block id, data or state, or if the specified command fails.


 * On success, executes the specified command as if executed by the specified target(s), done with operator-level permission at the specified coordinate.

Examples

 * To summon lightning bolts at the positions of every zombie:
 * To summon lightning bolts at the positions of every zombie standing on any type of sand:
 * To summon 10 creepers at the nearest player's position (only works as long as there are at least 10 entities in the loaded world):
 * To summon ender dragon at the position of your friend:
 * To summon 10 creepers at the nearest player's position (only works as long as there are at least 10 entities in the loaded world):
 * To summon ender dragon at the position of your friend:
 * To summon ender dragon at the position of your friend:

History
Befehl/execute Команды консоли/execute Команди консолі/execute 命令/execute