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

P4 Server Administration Documentation | 2026.1

# Execution environment

When testing and debugging triggers, remember that any `p4` commands invoked from within the script will run within a different environment (`P4USER`, `P4CLIENT`, and so on) than that of the calling user. You must therefore take care to initialize the environment you need from within the trigger script and not inherit these values from the current environment. For example:

    export P4USER=george
    export P4PASSWD=abR)aCad^ab9ra
    cd /home/perforce/my-database-triggers

    p4 admin checkpoint
    ls -l checkpoint.* journal*

where `/home/perforce/my-database-triggers` represents the location of your triggers.

We recommend the following guidelines:

- Wherever possible, use the full path to executables.

- For path names that contain spaces, use the short path name.

  For example, `C:\Program Files\Perforce\p4.exe` is most likely located in `C:\PROGRA~1\Perforce\p4.exe`.

- Unicode settings affect trigger scripts that communicate with the server. You should check your trigger’s use of file names, directory names, P4 Server identifiers, and files that contain Unicode characters, and make sure that these are consistent with the character set used by the server.
- Login tickets might not be located in the same place as they were during testing. For testing, you can pass in data with `p4 login < input.txt`.
- If you are using LDAP authentication, or authentication triggers, you must authenticate using tickets (as with level 3 of Server security levels). This prevents storing a plaintext password value in `P4PASSWD`. Instead, set `P4PASSWD` to the ticket value that `p4 login -p` returns.

- For troubleshooting, log output to a file. For example:

      date /t >> trigger.log
      p4 info >> trigger.log
      C:\PROGRA~1\Perforce\p4.exe -p myServer:1666 info

  If a trigger fails to execute, the event is now logged in the server log and an error is sent to the user.

- P4 Server commands in trigger scripts are always run by a specific P4 Server user. If no user is specified, an extra P4 Server license for a user named `SYSTEM` (or on UNIX, the user that owns the `p4d` process) is assumed. To prevent this from happening:

  - Pass a `%user%` argument to the trigger that calls each P4 Server command to ensure that each command is called by that user. For example, if Joe submits a changelist that activates trigger script `trigger.pl`, and `trigger.pl` calls the `p4 changes` command, the script can run the command as `p4 -u %user% changes`.
  - Set `P4USER` for the account that runs the trigger to the name of an existing user. (If your P4 Server is installed as a service under Windows, note that Windows services cannot have a `P4USER` value; on Windows, you must therefore pass a user value to each command as described above.)
- You can access the following environment variables from a trigger: `P4USER`, `P4CLIENT`, `P4HOST`, `P4LANGUAGE`, `CWD`, `OS`.

- Timeouts associated with the trigger user might affect trigger execution. To prevent an unwanted timeout, place the user running the trigger in a group that will not time out.

  Timeout is the login ticket duration as defined by the group spec of the user the trigger is using to run commands; the ticket is the one created for use with the trigger. For example, the default login ticket duration is 8 hours, so if that is left unchanged for the trigger user, the trigger will have stopped working by the next day. Consider disabling the timeout so the trigger is not concerned about logins while it has access to the ticket file.

- By default, the Perforce service runs under the Windows local `System` account. The `System` account might have different environmental configurations (including not just P4 Server-related variables, but `PATH` settings and file permissions) than the one in which you are using to test or write your trigger.
- Because Windows requires a real account name and password to access files on a network drive, if the trigger script resides on a network drive, you must configure the service to use a real userid and password to access the script.

- On Windows, standard input does not default to binary mode. In text mode, line ending translations are performed on standard input, which is inappropriate for binary files.

  If you are using archive triggers against binary files on a Windows machine, you must prevent unwanted line-ending translations by ensuring that standard input is changed to binary mode (`O_BINARY`).

- When using triggers on Windows, `%formfile%` and other variables that use a temp directory should use the `TMP` and `TEMP` system variables in Windows, not the user’s `TEMP` variables.

Your search for returned results