Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.1

# Triggering before or after commands

Triggers of type `command` allow you to configure P4 Server to run a trigger before or after a given command executes. You might want to execute a script.

Before a command runs | After a command runs
--- | ---
prevent a user with the `admin` protection from running p4 obliterate so that only a user with `super` protections can make a file unrecoverable prevent a user from running p4 sync against the commit server because using an edge server might improve performance (see Example command trigger below) prevent the user from runing any command that is not specifically included in a list of allowed commands Sometimes a new release of the server adds a new command. It is safer to decide whether to explicitly add the new command to an 'allowed' list rather than using a 'disallowed' list that permits all new commands by default. | connect its action with that of another tool or process, such as: connecting the creation of a new stream with an email notification to the admin adding to a spreadsheet the list of non-admin users who run p4 users, p4 clients, and p4 streams because gathering such information by non-admins might be considered suspicious

If you are using Distributed Versioning (DVCS), consider Triggering on pushes and fetches.

The following table describes the fields of the `command` trigger.

Field | Meaning
--- | ---
`name` | The name of the command trigger.
`type` | `command` The command to execute is specified in the `path` field.
`path` | The `pre-user-command` value specifies the command before which the trigger should execute. The `post-user-command` value specifies the command after which the trigger should execute. `command` can be a regular expression. For the grammar of regular expressions, see p4 help grep. Examples of possible values: pre-user-login post-user-add post-user-edit pre-user-obliterate pre-user-sync - see Example command trigger below post-user-sync To match a command name that is a substring of another valid command, use the end-of-line meta-character to terminate matching. For example, use `change$` so you don’t also match `changes`. You cannot create a `pre-user-info` trigger. See also Additional triggers for push and fetch commands.
`command` | The trigger for P4 Server to run when the condition implied by `path` is satisfied. Specify the command in a way that allows P4 Server to locate and run the command. The `command` (typically a call to a script) must be quoted, and can take as arguments anything that your `command` is capable of parsing, including any applicable P4 Server trigger variable. When your trigger script is stored in the depot, its path must be specified in depot syntax, delimited by percent characters. For example, if your script is stored in the depot as `//depot/scripts/myScript.pl`, the corresponding value for the command field might be `"/usr/bin/perl %//depot/scripts/myScript.pl%"`. See Storing triggers in the depot for more information.

## Example command trigger

You might want a pre-user-sync trigger to run before a user's request to sync (p4 sync) is executed.

An example of a trigger table entry, check-sync command pre-user-sync "check-sync.pl %serverservices%", is shown below in a comment:

Copy

    #!/usr/bin/perl# Example pre-user-sync command trigger
    # Trigger table entry:
    # check-sync command pre-user-sync "check-sync.pl %serverservices%"

    $serverservices = $ARGV[0]; # from %serverservices% in trigger table
    $allowed_to_sync_from = 'edge-server';
    if ($serverservices eq $allowed_to_sync_from) {
        exit 0;
        } else {
        print 'Sync must only be run from edge servers.';
        exit 1;
    }

See also:

Your search for returned results