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, Helix 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 may 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.

  • Helix Server commands in trigger scripts are always run by a specific Helix Server user. If no user is specified, an extra Helix 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 Helix 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 Helix Core 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 may have different environmental configurations (including not just Helix 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.