February 25, 2016

The magic of ‘p4 set’

Traceability

Most of you will probably use our visual client (Helix P4V) or an IDE like Eclipse or Visual Studio to work with your Helix Versioning Engine, but spare a thought for those of us who use the command line tool (Helix P4) or write a script.

If you start up the command line tool Helix P4 (or P4.exe on Windows) the first time, chances are that you get greeted with an error message telling you that you need to check $P4PORT. In order to connect to a Helix Versioning Engine, you actually need to define P4PORT, P4USER and usually P4CLIENT (find a full list of variables here, or run ‘p4 help environment’). You can define these parameters on the command line with the usage switches:

p4 –p server:1666 –u myuser –c myclientworkspace command

But, frankly, life is too short. You can, as well, hardcode the parameters as environment variables. This is easily done on UNIX (or even a Mac), but requires a bit more effort on Windows. 

On Windows you can always use the registry (that unwieldly beast you access via regedit or an API), but rather than using it directly, you use ‘p4 set’:

$> p4 set P4USER=sven

This will set the appropriate registry value for you, and make the change permanent (beyond the next reboot) as well. [1]

‘p4 set’ has a lot more tricks up its sleeve. For example, on Windows there are actually two registry settings: one for the user and one for the machine. If you want to set a variable for every user on the same machine, you can use the ‘-s’ option:

$> p4 set –s P4EDITOR=notepad2.exe

There is an implicit order as to which parameter is active. Listed below, with the higher entries overriding the lower ones: 

Explicitly named via usage switches
Environment
.enviro file or registry
Registry for all users (-s switch)
Default values (like your OS user name instead of P4USER)

 

Listing existing parameters

One of the greatest features for me is the ability to see which Perforce variables are active and where they have been set. For this, I use ‘p4 set’ without any arguments:
$> p4 set
P4CLIENT=sknop.marsipulami (config '/Users/sknop/p4-public/.p4') P4CONFIG=.p4 (config '/Users/sknop/p4-public/.p4' ) P4EDITOR=vi
P4IGNORE=.p4ignore
P4PORT=public.perforce.com:1666 (config '/Users/sknop/p4-public/.p4')
P4USER=sven_erik_knop (config '/Users/sknop/p4-public/.p4')
P4_public.perforce.com:1666_CHARSET=none (enviro)

Whoa, there are a whole range of variables defined here. Let’s go through some of them.

 

P4EDITOR=vi

I use a MacBook Pro these days, but I am kind of old fashioned, so I prefer to have my editor (for specs and so on) set to vi (well, technically vim, to which vi is an alias). I have defined this in my environment in .bash_profile. For environment variables, ‘p4 set’ simply prints the value and no extra brackets.

 

P4CONFIG=.p4

I could (and I will, I promise) write a whole blog article on the merits and features of P4CONFIG, but for now, if you do not know this feature yet, I’ll encourage you to read up on it in the documentation

The P4CONFIG variable points to a text file typically in the root of your workspace. That text file contains VARIABLE=VALUE pairs that override the environment. Very handy if you have more than one client workspace on your machine or if you have more than one user name (international man of mystery, me).

The value returned by the command ‘p4 set’ is a bit of an oddball. As you will see in a moment, ‘p4 set’ shows you in brackets which configuration file the particular variable is defined in. For P4CONFIG itself, it shows you which P4CONFIG file is active – but the value of P4CONFIG itself is defined somewhere else (in my case in .bash_profile again).

 

P4PORT=public.perforce.com:1666 (config '/Users/sknop/p4-public/.p4')

Here is such a variable defined in my P4CONFIG file. This is a very typical example for P4CONFIG’s use case.

 

P4IGNORE=.p4ignore

I have written about the great features of P4IGNORE before, so you should know what this is about.

 

P4_public.perforce.com:1666_CHARSET=none (enviro)

Hold your horses! The variable name is peculiar to start with, but what is this enviro? 

So, ‘p4 set’ would for the longest time return an error message on Mac and Linux if you tried to set a (registry) variable (something rude along the lines of “This is not Windows, go away”). Starting with 2014.2 this behaviour has been superseded by using a single global environment file located in your $HOME directory called .p4enviro. If you open this file you might find a whole range of entries, most of them related to charsets for Perforce Helix servers starting with “P4_”.

This is part of the effort towards making Unicode simpler to use (you might notice the “auto” word in there if you have a Unicode-enabled Helix server to which you have connected). Another blog post in itself, methinks. For non-Unicode servers the value defined in here is “none”.

Therefore, the peculiar name as well – it defines the Perforce Helix server to which the CHARSET setting applies (as you probably have guessed by now).

More on P4CONFIG and on Unicode in a future post.

 

Conclusion

If you are running P4 from the command line or if you are running a script, you often use your environment settings instead of providing connection details explicitly. To check which parameters are active, ‘p4 set’ is an invaluable tool.

You can use this command to set parameters on any platform as well, and they will wind up in the .enviro file on Linux and Mac. Check out this file to see what has been collected there already.

Happy hacking!

 

[1] If you are using our visual client (P4V) on Windows, you can go to Connections->Environment Settings... to set P4PORT, P4USER and P4CLIENT in the registry from there.